ARI/PJSIP: Apply requesting channel's format cap to created channels

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.

* 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.

* 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, the
  best that can be done at this point in time is clarifying the comment.

Review: https://reviewboard.asterisk.org/r/4434/

ASTERISK-24812 #close
Reported by: Matt Jordan
........

Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 4 insertions, 3 deletions

diff --git a/main/channel.c b/main/channel.c
index f8ae442b9..b35a2fad4 100644
--- a/main/channel.c
+++ b/main/channel.c
@@ -5886,9 +5886,10 @@ struct ast_channel *ast_request(const char *type, struct ast_format_cap *request
 			return NULL;
 
 		/* XXX Only the audio format calculated as being the best for translation
-		 * purposes is used for the request. This needs to be re-evaluated.  It may be
-		 * a better choice to send all the audio formats capable of being translated
-		 * during the request and allow the channel drivers to pick the best one. */
+		 * purposes is used for the request. This is because we don't have the ability
+		 * to signal to the initiator which one of their codecs that was offered is
+		 * the one that was selected, particularly in a chain of Local channels.
+		 */
 		joint_cap = ast_format_cap_alloc(AST_FORMAT_CAP_FLAG_DEFAULT);
 		if (!joint_cap) {
 			return NULL;