Asterisk
  1. Asterisk
  2. ASTERISK-8806

Cannot make compatible if video codecs do not match and audio codecs require transcoding

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • SVN Revision Number:
      54290
    • Mantis ID:
      9066
    • Regression:
      No

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

        Activity

        Hide
        Olle Johansson added a comment -

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

        Show
        Olle Johansson added a comment - The SIPura HAS to return a video media offer with port set to 0, so that's ok.
        Hide
        hristo added a comment -

        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.

        Show
        hristo added a comment - 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.
        Hide
        Olle Johansson added a comment -

        Reminder to myself

        Show
        Olle Johansson added a comment - Reminder to myself
        Hide
        jmls added a comment -

        reminder to oej

        Show
        jmls added a comment - reminder to oej
        Hide
        Emmanuel BUU added a comment -

        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

        Show
        Emmanuel BUU added a comment - 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
        Hide
        Tilghman Lesher added a comment -

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

        Show
        Tilghman Lesher added a comment - The right solution to this is actually to create a video transcoder. To do that, we need codec_* where the '*' is a video codec.
        Hide
        Joshua Colp added a comment -

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

        Show
        Joshua Colp added a comment - As this is a duplicate of 9815 I'm suspending it out, since the other one has much more progress.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development