The SBC Core supports playing announcements, tones, and collecting digits.

Tone and Announcement Profile

Tones and announcements are configured by allocating a percentage of DSP cores to tones/announcements. If no transcoding is used, you may allocate up to 100% toward tones/announcements.

Refer to DSP Channel Densities for SBC 5000 and 7000 Series for a comparison of different DSP card configurations for SBC 5000 series and SBC 7000 systems.

When using an external PSX, the PSX returns the tones/announcement profile and announcement or tone to be played in policy/trigger response. The SBC plays out the specified announcement/tone using the specified profile.

Announcement files are stored in the directory: /var/log/sonus/sbx/announcements

For more information on configuring tones and announcements, see following:

Note

When the SBC is configured to use an external PSX, there may be instances when hunt groups, or Automatic Call Distribution (ACD) groups, do not always operate as expected when the Tone and Announcement profile is used. A call can remain on-hold even after answering the call. PSX 09.02.01R000 and later can be configured using the parameters End To End Ack and No CDR Change In End To End Ack to resolve this. End To End Ack must be enabled before enabling No CDR Change In End To End Ack flag. See PSX Manager User Guide for configuration details.

Tone Profile

The SBC supports a default tone package with a package ID of “1”. The default package contains the following default tone profile definitions.

  • defBusy
  • defCallWaiting1
  • defCallWaiting2
  • defCallWaiting3
  • defCallWaiting4
  • defCpeAlerting
  • defDial
  • defReorder
  • defRing
  • defSit1
  • defSit2
  • defSit3
  • fccBusy
  • fccDial
  • fccRingback

Tones are customized by provisioning tone packages and tone profiles. The tone profile feature supports tone generation methods as described in Table 1.

For details to configure tone profiles, see below:

Tone Profile Generation Methods

Tone Type

Tones

Frequency

Power

Details

Single Tone

1

0-3999 Hertz

(-50 to +3) dBm

 

Dual Tone

1, 2

0-3999 Hertz

(-50 to +3) dBm

 

Composite Tone

1, 2, 3, 4

N/A

N/A

  • Cadences to which each tone is applied
  • Decay time constant in milliseconds
  • Decay frequency delta in Hz/second
  • Decay tone bit map of tones against which decay/frequency rate change are applied

Modulated Tone

N/A

  • Carrier Frequency
  • Signal Frequency
  • Carrier Power
  • Signal Modulation Index
N/A

 

Local Ring Back Tones (LRBT)

The SBC Core is configurable to support LRBT as described below:

The SBC generates LRBT in the following conditions:

  • Start LRBT upon receipt of 180 without SDP, the SBC.
  • Halt LRBT upon receipt of any18x with SDP or any final response.
  • Stop LRBT without waiting for media packet arrival.

The SBC supports the following dynamic LRBT functionality related to RFC 3960:

  • Do not generate local ringing unless a 180 ringing response with SDP is received.
  • Generate local ringing if a 180 ringing is received but no incoming media packets are present from the UAS.
  • If incoming media packets are received from the UAS, play incoming packets and stop playing the tone.

When configured to operate with an external PSX, local ring back tones are provisioned on the PSX on a per-trunk group basis. The PSX returns this information in a policy response.

In a pass-through call scenario, the SBC is prevented from selecting the preferred codec of the ingress offer to play the LRBT. The ingress offer codec may differ from the early answer codec that is used for the end-to-end cut-through, and this change in codec can cause a media glitch to the ingress user. The SBC instead plays the LRBT with the same codec as the early answer codec that was received from egress (see the following call flow). The end-to-end cut-through also uses the codec that plays the LRBT. The codec used between early media and to play tones therefore remains consistent. 

Note

The call flow has the following configurations:

  • UAC and UAS supports PCMU and PCMA
  • Honor Remote Precedence is Enabled
  • LRBT is enabled

SBC LRBT Call Flow

${body}

Note

In a transcode call scenario, the SBC selects the preferred codec of the ingress offer to play the LRBT because there is no common codec between ingress and egress.

Note

CPU based T-SBCs does not support LRBT and Announcement.


Delayed Ring Back Tones (DRBT)

Delayed Ring Back Tones (DRBT) is when the SBC feeds a tone on receipt of a provisional response. However, it is delayed based on the monitoring criteria defined. When RTP/Media monitoring fails, (i.e. the SBC did not receive adequate RTP packets in the configurable monitoring timer window), the SBC will start generating early-media/tone locally. 

An optional variation of DRBT is to play the ring back tone only if a 180 was received. This covers the scenarios where there is no need to generate early-media/tone by SBC unless the peer is already in a ringing state. 

 

P-Early-Media and DLRBT

To use the Force Local Ring Back Tone (FLRBT) feature, set the PSX flag DelayedRBTWithToneContinuation to enabled.The flag is available under the entity Tone Generation Criteria > Delayed RBT in the PSX.

  • To create a Tone Generation Criteria entity with the flag DelayedRBTWithToneContinuation:
    create Tone_Generation_Criteria_Data Tone_Generation_Criteria_Id <string> Sequence_Number <int> [Response_Code <short>] [Attributes <int>] [Ingress_Tg <string>]

  • To update a Tone Generation Criteria entity with the flag DelayedRBTWithToneContinuation:
    update Tone_Generation_Criteria_Data Tone_Generation_Criteria_Id <string> Sequence_Number <int> [Response_Code <short>] [Attributes <int>] [Ingress_Tg <string>]

  • To delete a Tone Generation Criteria entity with the flag DelayedRBTWithToneContinuation:
    delete Tone_Generation_Criteria_Data Tone_Generation_Criteria_Id <string> Sequence_Number <int>

For more information on the flag DelayedRBTWithToneContinuation, refer to the PSX document Tone Generation Criteria Screen.


When a caller sends a SIP INVITE to the SBC (irrespective of the presence of "P-Early-Media: supported" header in the Session Description Protocol (SDP) of the INVITE), the SBC adds P-Early-Media header in its 18x (180 or 183) response towards ingress call leg only if:

  • The SBC monitors and detects early media from the egress call leg.

    Note

    The SBC has an "observation" window for monitoring the stream of RTP packets. It also has a "silence" window before it restarts monitoring, to reject RTP packets from a previous announcement.

  • The SBC plays a Ring Back Tone (RBT).

    Note

    The SBC plays LRBT only if it does not receive any early media from the egress call leg at the end of a monitoring cycle. If the SBC starts playing LRBT, it continues to play even if it detects RTP in the subsequent monitoring cycles, or exchanges a new set of SDP answers with the egress call leg.

    When the SBC receives an UPDATE from the egress call leg, and the caller (ingress call leg) does not support UPDATE, the SBC continues to feed tone in the same codec. When the ingress call leg supports UPDATE, the SBC feeds tone in a modified codec after a successful offer-answer negotiation.

Note

If the egress call leg responds with P-Early-Media header in its 18x response, the SBC transparently relays it to the ingress call leg.

Playing Tones as Announcements

The SBC Core supports playing announcements that are stored in G.711ULaw format. The SBC Core is enhanced to support playing compressed tones directly without allocating DSP resources by playing the tones from the pre-encoded files with various combinations of tones and codec types. The tone files are created for the required tone types with different codec combinations and stored as .wav files in the SBC. All these tones are stored with a ptime of 20 milliseconds.

The SBC Core includes the media profile tonesAsAnnouncement which uses the following parameters to configure the announcement file to play LRBT for each codec entry:

  • toneType
  • codecType
  • segmentId

The existing Tone Profile references the toneType in the tonesAsAnnouncement profile, whereas the new object toneCodecEntry references the codecType. With this enhancement, the user can associate default Tone Profile or can create a customized Tone Profile and assign it to the toneType of the toneAsAnnouncementProfile. The flag announcementBasedTones is included in toneAndAnnouncementProfile configuration to play LRBT without using DSP resources.

The SBC supports playing tones for eight groups of codecs. If the required tone playback falls under one of the following codecs and the flag annoucementBasedTones is enabled, the SBC must avoid allocating DSP resources and play a tone as an announcement. If the required tone playback does not fall under one of the following codecs and the flag annoucementBasedTones is enabled, the SBC does not fall back to the DSP mode and continues the call without playing the tones.

  • G.711 (G.711ALaw and G.711ULaw)
  • G.722
  • EVRC (EVRC, EVRC0, EVRCB, and EVRCB0)
  • amrwbBandwidthEfficient (AMR-WB-BWE, 9 variants)
  • amrwbOctetAligned (AMR-WB-OA, 9 variants)

  • amrBandwidthEfficient (AMR-NB-BWE, 8 variants)

  • amrOctetAligned (AMR-NB-OA, 8 variants)

  • EVS

Note

The SBC supports play tone as announcements for tone type defRing only.

Note

The SBC supports playing default ringtones with 45 different types of codec variants.

The compressed tone files are stored in the standard .wav file format. The SBC uses the same naming convention for the compressed tone files as the announcement files. For example, in a sDDDDD.wav file, where DDDDD is a decimal number from 1 to 65,535, the decimal number represents the segment ID of the file.

The announcement and the tone files share the 5-bit segment ID space, and thus, every file name must have a unique segment ID. The compressed tone files are stored in the same directory path as the announcement files (/var/log/sonus/sbx/announcements). The tone file is played continuously until the tone is stopped due to a trigger.

The following table provides the .wav file mapping information for the application announcements:

Application Announcements

${body}

File NameAnnouncement IDRBTAudio Message

s20001.wav

20001RBT_MULAWUS Ring Back Tone
s20002.wav20002RBT_ALAWUS Ring Back Tone
s20003.wav20003RBT_EVRC (interleaved mode)US Ring Back Tone
s20004.wav20004RBT_EVRCB (interleaved mode)US Ring Back Tone
s20005.wav20005RBT_AMRWBBE_6_6KUS Ring Back Tone
s20006.wav20006RBT_AMRWBBE_8_85KUS Ring Back Tone
s20007.wav20007RBT_AMRWBBE_12_65KUS Ring Back Tone
s20008.wav20008RBT_AMRWBBE_14_25KUS Ring Back Tone
s20009.wav20009RBT_AMRWBBE_15_85KUS Ring Back Tone
s20010.wav20010RBT_AMRWBBE_18_25KUS Ring Back Tone
s20011.wav20011RBT_AMRWBBE_19_85KUS Ring Back Tone
s20012.wav20012RBT_AMRWBBE_23_05KUS Ring Back Tone
s20013.wav20013RBT_AMRWBBE_23_85KUS Ring Back Tone
s20014.wav20014

RBT_EVRC0 (Header free packet mode)

US Ring Back Tone
s20015.wav20015RBT_EVRCB0 (Header free packet mode)US Ring Back Tone
s20016.wav20016RBT_AMRWBOA_6_6KUS Ring Back Tone
s20017.wav20017RBT_AMRWBOA_8_85KUS Ring Back Tone
s20018.wav20018RBT_AMRWBOA_12_65KUS Ring Back Tone
s20019.wav20019RBT_AMRWBOA_14_25KUS Ring Back Tone
s20020.wav20020RBT_AMRWBOA_15_85KUS Ring Back Tone
s20021.wav20021RBT_AMRWBOA_18_25KUS Ring Back Tone
s20022.wav20022RBT_AMRWBOA_19_85KUS Ring Back Tone
s20023.wav20023RBT_AMRWBOA_23_05KUS Ring Back Tone
s20024.wav20024RBT_AMRWBOA_23_85KUS Ring Back Tone
s20025.wav20025RBT_AMRNBBE_4_7KUS Ring Back Tone
s20026.wav20026RBT_AMRNBBE_5_9KUS Ring Back Tone
s20027.wav20027RBT_AMRNBBE_5_15KUS Ring Back Tone
s20028.wav20028RBT_AMRNBBE_6_7KUS Ring Back Tone
s20029.wav20029RBT_AMRNBBE_7_4KUS Ring Back Tone
s20030.wav20030RBT_AMRNBBE_7_95KUS Ring Back Tone
s20031.wav20031RBT_AMRNBBE_10_2KUS Ring Back Tone
s20032.wav20032RBT_AMRNBBE_12_2KUS Ring Back Tone
s20033.wav20033RBT_AMRNBOA_4_7KUS Ring Back Tone
s20034.wav20034RBT_AMRNBOA_5_9KUS Ring Back Tone
s20035.wav20035RBT_AMRNBOA_5_15KUS Ring Back Tone
s20036.wav20036RBT_AMRNBOA_6_7KUS Ring Back Tone
s20037.wav20037RBT_AMRNBOA_7_4KUS Ring Back Tone
s20038.wav20038RBT_AMRNBOA_7_95KUS Ring Back Tone
s20039.wav20039RBT_AMRNBOA_10_2KUS Ring Back Tone
s20040.wav20040RBT_AMRNBOA_12_2KUS Ring Back Tone
s20041.wav20041RBT_G722US Ring Back Tone
s20042.wav20042RBT_EVS_7_2KUS Ring Back Tone
s20043.wav20043RBT_EVS_8_0KUS Ring Back Tone
s20044.wav20044RBT_EVS_9_6KUS Ring Back Tone
s20045.wav20045RBT_EVS_13_2KUS Ring Back Tone

Note

The .wav files for tones other than g711 a and u law are in Ribbon proprietary format.

LMSD - Tone Play Support

The SBC supports playing tones when an Alert-Info (AI) header is received in the Legacy Mobile Station Domain (LMSD) format (Alert-Info: <http:/LMSD/tone?sig-id=rt>). The SBC is enhanced to play the LRBT without using DSP resources whenever it receives 180 with Session Description Protocol (SDP) answer with AI header (Alert-Info: <http:/LMSD/tone?sig-id=rt>). The Al header, present in the 180 ringing with SDP, carries the tone package information required by the SBC to play LRBT. To support this feature, the existing LRBT framework is enhanced.  

The SBC supports generating LRBT when:

  • The flag acceptAlertInfo is enabled on the egress TG.
  • The provisional response is 180 ringing with SDP and the tone flavor is normal.
  • The P-Com.DropEarlyMedia is present in the original INVITE but its values are false. 
  • The SDP answer is received in 180 or in a previous provisional response (183).
  • The 180 contains an AI header having sig-id = “rt” only (bt/ct does not play tone).
  • The flag announcementBasedTone in the toneAndAnnouncementProfile associated with the ingress TG is enabled.
Note

The SBC supports fallback to LMSD inter-working state, if the flag acceptAlertInfo is enabled and the playing tone is failed. If the flag acceptAlertInfo  is not enabled, the SBC continues to process the call without playing a tone.

LMSD - Playing Tones Using Lock Down Preferred Codec

The SBC plays tones using the “lock down" preferred codec when the following flags are enabled:

  • sendOnlyPreferredCodec (IPSP)
  • honorRemotePrecedence (PSP)
  • announcementBasedTones

The codec that is used for playing tone towards the ingress leg is based on whether the session is established as pass-through or transcoded. If the SBC receives SDP answer from the egress peer, the selected codec is the egress peer's preferred codec. However, the ingress peer's preferred codec is used to play the tone, if the session outcome is transcoding.

Note

The SBC plays tones when it receives 180 responses with SDP for the egress peer preferred codec. When the 180 response is received without SDP from the egress peer, the SBC plays LRBT based on the existing LRBT implementation using the ingress peer preferred codec.

LMSD - Handling UPDATEs for the Tones

 The SBC is enhanced to stop playing LRBT upon receipt of any of the following messages:

  • UPDATE message with different SDP
  • subsequent 183 with SDP
  • 200 OK with or without SDP

For more information on Tone and Announcement feature, refer to:

Alert-Info and P-Early Media Headers Interworking

The SBC supports the following AI to PEM interworking functionality using the flag aiToPemInterworking:

  • Interworking between a network supporting AI header (based on the Legacy Mobile Station Domain (LMSD) format) to a network supporting PEM header. The SBC supports interworking irrespective of the existence of a provisioned tone on the SBC.
  • Interworking between a network that does not support PEM header to a network that supports PEM header. For example, the ingress network supports PEM header; however, the egress network does not.
  • Interworking between networks that support PEM headers.
Note

Tone playing is not dependent upon AI and PEM headers interworking.

When a tone is configured on the SBC,

  • If the flag aiToPemInterworking is disabled, the SBC plays tone based on the LMSD format. For more information, refer to Tones and Announcements
  • If the flag aiToPemInterworking is enabled, the SBC supports interworking between AI and PEM headers. The SBC plays tone when it receives AI header with sig-id=rt in the 180 provisioning response (either first 180 response or subsequent 180 response) from the Mobile Switching Center (MSC) (CDMA network). 

    Note
    • When all the tone playing criteria are fulfilled, the SBC inserts PEM header as SENDRECV (PEM: SENDRECV) and sends it towards the ingress network.

    • When the SBC fails to play tone, the SBC inserts PEM header as INACTIVE (PEM: INACTIVE) and sends it towards the ingress network.

When tone is not configured on the SBC; and the IPSP flag acceptAlertInfo is enabled on the egress TG, and the INVITE message is received with PEM: SUPPORTED,

  • If the flag aiToPemInterworking is disabled, the SBC falls back to the existing LMSD interwoking functionality. For more information, refer to LMSD Interworking without Tones.
  • If the flag aiToPemInterworking is enabled, the SBC supports interworking between AI header (received in the LMSD format) and PEM header.
     

    Note
    • When the User-Agent Server (UAS) plays tone, the SBC inserts PEM header as SENDRECV (PEM: SENDRECV) and sends it towards the ingress network.
    • When the User-Agent Client (UAC) plays tone, the SBC inserts PEM header as INACTIVE (PEM: INACTIVE) and sends it towards the ingress network.

P-Early Media to Alert-Info Header Interworking

The SBC supports interworking between a network supporting PEM header to a network supporting Al header. To support this functionality, the flag aiToPemInterworking is used in the IP Signaling Profile. The SBC performs PEM to AI interworking once the 180 response is received with PEM header, while forwarding 180 response. If the peer does not explicitly provide early media authorization using a PEM header in 180 response with SDP answer, the SBC monitors the RTP traffic from the egress TG and performs a cut-through if RTP is received from the egress. To support this functionality, the flag monitorRTP is added to the SIP Trunk Group.

Note

In case of PEM to AI interworking, the PEM must be supported on the egress leg.   

Explicit Early-Media-Authorization or Gating

Explicit Early-Media-Authorization signifies that a given network publishes P-Early-Media header support in the INVITE request and requires "authorized" early media. These networks, unless explicit Early-Media-Authorization is received, discard early media from UAS. These networks expect the P-Early-Media header in the provisional responses from UAS to determine that early media received after this response is deemed to come from an authorized source.

  • Terminating network shall insert "P-Early-Media:sendrecv/sendonly" header to authorize the UAS to send early media.
  • Terminating network inserts "P-Early-Media:inactive/recvonly" header, to indicate that UAS is not authorized to send early media. 
  • However, there is ambiguity when P-Early-Media is not inserted by UAS in provisional response containing SDP answer and current early media authorization state is not known. In order to handle these scenarios, Ribbon SBC shall monitor RTP traffic from UAS for specific time duration (to acknowledge a continuous stream of RTP packets) and generate P-Early-Media based on whether (sufficient) RTP packets are received or not.

The SBC uses the following "early-media-authorization" status' on a per TG level:

  • When INVITE is sent to a peer that has P-Early-Media:Supported
    • "no" – on no dialog associated with this request P-Early-Media header was received
    • "e-no" – on dialog associated with this request P-Early-Media header was received as “recvonly”/”inactive”
    • "e-yes" – on dialog associated with this request P-Early-Media header was received as “sendonly”/”sendrecv”
    •  “yes”  – on no dialog associated with this request P-Early-Media header was received, however monitoring criteria was successful i.e. media is received at least once

  • When Alert-Info header is supported (based on accept_alert_info)
    • "no" – the most recent dialog associated with this request did not have Alert-Info header
    • "e-no" – the most recent dialog associated with this request has Alert-Info header set to “rt”
    • "e-yes" – the most recent dialog associated with this request has Alert-Info header set to “null”
    • “yes”  – the most recent dialog associated with this request did not have Alert-Info header, however monitoring criteria was successful i.e. media is received at least once

The default status of early media authorization status shall be "No".


Interworking between PEM and AI Headers

The SBC supports PEM to AI interworking when PEM header is supported on the Trunk Group towards which 180 provisional response message is received and acceptAlertInfo flag is enabled on the Trunk Group towards which 180 provisional response message is sent.

  • When the SBC receives 180 response with PEM header, while forwarding 180 response:  
    • if PEM is inactive and the SBC does not play tone, the SBC inserts AI header with sig-id=rt. 
    • if PEM is inactive and the SBC plays tone, the SBC inserts AI header with sig-id=null.
    • if PEM is sendrecv or sendonly independent of the SBC is configured to play tone or not, the SBC inserts AI header with sig-id=null.
  • When the SBC receives 180 response with PEM header, while forwarding 180 response:

    • In case of first 180 response without SDP and PEM is inactive:
      • if the SBC does not play tone, the SBC inserts AI header with sig-id=rt.
      • If the SBC plays tone, the SBC inserts AI:rt and MSC plays the local tone

    • In case of subsequent 180 response without PEM header, the SBC goes for monitoring based on the monitoring profile and delayed RBT configuration.
      • If monitoring fails, the SBC sends additional 180 response without SDP with AI:rt towards Ingress.
      • If monitoring is successful, then the SBC sends 180 without SDP with AI:null towards Ingress.

PEM to PEM Interworking

The SBC supports PEM to PEM interworking when PEM header is supported on the Trunk Group towards which 180 provisional response message is received and PEM is supported on the Trunk Group towards which 180 provisional response message is sent.

  • When the SBC is not configured to play tone:  
    • if the SBC receives 180 response with PEM header, while forwarding 180 response, the SBC relays the received PEM header towards ingress.
    • if the SBC does not receive PEM header, the SBC inserts PEM header based on the SDP direction in 180 provisional  response while forwarding 180 response towards ingress.
    • if the SBC does not receive PEM header and the flag monitorRTP is enabled, the SBC forwards 180 response without PEM and monitors RTP.
  • When the SBC is configured to play tone:
    • if the SBC receives an inactive PEM, the SBC inserts PEM sendrecv while forwarding 180 response towards ingress.
    • if the SBC does not receive PEM and the monitoring profile which is configured on EXT-PSX and attached to packet service profile is enabled, the SBC inserts PEM sendrecv provided any of the previous provisional response did not receive PEM while sending 180 response towards ingress.
    • if the SBC is configured to play tone (based on tone generation criteria) for sendrecv/sendonly, the SBC will feed tone immediately and monitor for RTP.
  • The SBC will play tone based on local configuration at the ToneAndAnnouncement profile on receipt of 180 with or without SDP with P-Early-Media (inactive) or without P-Early-Media and will continue to play tone (including the new negotiated codec) and monitor while playing tone when UPDATE is received.

Tone Generation Profile

 The SBC has flexibility for tone generation criteria, such as:

  • For the same provisional response message, the SBC shall trigger tone-generation in some scenarios and shall relay in other scenarios.
  • For the same provisional response message, the SBC shall trigger tone-generation based on monitoring result in some scenarios and shall trigger tone-generation immediately in other scenarios and based on early media authorization state.
  • The SBC shall generate tone, on receipt of 18x provisional response, based on P-Early-Media header contents. For some scenarios, this is also coupled with result of monitoring status. 

The toneGenerationCriteria profile specifies conditions under which tone is generated. The conditions are as follows:

  • Whether it is first or subsequent response
    • Response codes: 180 w/o SDP, 183 w/o SDP, 180 w/ SDP, 183 w/ SDP, any18x, 18x w/ SDP, 18x w/o SDP
  • whether it is received on "SDP-answered" dialog or not
  • status of Early-Media-Authorization and whether it is based on Alert-Info or P-Early-Media
  • Delayed RBT, or Delayed RBT only if 180 is ever received, or neither
  • whether P-Early-Media: supported is received in INVITE or not

Monitoring RTP

The SBC monitors the RTP packets when all or either of the following conditions are met.

  • when the SBC sends an INVITE with PEM=supported and an early media SDP answer (in any 18x response) is received without PEM header.
  • when the flag defaultGatingMethod is set as none. For more information on the flag defaultGatingMethod, refer to SIP Trunk Group - Media - CLI. 

Monitoring Profile

Monitoring functionality is enhanced to cover additional interworking scenarios and allows the flexibility to monitor more than one RTP packet. The basic criteria for monitoring to begin is an SDP answer received from peer.

The following configuration parameters are provided:

  • packets_for_authorization: specifies how many RTP packets must be received in the monitoring period for monitoring to succeed.
  • monitoring_period: this defines a monitoring period on the Egress RTP stream (UAS). RTP packets received are relayed during the monitoring period if the SBC media pin hole for the call is open. When the monitoring period expires, the count of the packets received is compared with the packets_for_authorization
  • silent_period: the SBC uses silent period based on the call state. It is used when the call has already been answered. It means an silent window is started to discount RTP packets of previous early media dialog that may arrive due to a prior 18x having SDP answer (a 180 w/o SDP received and a previous SDP was received in a 183), before triggering monitoring.
  • no_of_iterations: defines how many windows the monitoring period spans.

If the packets_received count in the monitoring period is:

  • >= packets_for_authorizationthe monitoring criteria is considered successful
  • < packets_for_authorizationthe monitoring criteria is considered a failure

CDMA

This section refers to calls originating from trunkgroups that support alert-info.

CDMA MSCs, that are deployed currently, have certain inherent limitations with regard to Early Media.

MSC’s exhibit the following behavior:

  • They are able to play local ring-back on receipt of first 180 w or w/o SDP independent of Alert-Info.
  • MSC shall be informed to switch to local tone on receipt of 180 w/o SDP if an earlier 183 w/ SDP is sent towards MSC. This functionality would be achieved by configuring DelayedRBT for 180 w/o SDP for CDMA-originated calls. The subsequent 180 w/o SDP must be indicated with an
    • Alert-Info:rt if no media is played by the far end or
    • Alert-Info:null if early media is played by far end.
  • An ambiguous case arises if P-Early-Media is not explicitly indicated (as peer does not support P-Early-Media), however early media is sent by the peer. SBC needs to generate a 180 w/o SDP with Alert-Info:null. This will cause the MSC to listen to the media from the far end. 
    • This scenario is also possible when 180 with SDP with Alert-Info header has already been sent to the MSC and now a UDPATE request is received. SBC needs to generate a local 180 w/o SDP with Alert-Info:null.

Playing Tone Locally

The SBC is enhanced to play LRBT locally without considering PEM header. To achieve this functionality, the flag withOrWithOutSdp is added to the toneAndAnnouncementProfile.

The SBC plays tone locally when it receives:

  • first 180 response without SDP and PEM header or with PEM=inactive.
  • first 180 response with SDP and PEM=inactive.
  • first 180 response with SDP is received without PEM header.
  • subsequent 180 responses without SDP and PEM header and the previous provisional response does not contain PEM header (even during an RTP monitoring).
  • subsequent 180 responses without SDP with PEM=inactive.
  • subsequent 180 responses with SDP and without PEM header or PEM=inactive and the previous provisional response does not contain PEM header (even during an RTP monitoring).
Note
  • The SBC does not play tone when 180 without SDP and PEM is received when a previous 18x response had PEM=sendrecv/sendonly.
  • The flag withOrWithOutSdp  is not available for Forced and Dynamic LRBT flavors.

SBC does not Stop Playing Tone when UPDATE is Received from the UAS

The SBC is enhanced to continue playing the ringback tone after receiving an UPDATE message from the User Agent Server (UAS), rather than stopping the tone. The SBC then monitors the egress leg, stops the tone, if it receives an RTP packet or 200 OK message and opening the audio path in both directions. The UAS sends an UPDATE message, a codec upgrade, or a media hold. If the UPDATE message is due to a codec upgrade, the SBC continues playing the ringback tone using the new codec. If the SBC is not configured to continue playing the ringback tone after UPDATE, the caller may hear a very short ringback tone followed by a long period of silence until the final response is received. To achieve this functionality, the flag monitorRtpOnEgressUpdate is added to the egressIpAttributes of the IP Signaling Profile.

The SBC supports early media authorization in UPDATE, 200 OK to UPDATE, and PRACK messages towards the Trunk Group that supports PEM. 

  • The SBC processes:
    • if PEM is received, the data path mode is set based on SDP direction attribute.
    • if PEM is not received in the egress UPDATE, the SBC relays the UPDATE towards the ingress without PEM.
    • if PEM is not received in 200 OK (UPDATE), the SBC does not add PEM header. It only adds PEM header in the 200 OK if UPDATE is received from the ingress with PEM: inactive or without PEM and the SBC is configured to play the tone.
  • The SBC receives and processes:
    • UPDATE without PEM and forwards UPDATE without PEM header, when SBC is not playing tone. 

    • UPDATE without PEM and forwards UPDATE with PEM=sendrecv header, when SBC is playing tone (when RTP monitoring is configured). 

    • if UPDATE is received on a leg, on which tone is being played, UPDATE is locally handled and tone is played with the new codec.
  • The SBC receives and processes:
    • 200 OK to UPDATE with PEM and relays 200 OK to UPDATE with PEM header.
  • The SBC processes the PEM header received in:
    • PRACK message and  relays PRACK with PEM header.
    • PRACK message and if PRACK message is received without PEM header, the SBC relays PRACK without PEM header.
  • The SBC is configured to play tone:
    • if UPDATE is received without PEM or PEM:inactive from egress, the SBC inserts UPDATE with PEM:sendrecv towards ingress.
    • If UPDATE is received with sendrecv/sendonly, the SBC switches tone play to new codec and monitors for RTP. If RTP is received, the SBC stops the tone and does a media cut through.