Transport Selection

https://wiki.asterisk.org/wiki/display/AST/PJSIP+Transport+Selection

FreePBX outbound CID using exten CID

same=>n,Set(USEROUTCID=${DB(AMPUSER/${src}/outboundcid)})
same=>n,Set(CALLERID(num)=${USEROUTCID})

Asterisk Codec

General Rules

1. For an inbound channel with a set of format capabilities, Asterisk should respond to that set of formats with the intersection of the offered capabilities and what is configured for the endpoint for that channel. The format preference order should be based on the configuration of the endpoint.
   1. If the system should accept a different set of codecs, a dialplan function and/or channel variable can be used to set which formats (and their preference order) are accepted on the channel at run-time. This would have to occur before the inbound channel is answered (via the MASTER_CHANNEL function and the U/M options in the dialplan).
   2. If the system would like to restrict in the device to a single format, a dialplan function and/or channel variable and/or configuration option can be set so that Asterisk will only ever respond with the preferred codec.
2. For an outbound channel, Asterisk should offer the formats that have been configured for that endpoint, with the format preference order based on the configuration of that channel's endpoint.
   1. If the system would like to restrict the outbound channel such that it only has a single format, a dialplan function/channel variable/configuration option can be used such that Asterisk only offers a single format.
3. Prior to entering a bridge, a dialplan function can be used to set whether or not that channel will attempt to make itself compatible with whatever is in the bridge with it. If a channel enters a bridge that has another channel in it with a format it supports, it will attempt to switch the channel to the bridged channel's format to facilitate native bridging. Note that this has no bearing in multi-party bridges, where everyone is transcoded.
4. At any point in time, a dialplan function can be used to set the allowed set of formats on the channel, with whatever ordering. These formats should be a subset of the allowed formats configured on that channel's endpoint. This will cause the channel to re-negotiate to the set of formats specified by the function.

The difference with this approach is that Asterisk will no longer always attempt to avoid transcoding. Instead, it will default to the rules configured in the .conf files, overriding as it can via the dialplan. Transcoding may be more likely in poorly configured systems, but it will also allow for much greater flexibility in the behaviour of Asterisk.

Single Channel

Nominal Offer/Answer (Single Media Stream)

Icon

Each of the tests with a Single Media Stream should be repeated for each media stream that a channel driver supports, i.e., audio, video, RTT, etc.

Offer Negotiation - Nominal

• Alice's phone offers some set of codecs in an INVITE request (example: ulaw,g729,ilbc), where all codecs are supported by Alice's endpoint
• Asterisk responds with an answer containing the codecs in the order specified by the offer

Icon

This should also verify various SDP offers:

1. Lack of rtpmap attributes for specific codecs, e.g., 0 implies ulaw (See Table 2, RFC 1890)
2. Non-standard rtpmap designations for codecs

While these could be considered "off-nominal", they are allowed by the various RFCs and should be covered under a 'nominal negotiation', where the set of codecs offered match completely with what is configured in Asterisk

Offer Negotiation - Subset (Alice)

• Alice's phone offers a set of codecs in an INVITE request, where a subset of the codecs is supported by Alice's endpoint and some subset is not
• Asterisk modifies the origin line in the SDP, and responds with the set of codecs that are allowed based on the intersection of the offered codecs and the configured codecs for the endpoint

Offer Negotiation - Subset (Asterisk)

• Alice's phone offers a set of codecs in an INVITE request, where the codecs offered is a subset of the codecs supported by Alice's endpoint
• Asterisk responds with an answer containing the codecs in the order specified by the offer

Offer Negotiation - Preferred Codec Only (Alice's preference)

• Alice's phone offers a set of codecs in an INVITE request, where all codecs are supported by Alice's endpoint
• Asterisk modifies the origin line in the SDP, and responds with only the preferred codec in the offer

Offer Negotiation - Preferred Codec Only (Asterisk's preference)

• Alice's phone offers a set of codecs in an INVITE request, where all codecs are supported by Alice's endpoint
• Asterisk modifies the origin line in the SDP, and responds with only the preferred codec configured via the dialplan/configuration file

Offer Negotiation - Preferred Codec List

• Alice's phone offers a set of codecs in an INVITE request, where all codecs are supported by Alice's endpoint
• Asterisk modifies the origin line in the SDP, and responds with a subset of the codecs in the offer re-ordered per the preference order defined via the dialplan/configuration file

Offer Negotiation - packetization

• Alice's phone offers a set of codecs in an INVITE request, where the preferred codec has a ptime attribute indicating a different packetization
• Asterisk responds with the codecs in the offer, and sends RTP to the endpoint with the appropriate packetization

Nominal Offer/Answer (Multiple Media Streams)

All use cases covered in Nominal Offer/Answer (Single Media Stream) apply here as well, save that there should be multiple streams of different types. Asterisk should treat the preferred codec offer in the same fashion for each stream independently; that is, if the preferred codec list is ulaw,g722,h261,h264, then the preferred audio codec is ulaw and the preferred video codec is h261.

Icon

Each of the following tests be repeated to include multiple media streams in various combinations:

• Audio + Video
• Video + Text
• Audio + Text
• Audio + Video + Text

Restricted Offer/Answer (Single Stream)

No codecs

• Alice's phone offers no codecs in an INVITE request with an SDP.
• Asterisk responds with an equivalent answer.

Restricted flow

• Alice's phone offers a set of codecs in an INVITE request, where the media is set to sendonly (phone => Asterisk)
• Asterisk responds with the codecs in the offer, where the media is set to recvonly.

Restricted Offer/Answer (Multiple Streams)

Each scenario in Restricted Offer/Answer applies, only with both an audio stream as well as a video stream. Either or both stream can be indicated to be sendonly, or can be sent with no codecs.

Invalid Format Offer/Answer (Single Stream)

Offer Invalid Codec (one)

• Alice's phone offers a set of codecs in an INVITE request, where at least one codec is not supported by Alice's endpoint
• Asterisk responds with the subset of the codecs that were offered that it does support, using the preference order of the offer

Offer Invalid Codec (all)

• Alice's phone offers a set of codecs in an INVITE request, where none of the codecs are supported by Alice's endpoint
• Asterisk responds with a 488.

Offer Invalid Attribute

• Alice's phone offers a set of codecs, where additional attributes are provided that are invalid:
  • An invalid rtpmap attribute for an unknown media format
  • An invalid attribute (or unknown attribute) for a known media format
  • An improperly formatted media description line
• Asterisk responds with a 488.

Invalid Format Offer/Answer (Multiple Stream)

All of the scenarios in Invalid Format Offer/Answer apply, only with a single audio and a single video stream. Streams can be declined, or the entire offer can be declined with a 488 as appropriate.

Multiple Channels

Nominal Offer/Answer

• Alice sends an INVITE request with an offer containing a set of codecs. The offer is a complete match with the set of codecs configured for Alice's endpoint.
• Asterisk dials Bob. Bob's endpoint is configured with the same set of codecs, in the same order.
• Bob's response to the INVITE request contains the same set of codecs as the offer. Asterisk responds to Alice with her set of configured codecs.
• Alice and Bob are bridged using the same formats, with the same priority order.

Preferred codec only

Preferred codec only in outbound answer

• Alice sends an INVITE request with an offer containing a set of codecs. The offer is a complete match with the set of codecs configured for Alice's endpoint.
• Asterisk dials Bob with his endpoint's codecs.
• Bob's response contains only a single codec. Asterisk uses that format for Bob's channel.
• Alice's reply contains her codecs in the order specified by her endpoint.

Preferred codec only in inbound answer

• Alice sends an INVITE request with an offer containing a set of codecs configured for Alice's endpoint.
• The dialplan restricts Asterisk to responding only with Alice's preferred codec.
• Asterisk dials Bob with his endpoint's codecs.
• Bob responds with an acceptable set of codecs.
• Asterisk sends an answer to Alice's offer with only her endpoint's preferred codec.

Transcoding

Acceptable translation path

• Alice sends an INVITE request with an offer containing a set of codecs configured for Alice's endpoint.
• Asterisk dials Bob with his endpoint's codecs, where the codecs for Bob's endpoint are not the same as Alice's but have an acceptable translation path.
• Bob answers with his endpoint's codecs.
• Asterisk sends an answer to Alice's offer with the codecs for her endpoint.
• Alice and Bob enter a bridge together and their media is transcoded based on the current formats sent by their endpoints.

Failed translation path (no path exists)

• Alice sends an INVITE request with an offer containing a set of codecs configured for Alice's endpoint.
• Asterisk determines that there is no translation path between the codecs configured for Alice and the codecs configured for Bob
• Alice's offer is rejected; Bob is not dialled.

Failed translation paths

• Alice sends an INVITE request with an offer containing a set of codecs configured for Alice's endpoint
• Asterisk dials Bob with his endpoint's codecs, where the codecs for Bob's endpoint are not the same as Alice's. For each codec that does not have a translation path to Alice's codecs, those codecs are not offered.
• Bob responds with one of this acceptable codecs. Asterisk responds to Alice with her codecs.
• Alice and Bob enter a bridge together and their media is transcoded based on the current formats sent by their endpoints.

Re-Invite to Native Bridge

Nominal

• Alice sends an INVITE request with a different ordered set of codecs than Bob.
• Alice's channel is set to re-INVITE back to native bridging if possible.
  Icon
  

  Variants to test: Bob's channel being set to re-INVITE back to a native bridge, as well as both channels being set to re-INVITE.
• Asterisk dials Bob with his set of codecs in his endpoint's priority order.
• Bob responds back with a set of codecs. The set of codecs should have at least one format in common.
• Asterisk Answers Alice with her preferred codecs.
• Alice and Bob enter a bridge together. Asterisk sends a re-INVITE to Alice and to Bob with the formats that are in common.
• Alice and Bob respond to the re-INVITE with a 200 OK
• Asterisk switches to a native bridge

Failed re-INVITE

• Alice sends an INVITE request with a different ordered set of codecs than Bob.
• Alice's channel is set to re-INVITE back to native bridging if possible.
  
  
• Asterisk dials Bob with his set of codecs in his endpoint's priority order.
• Bob responds back with a set of codecs. The set of codecs should have at least one format in common.
• Asterisk Answers Alice with her preferred codecs.
• Alice and Bob enter a bridge together. Asterisk sends a re-INVITE to Alice and to Bob with the formats that are in common.
• Alice responds to the re-INVITE with a failure response (488)
  Icon
  

  Variants to test: Bob rejects the re-INVITE; both Alice and Bob reject the re-INVITE
• Asterisk sends an UPDATE request (if Alice/Bob support it) with the previous SDP (see RFC 6337, section 3.4)
• Asterisk transcodes media between Alice and Bob

Modified outbound invite

• Alice sends an INVITE request with a set of codecs.
• Prior to dialling Bob, PJSIP_MEDIA_OFFER modifies which codecs will be offered. (Alternatively, the CHANNEL function in a pre-dial handler)
• Asterisk sends an INVITE request with the codecs specified, regardless of whether or not Bob's endpoint supports them.
  Icon
  

  This scenario should test sending Bob both acceptable codecs for his endpoint, as well as codecs that are unsupported.

Modified inbound response

• Alice sends over an INVITE request with a set of codecs.
• Prior to being answered, the CHANNEL function changes what media formats are accepted. Note that this must be a subset of what Alice's endpoint accepts.
• Asterisk responds with the formats the CHANNEL function specified