Asterisk
  1. Asterisk
  2. ASTERISK-9528

[patch] major fix for SIP video codec negociations

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • Mantis ID:
      9815
    • Regression:
      No

      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.

      Emmanuel
      http://www.ives.fr

                • ADDITIONAL INFORMATION ******

      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 82.228.184.247:5128
      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 82.228.184.247:5128
      Peer video RTP is at port 82.228.184.247:5130
      [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@82.228.184.247:1024;transport=udp>
      list_route: hop: <sip:2005@82.228.184.247:1024;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@82.228.184.247:1024;transport=udp> for address/port to send to
      set_destination: set destination to 82.228.184.247, port 1024
      Transmitting (NAT) to 82.228.184.247:1024:
      ACK sip:2005@82.228.184.247:1024;transport=udp SIP/2.0

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

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

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

      Contact: <sip:2006@88.191.23.38>

      Call-ID: 6eae62d932eb57711d0fca3c7166208d@visioassistance.net

      CSeq: 102 ACK

      User-Agent: Centre Appel IVeS

      Max-Forwards: 70

      Content-Length: 0

      1. nego_video.patch
        13 kB
      2. report.patch.gz
        73 kB
        Emmanuel BUU

        Activity

        Hide
        rayjay added a comment -

        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).

        Show
        rayjay added a comment - 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).
        Hide
        Emmanuel BUU added a comment -

        Interesting.

        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.

        Show
        Emmanuel BUU added a comment - Interesting. 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.
        Hide
        rayjay added a comment -

        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.

        Show
        rayjay added a comment - 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.
        Hide
        jmls added a comment -

        rayjay, what was the outcome of your tests ?

        Show
        jmls added a comment - rayjay, what was the outcome of your tests ?
        Hide
        Jason Parker added a comment -

        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.

        Show
        Jason Parker added a comment - 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.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development