Summary:ASTERISK-09528: [patch] major fix for SIP video codec negociations
Reporter:Emmanuel BUU (neutrino88)Labels:
Date Opened:2007-05-27 09:45:33Date Closed:2011-06-07 14:02:49
Versions:Frequency of
Environment:Attachments:( 0) nego_video.patch
( 1) report.patch.gz
Description:I was trying to make a video call between two SIP phone having the save video codec but supporting different (and distinct) audio codecs. I found out that Asterisk codec negociation is very broken when video is involved and I found 4 bugs.

- bug 1 - A call B, A has codecs h.263 + ilbc, b has codec h.263 + ulaw

On asterisk 1.4.4, call fails with trace:

    -- Call on SIP/2005-090ef910 left from hold
[May 26 05:46:23] DEBUG[923]: devicestate.c:303 __ast_device_state_changed_literal:  Notification of state change to be queued on device/channel SIP/2005-090ef910
    -- SIP/2005-090ef910 answered SIP/2006-090f7b40
[May 26 06:34:33] DEBUG[3940]: channel.c:2874 set_format: set_format() channel SIP/2006-09d189f8 audip from 00000000 to 00080400 in dir. read
[May 26 05:46:23] WARNING[923]: channel.c:2882 set_format:  Unable to find a codec translation path from unknown to unknown
[May 26 05:46:23] WARNING[923]: channel.c:3234 ast_channel_make_compatible:  Unable to set read format on channel SIP/2006-090f7b40 to 524288
[May 26 05:46:23] WARNING[923]: app_dial.c:1628 dial_exec_full:  Had to drop call because I couldn't make SIP/2006-090f7b40 compatible with SIP/2005-090ef910

Cause: function make_compatible_channel() lookup for translator with composite (audio+video) formats
Fix: separate processing of audio translation and video translation

- bug 2 - B calls A. Same codecs as above

Assuming fix 1 is applied on ast 1.4.4, call fails with a similar message
Cause: in newly created outging channel, jointcapabilities is not initialized properly.

- bug 3 - A calls B. A has h.263 + ulaw + ilbc configured in sip.conf but actually A supports only h.263 + ulaw, B has h.263 + ilbc in sip.conf

On ast 1.4.4, When B anwers,A receives 200 OK with h.263 + ilbc !!! where it shoud be h.263 + ulaw
Cause: bug in process_sdp when checking joint capabilites. COndition for disjoint audio codec does not cause reconfiguration of native format.

- bug 4 - B call A. A has h.263 + ulaw, B has h263, h263+, ilbc

On ast 1.4.4, when A answers, A receives 200 OK with both video codecs !!!!
Cause: there is no mechanism to pass codecs negocialted from outbound channel to back inbound channel.
Fix: added sip_setoption and used ast_channel_option to pass the negociated codec back. Implemented it inside
make_channel_compatible() in channel.c. Restricted it to SIP chans but can be extended easily to other tech

I included a patch that correct this behavior. I sincerly hope that it will make its way into Ast because it corrects loads of problems.

On the more philosofical level, we have in my view a specification issue at stake. I mean that codec capabilities for modern protocols like SIP, IAX, Gtalk, H.323 and even H.324m that are able to support codec negociation should not be specified at the user (or peer) level. It should be left to both end to negociate. If Asterisk is to be used as a video IVR, then, we would need to add the ability to specify a capability per extention.



Full trace of failed cal

[May 26 05:46:23] DEBUG[859]: chan_sip.c:11749 handle_response_invite:  SIP response 200 to standard invite
Found RTP audio format 0
Found RTP audio format 101
Found RTP video format 34
Peer audio RTP is at port
Found description format pcmu for ID 0
Got unsupported a:rtcp in SDP offer
Found description format telephone-event for ID 101
Got unsupported a:fmtp in SDP offer
Found description format h263 for ID 34
Got unsupported a:fmtp in SDP offer
Got unsupported a:rtcp in SDP offer
[May 26 05:46:23] DEBUG[859]: chan_sip.c:5158 process_sdp:  T38 state changed to 0 on channel SIP/2005-090ef910
Capabilities: us - 0x780404 (ulaw|ilbc|h263|h263p|h264|mpeg4), peer - audio=0x80004 (ulaw|h263)/video=0x80000 (h263), combined - 0x80004 (ulaw|h263)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port
Peer video RTP is at port
[May 26 05:46:23] DEBUG[859]: chan_sip.c:5238 process_sdp:  We're settling with these formats: 0x80004 (ulaw|h263)
[May 26 05:46:23] DEBUG[859]: chan_sip.c:5245 process_sdp:  We have an owner, now see if we need to change this call
[May 26 05:46:23] DEBUG[859]: chan_sip.c:5250 process_sdp:  Oooh, we need to change our audio formats since our peer supports only 0x80004 (ulaw|h263) and not 0x400 (ilbc)
[May 26 05:46:23] DEBUG[859]: channel.c:2911 set_format:  Set channel SIP/2005-090ef910 to read format ilbc
[May 26 05:46:23] DEBUG[859]: channel.c:2911 set_format:  Set channel SIP/2005-090ef910 to write format ilbc
[May 26 05:46:23] DEBUG[859]: chan_sip.c:3026 update_call_counter:  Updating call counter for outgoing call
[May 26 05:46:23] DEBUG[859]: devicestate.c:303 __ast_device_state_changed_literal:  Notification of state change to be queued on device/channel SIP/2005
[May 26 05:46:23] DEBUG[859]: chan_sip.c:8034 build_route:  build_route: Contact hop: <sip:2005@;transport=udp>
list_route: hop: <sip:2005@;transport=udp>
[May 26 05:46:23] DEBUG[859]: chan_sip.c:5673 reqprep:  Strict routing enforced for session 6eae62d932eb57711d0fca3c7166208d@visioassistance.net
set_destination: Parsing <sip:2005@;transport=udp> for address/port to send to
set_destination: set destination to, port 1024
Transmitting (NAT) to
ACK sip:2005@;transport=udp SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK3a062fd1;rport

From: "Didier Chabanol -P test VP5500" <sip:2006@visioassistance.net>;tag=as755168e9

To: <sip:2005@;transport=udp>;tag=1180125417

Contact: <sip:2006@>

Call-ID: 6eae62d932eb57711d0fca3c7166208d@visioassistance.net

CSeq: 102 ACK

User-Agent: Centre Appel IVeS

Max-Forwards: 70

Content-Length: 0

Comments:By: Olle Johansson (oej) 2007-05-29 01:08:51

The code does not follow coding guidelines

By: Olle Johansson (oej) 2007-05-29 01:11:10

You are changing quite a lot of code, this is much more than a simple bug fix. This will have to be handled in the large call setup re-design together with videocaps, I think. We need to do a general overhaul of this code.

By: Emmanuel BUU (neutrino88) 2007-05-29 03:02:38

I agree with you regarding the need for general overhaul. But here we add no new functionnality. We just fix codec negociation. And this patch could be broken up into two pieces if needed:

1- fix for video codec negociation when endpoint share at least one video codec but no audio codec (asterisk transcode)

2- fix for final 200 OK answder when calling enpoind advertises more than one video codec.

Regarding 2. I admit that I make a creative use of ast_channel_option() in order to pass the negociated format from the oubound channel back to the incoming channel but this is no such big deal.

Also: some part of the code change is simply tracing improvment as codec negociation was really hard to troubleshoot (format of channel displayed in decimal, no debug trace on what I consider important decision in the code, etc.)

Would you reconsider your position in case I would propose such a break up?

By: Olle Johansson (oej) 2007-06-08 02:35:24

Yes, separating the patches would be great. Small patches move more quickly :-)

By: rayjay (rayjay) 2007-09-06 19:14:39

I'd like to add my support to get this one fixed please.  I have 3 different softphones that ALL come up as Unknown Codec when video is enabled and H263/H264 codecs are included in the SIP invite.  I get the same problem when calling between phones.  I get the error:

Unable to find a codec translation path from unknown to unknown

and calls drop... This bug has been in asterisk since 1.4.0 and now I want to start supporting Video properly it is causing me headaches!  I notice that it doesn't seem to affect X-Lite with Video enabled, so perhaps it is an SDP formatting issue on my other Softphones?

Here is a copy of my SDP info in the SIP INVITE if that helps?

o=userX 20000001 20000001 IN IP4
s=A call
c=IN IP4
t=1189075024 1189078624
m=audio 10600 RTP/AVP 3 111 102 8 0 124 123 101
a=rtpmap:3 GSM/8000/1
a=rtpmap:111 ILBC/8000/1
a=rtpmap:102 G726-64wb/16000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:0 PCMU/8000/1
a=rtpmap:124 AMR-WB/16000/1
a=rtpmap:123 AMR/8000/1
a=rtpmap:101 telephone-event/8000/1
a=AS:111 20
m=video 10702 RTP/AVP 34 31
a=rtpmap:34 H263/90000/1
a=rtpmap:31 H261/90000/1

By: Emmanuel BUU (neutrino88) 2007-09-07 02:39:02

Well, since then, we refined the patch and it became very complex as it now touches channel.c and translate.c.

Furthermore, we have manually merged T.140 support on 1.4.x branch so both patches are now so closely interdependent that this is a non trivial work to extract.

We are waiting for videocaps to be merged with trunk in order to review it and fix the video negociation if needed.

By: Emmanuel BUU (neutrino88) 2007-10-29 09:46:08

The last uploaded patch containts all the fixes against version 1.4.13.
It also contains merged T.140 support for 1.4.x branch.

By: andre valentin (avalentin) 2007-11-04 06:40:00.000-0600

I cannot decompress your patch. Could you check it or send to me via email: a.valentin@ddimension.net.

By: Olle Johansson (oej) 2007-11-05 06:33:31.000-0600

Please don't mix patches with other stuff from other branches. The bug tracker is for bug fixes and corrected code.

Please upload a clear patch, not an archive.

Thanks for your help.

By: rayjay (rayjay) 2007-11-08 03:45:49.000-0600

I tried applying this patch to 1.4.13 and although it helped resolve some of the video related codec issues - it seems to have broken some codec negotiation on standard voice calls so I had to back it out.  I have a SIP trunk to the PSTN for which I use G711 alaw and I have clients using ilbc/g729 etc. and after applying this patch calls started failing.  It seems the session progress message and OK messages did not match codec wise and the client rejected the OK which was repeatedly retransmitted and meant the call did not setup correctly and we ended up with one way audio before the call was finally torn down.

I'll try and get more info for you tomorrow, but it seems this patch breaks a whole lot more than it fixes (at least in our case).

By: Emmanuel BUU (neutrino88) 2007-11-08 04:18:25.000-0600


First, what caused the 183 call progress to be sent? Was it an Asterisk prompt or is it a 183 Session progress coming from your SIP trunk?

Second: as far as I know, codec negociated in call progress might be different from codec finally negociated in 200 OK. SIP client should accept that. The only limit is that call progress codecs should be compatible with both ends.

I am aware that we may have an issue with 183 Session Progress in the patch.

Please provide debug logs and send them to emmanuel.buu@ives.fr We will issue a corrected patch.

By: rayjay (rayjay) 2007-11-08 04:54:31.000-0600

We are both receiving 183 session progress from our SIP trunk and also generating our own 183 progress within asterisk (moh) for ringing in the Dial app.  I will try and retest again tomorrow and see if there is a difference when using 180 ringing vs. 183 session progress during call setup and get some debug to you to evaluate.

By: jmls (jmls) 2008-02-17 12:44:37.000-0600

rayjay, what was the outcome of your tests ?

By: Jason Parker (jparker) 2008-04-22 15:33:19

Suspending, per comments from oej.

Please reopen this issue if you can provide a patch (or patches, if they are for different things) without all of the unnecessary additions/changes.