[asterisk-bugs] [JIRA] (ASTERISK-4703) [patch][post 1.4] New codec negotiation algorithm

Alisher (JIRA) noreply at issues.asterisk.org
Thu Apr 14 00:58:56 CDT 2016


    [ https://issues.asterisk.org/jira/browse/ASTERISK-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230241#comment-230241 ] 

Alisher commented on ASTERISK-4703:
-----------------------------------

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.

> [patch][post 1.4] New codec negotiation algorithm
> -------------------------------------------------
>
>                 Key: ASTERISK-4703
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-4703
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: Core/CodecInterface
>            Reporter: Andriy I Pylypenko
>         Attachments: asterisk-11.13.0-codec-negotiation-20141006.diff.gz, asterisk-1.2.7.1-evade-transcoding.patch, asterisk.log.gz, codec_negotiation-20060614.diff, codecnegotiationPatch
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list