Local Media Playback Operation

You configure the Oracle Communications Session Border Controller (SBC) to generate media locally by specifying the triggers and media files you need. The SBC monitors signaling traffic for playback triggers. For the most part, operation of the local media playback feature is the same regardless of the RTP generation method. Differences are explained herein.

The SBC allows for playback configurations on a session agent, realm and sip interface. It plays back media to a caller using the configuration 'closest' to that endpoint. The term 'closest' refers to the hierarchy by which the SBC selects the playback configuration to use for a given call. The hierarchy the SBC uses is session-agent, followed by realm, followed by sip-interface. To complete the notion of 'closest', consider the element's proximity to the end station initiating the call, to which the SBC sends the RTP.

For example, if the initiating end station is a session agent that includes a playback configuration, then the SBC would use that configuration. But if the endpoint is not a session agent or is a session agent without a playback configuration, the SBC would check that endstation's realm, then the sip-interface configurations to identify which, if any, playback trigger and media it would use.

Key operational detail on the RTP stream generated by the SBC playback function includes:

The SBC supports local media playback as RTP or SRTP streams over IPv4 and IPv6, using UDP transport and SIP.
The SBC supports local media playback over VLANs.
The generated RTP stream complies with all relevant RTP standards, including incrementing RTP timestamp and Sequence Number, and specifying a unique SSRC.
If applicable, the playback RTP stream appropriately maintains the Payload Type, SSRC, RTP timestamp and Sequence Numbers of the original media stream.
The SBC marks the first packet of the playback with the RTP marker bit.
If the SBC receives a SIP request, such as an UPDATE or REINVITE, that includes a new SDP offer and the p-acme-playback header, it waits to play the RBT until it receives a corresponding successful answer. This resolves the issue wherein it is unclear which codec to use to play RBT (originator, terminator, or both) because the answer is incomplete and the request may still be rejected.
For all triggers except the playback-on header trigger, the SBC does not create a playback stream if:
- The initial INVITE or the SIP reply contains the proprietary SIP header "P-Acme-RBT: no".
- The 18x response includes the "P-Early-Media:sendonly" or "P-Early-Media:sendrecv" parameter(s).
  
  Note:
  The SBC does play RBT if the 18x response has P-Early-Media set to "recvonly" or "inactive".
If playback is operating on a hairpin stream, and the scenario fires multiple playback triggers, the SBC plays the stream based on the configuration 'closest' to the destination.
Once playback is in progress, the SBC mutes the session in the playback direction so that only the playback media can be heard.

The SBC stops local media playback when:

It receives the final SIP answer from the callee, or
If you are using the 180-force or 180-no-sdp configuration, the callee has received a SIP UPDATE with SDP and has relayed it to the caller.

External signaling and other SBC configuration that impacts local media playback deployments include:

The SBC disables local media playback when configured to release media.
If both 2833 generation and playback are configured on a flow, the SBC gives precedence to the playback feature, disabling 2833 generation.
If you are using the 180-no-sdp configuration, the SBC has not received SDP from the callee, and the processed response does not contain SDP, the SBC adds SDP:
- The SBC chooses the codec based on the offer received, and after application of the ingress and egress codec policy.
- If the SBC has not received an offer at that time from caller (delayed offer scenario), the SBC disables local media playback.
When several early dialogs are received from the called party side, the SBC starts and stops local media playback based on the “active” early dialog. The active dialog is the last dialog for which the SBC received a provisional response.

Supported Local Media Triggers

The Oracle Communications Session Border Controller (SBC) can generate media locally based on end station signaling, local media playback configuration, and other SBC configuration.

Local media playback capabilities are dependent upon your choice of media generation method. Be aware of the few operational differences between these methods. Most new deployments use the transcoding-based method.

Deployments Configured for Transcoding Resources

The SBC supports the following playback triggers when configured for transcoding resources:

Playback on 180 Ringing
Playback on 180 Ringing when 180 does not include SDP
Playback on 183 Session Progress
Playback on REFER
Playback upon both 183 and REFER
Playback on header, where the header is P-Acme-Playback

You can also configure the SBC with:

HMR response code mapping: On the SIP call egress side, map a 183 into a 180 response, thereby triggering playback on 180 Ringing
Error announcement mapping: On the Session Router, map SIP error codes or Q.850 cause codes to playback files and enable the announcement-on-error for the egress realm or SIP interface. This uses transcoding resource to play network announcements toward the caller based on errors responses to the INVITE from the callee, but does not rely on the ringback-file or ringback-trigger parameters. See Network Announcements for 4xx/5xx/6xx Responses for more information.

Deployments Configured with SPL

The SBC supports the following playback triggers when configured with SPL:

Playback on 183 Session Progress
Playback on REFER
Playback on header, where the header is P-Acme-Playback

The SBC does not support the following operations for local media playback when configured with SPL:

SRTP
Call recording
SIPREC

Media Files

Media files of ringback tones are uploaded to /code/media to the SBC. This file differs based on your media generation method and must be raw media binary. For Transcoding based RBT, ensure that the files RAW PCM 16-bit MONO samples, sampled at 8-khz encapsulated with little-endian formatting and cannot exceed 4.8 MB.

When using the SPL method:

A separate file is required for each different codec type, even if the media itself is the same.
Your configuration must specify a playback rate in bytes per second, as this setting defines how many bytes of data per unit of ptime are needed.
To preserve system memory resources, media files are limited to 2MB.

Each media file can contain up to 5 minutes of playback data, no more.

Media Setup and Playback

For each session requiring media playback, the SBC sets up media that supports standard RTP parameters. From the original media (if present), the SBC preserves the synchronization source (SSRC), timestamp, and sequence number.

Playback duration varies depending on your configurations:

For local media playback configured with ringback-trigger, duration depends on the value of ringback-trigger. For most values of ringback-trigger, playback is continuous.
When you set ringback-trigger to playback-on-header, playback duration changes according to the settings in the P-Acme-Playback header. This header contains a duration=<ms-value|once|continuous> value, so you can customize the playback duration.

Playback timing options for playback-on-header include:
- Continuous: Media playback continues until the point at which the playback scenario defines its stop. The media file loops if it fails to cover the entire playback duration.
- Once: The file plays until either the playback scenario defines its stop or until the media file runs out.
- Ms-value: Playback continues for a specific duration (in milliseconds) and will loop if necessary.
For network announcements local media playback configured with error-announcement-map, the media file plays once, until the file runs out, or stops playing if the caller sends a CANCEL or a BYE.

The P-Acme-Playback Header

You can configure the SBC to generate RTP media on a media flow when a request or response contains the P-Acme-Playback header after media setup is complete. You can configure this playback on a realm-config, sip-interface, or session-agent with either media generation method.

The P-Acme-Playback header can be included, along with the file format, by the endpoint in any request or response. When the SBC receives a header, it starts or stops the media, based on the header's parameters. By default, the SBC stops playback on any final response.

The syntax of the header, including all of its possible parameters, is:

P-Acme-Playback: <start|stop>[;media=<media file name>][;duration=<ms-value|once|continuous>]
[;direction=<originator|terminator|both>][;stop-on-final-resp=<true|false>]

Header Element	Description
<start\|stop>	Required Defines starting and stopping playback. start: starts playback stop: stops playback
[;media=<media-name>]	Optional Defines the name of the playback configuration to play. If unspecified, the playback configuration that was triggered by the header will play.
[;duration=<ms-value\|once\|continuous>]	Optional Defines the duration of playback. If unspecified, the value will be taken from the playback-config that was triggered. ms-value: time value in milliseconds once: plays playback media one time continuous: loops the playback media
[;direction=<originator\|terminator\|both>]	Optional Defines the direction from which to play media. If unspecified, playback will begin in the realm, session agent, or SIP interface from which the header was received. originator: plays in the west flow (original caller) terminator: plays in the east flow (original callee) both: plays in both directions
[;stop-on-final-resp=<true\|false>]	Optional Defines whether or not to stop playing media upon the final response. If unspecified, this parameter is true. true: stops playback automatically on a final response false: stop only after a stop header is received or media terminated

Note:

Play back trigger playback-on-header does not work with other triggers like 180-force, 183.

Network Announcements for 4xx/5xx/6xx Responses

You can configure the SBC to use local media for network announcements toward the caller when the callee responds to the initial INVITE with a 4xx/5xx/6xx error, such as 486 (Busy Here) or 503 (Service Unavailable).

The SBC selects the announcement based on the mapping configured between a media file and the SIP response code, Q.850 cause code, or both.

These network announcements apply only to non-established audio calls for the initial INVITE transaction. The SBC doesn't play announcements in response to locally generated errors or requests (even if the response code matches a configured mapping), or for calls that are already connected.

Playback starts as soon as the triggering error message is received, and stops either when the entire file is played, or the caller sends a CANCEL, whichever comes first. After playback completes, the SBC forwards the error to the caller. If the caller sends a CANCEL before the playback completes, because the call is already in a final state from the callee's perspective, the SBC does not send a CANCEL to the callee.

The SBC uses DSP resources to generate RTP playback, for both transcoded and non-transcoded audio calls. For transcoded calls, the SBC uses existing DSP resources that are already allocated for the session, replacing the audio output with the announcement. For non-transcoded calls, the SBC allocates DSP resources only for the duration of announcement playback. The SBC supports only DSP-based transcoding for announcements, not software-based transcoding.

You enable network announcements for SIP interfaces or realms with the announcement-on-error parameter, with the realm configuration taking precedence. You map response codes to media files on the session router in the error-announcement-map configuration element (session agents are not relevant to the network announcement scenarios). These configurations are RTC-enabled.

For a given session, the SBC plays network announcements when:

The egress sip-interface or realm-id has announcement-on-error set to enabled.
The session is not yet established. (However, early media and PRACK can be established.)
The error or request is not internally-generated
The SIP response code or Q.850 cause code in the 4xx/5xx/6xx response matches one configured in the error-announcement-map.

Selecting the Network Announcement Media File

When announcement-on-error is enabled and the callee sends an error response to the initial audio invite, the SBC selects the appropriate file to play based on the error-announcement-map configured on the session router.

The SBC looks for a match as follows:

If the response contains both a SIP code and a Q.850 cause code, look for the mapping entry that matches both.
If no entry exists with both, look for the entry that matches the Q.850 cause code.
If no entry exists that matches the Q.850 cause code, look for the entry that matches the SIP response code.

For example, assume you have the following mapping configured:

error-announcement-map
        entries
                q850-cause-code       18
                announcement-file     no-response.pcm
        entries
                sip-response-code     480
                q850-cause-code       20
                announcement-file     not-reachable.pcm
        entries
                sip-response-code     487
                q850-cause-code       20
                announcement-file     switched-off.pcm
        entries
                sip-response-code     480
                announcement-file     unavailable.pcm

The following table maps which files the SBC plays for different combinations of SIP response code and Q.850 cause code.

SIP Response Code	Q.850 cause code	File played
480 (Temporarily unavailable)	None	No matching code combination (no Q.850 code). No matching Q.850 code. SIP response code matches, select unavailable.pcm.
480 (Temporarily unavailable)	20	SIP and Q.850 combination matches, select not-reachable.pcm.
480 (Temporarily unavailable)	18	No matching code combination. Q.850 code matches, select no-response.pcm.
480 (Temporarily unavailable)	17	No matching code combination. No matching Q.850 code. SIP response code matches, select unavailable.pcm.
487 (Request Terminated)	20	SIP and Q.850 combination matches, select switched-off.pcm.
483 (Too many hops)	18	No matching code combination. Matching Q.850 code, select no-response.pcm.

Logging for Network Announcements

The sipmsg.log, log.sipd, log.mbcd, and log.xserv files contain logs relevant to network announcements. To assist in troubleshooting, you can setting the logging level to DEBUG for the mbcd and xserv processes.

You can also use the show mbcd statistics and show mbcd errors commands to show playback statistics and errors applicable to network announcements and other local media playback.

Limitations for Network Announcements

The following feature interactions and limitations apply to local media playback of network announcements for 4xx/5xx/6xx errors:

The following scenarios do not support network announcements on errors:
- VoLTE/SRVCC
- Precondition/PEM/Gating
- Multiple early dialogs (MED)
- Parallel forking
- SRTP
- Microsoft Teams (Advanced Media Termination)
- Offerless INVITE and delayed offer
- Pooled transcoding
Because the SBC cannot determine if the callee has played their own call release announcement to the caller, two release tones may be played toward the caller, one from the SBC and another from the callee.
In SIPI interworking flows, the decision of the announcement file and status codes is based on the final outgoing message only.
When the flows toward the caller are in sendOnly/inactive mode, the SBC does not play announcements
In UPDATE interworking scenarios, when a callee supports 100rel and sends an updated SDP offer, the UPDATE can change media streams without explicitly informing the caller. In this case, the SBC determines the announcement (including whether to send it at all according to the sendrecv or inactive attribute) based on the most recent SDP negotiation, rather than the original INVITE.
Network announcements use DSP resources only, not software-based transcoding resources.

Considerations for HA Nodes

Standard configuration replication transfers the local media playback configurations between the active and standby systems. However, this does not include media playback files (in /code/media). You must load these onto the standby.

On switchover, for most RBT, media setup for playback is preserved, and negotiated codec and ptime for playback are transferred to the stand-by system in an HA node.

Because sessions that are not yet established are not maintained on switchover, media setup is not preserved or transferred for network announcements (configured with error-announcement-map), which the SBC sends only for non-established sessions.

After switchover, any playback in progress (for standard RBT and network announcements) does not continue on the newly active node, and all statistics are cleared on active and standby according to the guard timers.