----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4434/#review14518 -----------------------------------------------------------
Ship it! Ship It! - Joshua Colp On Feb. 20, 2015, 2:28 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4434/ > ----------------------------------------------------------- > > (Updated Feb. 20, 2015, 2:28 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24812 > https://issues.asterisk.org/jira/browse/ASTERISK-24812 > > > Repository: Asterisk > > > Description > ------- > > This patch addresses the following problems: > * ari/resource_channels: In ARI, we currently create a format capability > structure of SLIN and apply it to the new channel being created. This was > originally done when the PBX core was used to create the channel, as there > was a condition where a newly created channel could be created without any > formats. Unfortunately, now that the Dial API is being used, this has two > drawbacks: > (a) SLIN, while it will ensure audio will flows, can cause a lot of > needless transcodings to occur, particularly when a Local channel is created > to the dialplan. When no format capabilities are available, the Dial API > handles this better by handing all audio formats to the requsted channels. As > such, we defer to that API to provide the format capabilities. > (b) If a channel (requester) is causing this channel to be created, we > currently don't use its format capabilities as we are passing in our own. > However, the Dial API will use the requester channel's formats if none are > passed into it, and the requester channel exists and has format capabilities. > This is the "best" scenario, as it is the most likely to create a media path > that minimizes transcoding. > Fixing this simply entails removing the providing of the format > capabilities structure to the Dial API. > > * chan_pjsip: Rather than blindly picking the first format in the format > capability structure - which actually *can* be a video or text format - we > select an audio format, and only pick the first format if that fails. That > minimizes the weird scenario where we attempt to transcode between > video/audio. > > * channel: Fixed a comment. The reason we have to minimize our requested > format capabilities down to a single format is due to Asterisk's inability to > convey the format to be used back "up" a channel chain. Consider the > following: > > PJSIP/A => L;1 <=> L;2 => PJSIP/B > g,u,a g,u,a g,u,a u > > That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials > PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local > channel has inherited those format capabilities down the line; PJSIP/B > supports only ulaw. According to these format capabilities, ulaw is > acceptable and should be selected across all the channels, and no transcoding > should occur. However, there is no way to convey this: when L;2 and PJSIP/B > are put into a bridge, we will select ulaw, but that is not conveyed to > PJSIP/A and L;1. Thus, we end up with: > > PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B > g g X u u > > Which causes g722 to be written to PJSIP/B. > > Even if we can convey the 'ulaw' choice back up the chain (which through some > severe hacking in Local channels was accomplished), such that the chain looks > like: > > PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B > u u u u > > We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back > with only 'ulaw'. This results in all the channel structures being set up > correctly, but PJSIP/A *still* sending g722 and causing the chain to fall > apart. > > There's a lot of difficulty just in setting this up, as there are numerous > race conditions in the act of bridging, and no clean mechanism to pass the > selected format backwards down an established channel chain. As such, I > punted on improving this and simply updated the comment. > > * res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure. > Since ast_request already limits us down to one format capability once the > format capabilities are passed along, there's no reason to squelch it here. > The comment about bridge_softmix is a purely theoretical concern that should > not limit what the PJSIP stack does. > > > Diffs > ----- > > /branches/13/res/res_pjsip_sdp_rtp.c 431991 > /branches/13/res/ari/resource_channels.c 431991 > /branches/13/main/channel.c 431991 > /branches/13/channels/chan_pjsip.c 431991 > > Diff: https://reviewboard.asterisk.org/r/4434/diff/ > > > Testing > ------- > > The PJSIP SDP Offer/Answer tests all pass. Prior to this patch, we could set > up to 8 transcoding paths on a channel chain created by ARI; now, we have > none (if both far ends support the same formats). > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
