Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/CodecInterface
    • Labels:
      None
    • SVN Revision Number:
      34061
    • Mantis ID:
      4825
    • Regression:
      No

      Description

      I'm not sure is this new feature or bug fix so I'm submitting this as feature.

      I did some work on codec negotiation issue. Asterisk behaves far from perfect trying to negotiate codecs while some non-installed codecs is in use (for example G723 or G729). Asterisk can transparently bridge such RTP streams but not always reasonably does codec negotiation.

                • ADDITIONAL INFORMATION ******

      1. Algorithm of codec negotiation has changed. Information about codecs passed to ast_request() & friends now processed more carefully. This functionality is very important for example for SIP channels. The following changes was made:

      • In order for channels to have last chance to negotiate codecs before establishing connection the (*fixup_codecs)() callback added to ast_channel_tech structure.
      • SIP channel source code was cleaned up to simplify codec management.
      • Function ast_compatible_formats() was added (returns codecs that can be translated from/to given formats).

      Here is example why one may need the new algorithm.

      Suppose we have an Asterisk which have no G729 codec installed. One SIP UA supports G729 only. The other SIP UA supports G729 and PCMU and PCMU is preferred codec. First UA places call to second UA via Asterisk.

      In the current implementation the call progress looks as follows:

      UA1 -> Asterisk: INVITE UA2, codecs G729
      Asterisk -> UA2: INVITE UA2, codecs A, B, PCMU, C, G729, D (all enabled in sip.conf codecs are sent)
      UA2 -> Asterisk: OK, codec PCMU
      Asterisk drops call with messages:

      WARNING: channel.c:2333 ast_channel_make_compatible: No path to translate from ID1 to ID2
      WARNING: app_dial.c:1627 dial_exec_full: Had to drop call because I couldn't make ID1 compatible with ID2

      G729 codec is not present in Asterisk, so there is no way to convert it to PCMU. And we end up with call drop.

      New scenario is:

      UA1 -> Asterisk: INVITE UA2, codec G729
      Asterisk -> UA2: INVITE UA2, codec G729
      UA2 -> Asterisk: OK, codec G729
      Asterisk -> UA1: OK, codec G729

      So we have working connection. It has limitation that we cannot detect inband DTMF, but at least peers can talk.

      Another example - UA2 invites UA1:

      Current implementation:

      UA2 -> Asterisk: INVITE UA1, codecs PCMU, G729
      Asterisk -> UA1: INVITE UA1, codecs A, B, PCMU, C, G729, D
      UA1 -> Asterisk: OK, codec G729
      Asterisk drops call with the same messages as in previous example.

      New diagram is:

      UA2 -> Asterisk: INVITE UA1, codecs PCMU, G729
      Asterisk -> UA1: INVITE UA1, codecs PCMU, G729, A, B, C (A, B, C - codecs that translateable from/to PCMU)
      UA1 -> Asterisk: OK, codec G729
      Asterisk -> UA2: OK, codec G729

      Again we have limited but working connection.

      2. The ast_channel_tech.requester() now has `const struct ast_codec_pref *' as second parameter instead of simple bitmap. This gives us generic ability to inform channel not only about formats supported but we now have chance to pass information about most preferred codec requested by peer channel (it's first in the codec set). This change is rather trivial but massive.

      3. New member `bits' added to struct ast_codec_pref. Corresponding functions modified to support this field. The bits field contains bitmap of current codecs in codec set. Several functions for data manipulation in this struct were added:

      • ast_codec_pref_append_missing2()
      • ast_codec_pref_append_missing()
      • ast_codec_pref_init() (declaration was already there, implementation added now)
      • ast_codec_pref_set2()
      • ast_codec_pref_combine()
      • ast_codec_pref_remove2()
      • ast_codec_pref_dump()
        Suffix 2 in function names means that last parameter is set of codecs as bitmap.

      4. Channel capability checking moved to ast_request() function and removed in channels.

      5. Several bugfixes.

      a) Checks like:
      if (format != format_set)
      replaced with
      if (!(format & format_set))
      b) ast_getformatname() call replaced with ast_getformatname_multiple() call when appropriate
      c) In ast_codec_pref_append() function the local variable newindex was incorrectly initialized with -1 while it must be 0.
      d) In ast_codec_pref_convert() function the buffer overrun prevented.
      e) struct rtpPayloadType moved from rtp.c (and chan_h323.c) to rtp.h since it must be defined not only declared for chan_h323.c and chan_sip.c to compile.

      P.S. I did not patch channels/chan_vpb.c as I was unable compile at least with version vpb2-2.0.3.

        Activity

        Hide
        Michael van der Kolff added a comment -

        Well, I'm happy to try to update this to trunk, but does this patch actually have any chance of being integrated? Else the original maintainer (or someone connected to him) is still maintaining the patchset at b2bua.org.

        Cheers,

        Michael

        Show
        Michael van der Kolff added a comment - Well, I'm happy to try to update this to trunk, but does this patch actually have any chance of being integrated? Else the original maintainer (or someone connected to him) is still maintaining the patchset at b2bua.org. Cheers, Michael
        Hide
        Ovidiu Sas added a comment -

        The patch seems to be actively maintained by sippy:
        http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch

        It is available for both 1.2 and 1.4 version (check the Download section).

        Show
        Ovidiu Sas added a comment - The patch seems to be actively maintained by sippy: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch It is available for both 1.2 and 1.4 version (check the Download section).
        Hide
        Jason Parker added a comment -

        The development team has given the area of codec negotiation a lot of thought. It was actually a major item of discussion at the last developer conference. We have a lot of ideas in place, but the implementation that we would like to proceed with is different than what has been proposed here. While this issue has provided a nice patch that has been useful to people, I am going to close it out as we will be proceeding with a different approach.

        We are fully aware of the issues that need to be addressed. There is definitely a major lack in the entire area of codec negotiation - both pre-call, as well as changing codecs mid-call.

        This is something we would like to work on in the not-too-distant future - we want to give codec negotiation (audio and video) the overhaul it needs. While we will be taking a different approach, the information that has been presented here has been quite valuable, and will continue to be valuable as we progress towards this goal.

        Show
        Jason Parker added a comment - The development team has given the area of codec negotiation a lot of thought. It was actually a major item of discussion at the last developer conference. We have a lot of ideas in place, but the implementation that we would like to proceed with is different than what has been proposed here. While this issue has provided a nice patch that has been useful to people, I am going to close it out as we will be proceeding with a different approach. We are fully aware of the issues that need to be addressed. There is definitely a major lack in the entire area of codec negotiation - both pre-call, as well as changing codecs mid-call. This is something we would like to work on in the not-too-distant future - we want to give codec negotiation (audio and video) the overhaul it needs. While we will be taking a different approach, the information that has been presented here has been quite valuable, and will continue to be valuable as we progress towards this goal.
        Hide
        Andriy I Pylypenko added a comment -

        Hi,

        I want to return to the issue with the codec negotiation. The key component of the patch never reached the Asterisk code, so I'm re-submitting the patch. The idea was to pass the real codec list (which is now the ast_format_cap structure) from one channel to another so the other channel can make realistic assumptions about which codecs may and which may not be proposed on the second call leg. Another important information is what the most preferred codec is, in my previous patch this was the first codec in the list.

        Asterisk code now uses an ao2 container for that list so the task now is simpler. However the container is a hash and does not allow to keep ordered lists, so I've changed options to the ao2_container_alloc_options() call so that the container has only one bucket instead of default 283 and so it works now like a simple list.

        I'm attaching the asterisk-11.13.0-codec-negotiation-20141006.diff.gz file. It however works ok with Asterisk 11.16.0 too.

        Show
        Andriy I Pylypenko added a comment - Hi, I want to return to the issue with the codec negotiation. The key component of the patch never reached the Asterisk code, so I'm re-submitting the patch. The idea was to pass the real codec list (which is now the ast_format_cap structure) from one channel to another so the other channel can make realistic assumptions about which codecs may and which may not be proposed on the second call leg. Another important information is what the most preferred codec is, in my previous patch this was the first codec in the list. Asterisk code now uses an ao2 container for that list so the task now is simpler. However the container is a hash and does not allow to keep ordered lists, so I've changed options to the ao2_container_alloc_options() call so that the container has only one bucket instead of default 283 and so it works now like a simple list. I'm attaching the asterisk-11.13.0-codec-negotiation-20141006.diff.gz file. It however works ok with Asterisk 11.16.0 too.
        Hide
        Alisher added a comment -

        Hi I tested the patch with Latest Asterisk 11.22.0 version. It works fine for audio codecs, but audio codec translation doesn't work for video calls that use H.264 video codec. Asterisk tries to translate from ulaw to H264 or from h264 to audio codec and throws the errors.

        Show
        Alisher added a comment - Hi I tested the patch with Latest Asterisk 11.22.0 version. It works fine for audio codecs, but audio codec translation doesn't work for video calls that use H.264 video codec. Asterisk tries to translate from ulaw to H264 or from h264 to audio codec and throws the errors.

          Dates

          • Created:
            Updated:
            Resolved:

            Development