-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4434/
-----------------------------------------------------------
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
