[Home]

Summary:ASTERISK-08806: Cannot make compatible if video codecs do not match and audio codecs require transcoding
Reporter:hristo (hristo)Labels:
Date Opened:2007-02-14 10:40:57.000-0600Date Closed:2011-06-07 14:07:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) r54290.txt
Description:Asterisk fails to bridge two call legs if one of them offers audio+video and the other only supports audio, but in fact does offer video to port 0 (supura bug maybe? see additional info below).

Anyway, the problem only appears if asterisk needs to make audio transcoding and at the same time there are no matching video (yes video!) codecs.

Note that the problem is *not* present if either:
- video codecs are disabled in sip.conf (audio transcoding b/n 711 and 729 works fine in this case) or
- even with video codecs on, audio codecs match (therefore no need to tanscode)

Maybe asterisk only needs to give up trying to setup video, since audio can be handled properly (even via transcoding - line 499 of debug). Instead asterisk drops the call with:

[Feb 14 17:44:47] WARNING[5583]: app_dial.c:1607 dial_exec_full: Had to drop call because I couldn't make SIP/mydomain.tld-081ff6e0 compatible with SIP/ser-08230148

I'm pretty sure this used to work a couple of weeks ago.
sip debug attached.

****** ADDITIONAL INFORMATION ******

It is interesting to note that SPA adds video support in 200 OK (line 445 in debug), even though there is no video on the device - SPA2100. This only happens if video was offered with the initial INVITE sent to SPA2100.

m=video 0 RTP/AVP 34 103 99 - note that port is set to 0, and there is no video stream description.

While this may be a bug with SPA (or maybe it's legal since port is set to 0?) asterisk shouldn't drop the call if only video is not compatible (but audio is!)
Comments:By: Olle Johansson (oej) 2007-02-14 14:55:00.000-0600

The SIPura HAS to return a video media offer with port set to 0, so that's ok.

By: hristo (hristo) 2007-02-23 05:21:43.000-0600

I have also tested this with Eyebeam 1.5 and I was able to duplicate the problem. Eyebeam supports video and actually adds all video headers to the SDP so potentially this bug also affects all video enabled devices.

On the other hand AT-320 IP Phone has no problems with that, because it doesn't add any video headers to the SDP (not even with media port set to 0 as Sipura does).

Hope this helps. Please, let me know if you'll need more debug logs.

By: Olle Johansson (oej) 2007-05-15 15:36:20

Reminder to myself

By: jmls (jmls) 2007-09-12 16:35:34

reminder to oej :)

By: Emmanuel BUU (neutrino88) 2007-09-14 13:44:16

Yeah, I know this issue VERY well : http://bugs.digium.com/view.php?id=9815

Maybe I should produce a new clean patch for branch 1.4.x

By: Tilghman Lesher (tilghman) 2007-11-12 12:50:17.000-0600

The right solution to this is actually to create a video transcoder.  To do that, we need codec_* where the '*' is a video codec.

By: Joshua C. Colp (jcolp) 2008-02-26 12:49:00.000-0600

As this is a duplicate of 9815 I'm suspending it out, since the other one has much more progress.