Supported Playback Scenarios when using Transcoding-based media generation

These scenarios are defined by the ringback-trigger parameter you configure for session agents, realms, and SIP interfaces:

• none: The SBC does not perform local media playback procedures for this configuration. Based on precedence, however, the SBC may issue playback based on other element configurations. Local media playback follows the precedence session-agent, realm, then sip-interface.
• disabled: The SBC does not perform media playback procedures on this flow, regardless of ensuing configurations.
• 180-no-sdp: The SBC starts local media playback to the caller when a 180 is received without SDP, and a 18x with SDP has not yet been received. The SBC stops the playback:
  • On the final response, or
  • When the SBC receives an UPDATE with SDP from the callee.
• 180-force: The SBC starts local media playback to the caller when a 180 is received regardless of whether it includes SDP. The SBC stops the playback:
  • On the final response, or
  • When the SBC receives an UPDATE with SDP from the callee.
• 183: The SBC starts local media playback to caller when 183 is sent to call originator. The SBC stops the playback on the final response (either 2xx success or 4xx error). Configure this 183 value on the original INVITE ingress realm/sip-interface/session-agent.
• refer: The SBC starts local media playback to the referee when it receives a REFER. This trigger operates only if the SBC actually terminates and performs the refer operation. If the REFER is via proxy, playback is not a triggered. Playback stops when the refer operation is complete with a final response (200-299 or 400-699). Configure this refer value on the ingress realm/sip-interface/session-agent of the transferred call.
• 183-and-refer: The SBC starts local media playback when both 183 and refer triggers are activated.
• playback-on-header: The SBC starts or stops playback based on the presence of the P-Acme-Playback header and its definitions.

The SBC also uses transcoding resources when playing media files for network announcements according to your error-announcement-map and announcement-on-error configurations.

Supported Playback Scenarios for Network Announcements

The SBC supports network announcements, which also use transcoding resources, in the following scenarios:

• Transcoded calls: For calls that will be transcoded, the DSP resources are allocated at the INVITE stage. The SBC uses these resources for the announcement.
• Nontranscoded calls: For calls that will not be transcoded, there are no existing DSP resources to use. The SBC allocates the appropriate DSP resources to play the announcement, then releases them. This does not require transcoding-related codec-policy configuration (similar to standard local media playback.)
• Early media: The SBC supports announcements in early-media flows.

  If media negotiation is not complete when the error response arrives (such as when the 18x response does not include SDP or when the error arrives before the 18x response), the SBC injects SDP toward the caller to establish the media for the announcement, selecting a codec according to the ingress and egress codec policies.

• RBT: If the SBC is already playing other local media, such as RBT, when a configured error response arrives, the SBC stops the RBT playback and plays the announcement using the negotiated media parameters.
• SIP response maps: The SBC applies any configured sip-response-map before selecting the appropriate announcement file. For example, if the sip-response-map maps a 400 error to 405, then SBC uses the 405 code when checking the error-announcement-map.
• Local response maps: Because the SBC does not play network announcements in response to locally-generated errors, including diameter errors, any configured local-response-map has no impact on network announcements.
• SIPI interworking: For SIP-I calls, the SBC can use both SIP response codes and encapsulated Q.850 cause codes to select announcement files. This lets you differentiate announcements for the same SIP response based on ISUP release causes.
  • In SIPI to SIP calls, the SBC encapsulates the SIP response from the callee in an ISUP body, and uses the subsequent combination of the SIP response and Q.850 cause code to select the appropriate playback file.
  • In SIP to SIPI calls, the SBC removes the encapsulated ISUP body from the error response, and uses only the SIP code to select the appropriate playback file.
• Redirection, serial forking, and recursion: If the SIP request is redirected (with a 3xx), forked, or proxied to a string of locations, the SBC saves and refreshes media flows whenever it send the SDP answer to the caller, but waits for the final error in the chain before determining and playing the appropriate playback file. If multiple errors are received from forked endpoints, the best error response is selected based on the current SBC behavior.
• Transfers:
  • In attended transfers, because the transfer is considered a new call, if the transferring party has announcement-on-error enabled, and the transfer target responds with an error, the SBC plays announcements toward the transferring party.
  • In unattended transfers, because the transfer is not considered a new call, the SBC does not play announcements.
• Hairpin: As for standard local media playback, if hairpinning results in multiple playback triggers, the SBC uses the media configured closest to the destination.
• Mutiple m-lines: As for standard local media playback, if multiple audio m-lines or mixed m-lines appear, the SBC uses the first audio m-line.
• PRACK and UPDATE: If the caller sends an UPDATE or a PRACK while the announcement is playing, the SBC responds appropriately (either 200OK or 488 Not Acceptable Here, depending on the SDP scenario), and continues playing the announcement.
• CANCEL and BYE:
  • If the caller sends a CANCEL or a BYE and the callee responds with a 200OK, then sends an error, the SBC does not play the announcement. The 200OK is considered final.
  • If the caller sends a CANCEL or a BYE and the callee sends an error, then sends the 200OK, the SBC plays the announcement, forwards the 200OK, and then forwards the error to the caller.
  • If the caller sends a CANCEL or BYE while the announcement is playing, the SBC stops the announcement, responds with a 200OK, then forwards the error to the caller. Because the call is already finalized from the callee perspective, the the SBC does not send a CANCEL or BYE to the callee.

Supported Playback Scenarios when using SPL

These scenarios are defined by the SPL options parameters you configure for realms, session agents, and SIP interfaces. These differ slightly from the transcoding method, but support the same types of event for triggers.

For more information about configuring these options, see documentation on the Session Plug-in Language (SPL).

• playback-on-183-to-originator: Playback enabled upon the receipt of a 183 Session Progress destined for the originator and stops when a either a (200-299 or 400-699) final response is sent.
• playback-on-183-from-terminator: Playback enabled upon the receipt of a 183 Session Progress response is received from the terminator and stops when a (200-299 or 400-699) final response is received.
• playback-on-refer: Playback enabled for the caller being transferred when the SBC receives a REFER message that is locally terminated (i.e., processed on the SBC on REFER completion).
• playback-on-header: Starts or stops playback based on the presence of the P-Acme-Playback header and its definitions.

  Note:

  The SBC supports a maximum of 100 simultaneous playbacks when configured using the SPL method.