In this section:
The
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.
See DSP Channel Densities for SBC 5000 and 7000 Series for a comparison of different DSP card configurations for
Announcements are customized by provisioning announcement packages using Media Profile on the
When using an external PSX, the PSX returns the tones/announcement profile and announcement or tone to be played in policy/trigger response. The
Announcement files are stored in the directory: /var/log/sonus/sbx/announcements
For more information on configuring tones and announcements, see following:
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. Refer to the PSX Manager User Guide for configuration details.
Tone Profile
The
- 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 |
|
Modulated Tone | N/A |
| N/A |
Local Ring Back Tones (LRBT)
The
The
- Start LRBT upon receipt of 180 without SDP, the Unable to show "metadata-from": No such page "_space_variables".
- Halt LRBT upon receipt of any18x with SDP or any final response.
- Stop LRBT without waiting for media packet arrival.
The
- 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
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
In a transcode call scenario, the
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 the SBC unless the peer is already in a ringing state.
To use the Force Local Ring Back Tone (FLRBT) feature, set the PSX flag For more information on the flag When a caller sends a SIP The SBC monitors and detects early media from the egress call leg. 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). 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. 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.P-Early-Media and Delayed RBT
DelayedRBTWithToneContinuation
to enabled
. The flag is available under the entity Tone Generation Criteria
> Delayed RBT
in the PSX.DelayedRBTWithToneContinuation
:create Tone_Generation_Criteria_Data
Tone_Generation_Criteria_Id <string> Sequence_Number <int>
[Response_Code <short>] [Attributes <int>] [Ingress_Tg
<string>]
DelayedRBTWithToneContinuation
:update Tone_Generation_Criteria_Data
Tone_Generation_Criteria_Id <string> Sequence_Number <int>
[Response_Code <short>] [Attributes <int>] [Ingress_Tg
<string>]
DelayedRBTWithToneContinuation
:delete Tone_Generation_Criteria_Data Tone_Generation_Criteria_Id <string> Sequence_Number <int>
DelayedRBTWithToneContinuation
, refer to the PSX document Tone Generation Criteria Screen.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:
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
The SBC supports play tone as announcements for tone type defRing only.
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
File Name | Announcement ID | RBT | Audio Message |
---|---|---|---|
s20001.wav | 20001 | RBT_MULAW | US Ring Back Tone |
s20002.wav | 20002 | RBT_ALAW | US Ring Back Tone |
s20003.wav | 20003 | RBT_EVRC (interleaved mode) | US Ring Back Tone |
s20004.wav | 20004 | RBT_EVRCB (interleaved mode) | US Ring Back Tone |
s20005.wav | 20005 | RBT_AMRWBBE_6_6K | US Ring Back Tone |
s20006.wav | 20006 | RBT_AMRWBBE_8_85K | US Ring Back Tone |
s20007.wav | 20007 | RBT_AMRWBBE_12_65K | US Ring Back Tone |
s20008.wav | 20008 | RBT_AMRWBBE_14_25K | US Ring Back Tone |
s20009.wav | 20009 | RBT_AMRWBBE_15_85K | US Ring Back Tone |
s20010.wav | 20010 | RBT_AMRWBBE_18_25K | US Ring Back Tone |
s20011.wav | 20011 | RBT_AMRWBBE_19_85K | US Ring Back Tone |
s20012.wav | 20012 | RBT_AMRWBBE_23_05K | US Ring Back Tone |
s20013.wav | 20013 | RBT_AMRWBBE_23_85K | US Ring Back Tone |
s20014.wav | 20014 | RBT_EVRC0 (Header free packet mode) | US Ring Back Tone |
s20015.wav | 20015 | RBT_EVRCB0 (Header free packet mode) | US Ring Back Tone |
s20016.wav | 20016 | RBT_AMRWBOA_6_6K | US Ring Back Tone |
s20017.wav | 20017 | RBT_AMRWBOA_8_85K | US Ring Back Tone |
s20018.wav | 20018 | RBT_AMRWBOA_12_65K | US Ring Back Tone |
s20019.wav | 20019 | RBT_AMRWBOA_14_25K | US Ring Back Tone |
s20020.wav | 20020 | RBT_AMRWBOA_15_85K | US Ring Back Tone |
s20021.wav | 20021 | RBT_AMRWBOA_18_25K | US Ring Back Tone |
s20022.wav | 20022 | RBT_AMRWBOA_19_85K | US Ring Back Tone |
s20023.wav | 20023 | RBT_AMRWBOA_23_05K | US Ring Back Tone |
s20024.wav | 20024 | RBT_AMRWBOA_23_85K | US Ring Back Tone |
s20025.wav | 20025 | RBT_AMRNBBE_4_7K | US Ring Back Tone |
s20026.wav | 20026 | RBT_AMRNBBE_5_9K | US Ring Back Tone |
s20027.wav | 20027 | RBT_AMRNBBE_5_15K | US Ring Back Tone |
s20028.wav | 20028 | RBT_AMRNBBE_6_7K | US Ring Back Tone |
s20029.wav | 20029 | RBT_AMRNBBE_7_4K | US Ring Back Tone |
s20030.wav | 20030 | RBT_AMRNBBE_7_95K | US Ring Back Tone |
s20031.wav | 20031 | RBT_AMRNBBE_10_2K | US Ring Back Tone |
s20032.wav | 20032 | RBT_AMRNBBE_12_2K | US Ring Back Tone |
s20033.wav | 20033 | RBT_AMRNBOA_4_7K | US Ring Back Tone |
s20034.wav | 20034 | RBT_AMRNBOA_5_9K | US Ring Back Tone |
s20035.wav | 20035 | RBT_AMRNBOA_5_15K | US Ring Back Tone |
s20036.wav | 20036 | RBT_AMRNBOA_6_7K | US Ring Back Tone |
s20037.wav | 20037 | RBT_AMRNBOA_7_4K | US Ring Back Tone |
s20038.wav | 20038 | RBT_AMRNBOA_7_95K | US Ring Back Tone |
s20039.wav | 20039 | RBT_AMRNBOA_10_2K | US Ring Back Tone |
s20040.wav | 20040 | RBT_AMRNBOA_12_2K | US Ring Back Tone |
s20041.wav | 20041 | RBT_G722 | US Ring Back Tone |
s20042.wav | 20042 | RBT_EVS_7_2K | US Ring Back Tone |
s20043.wav | 20043 | RBT_EVS_8_0K | US Ring Back Tone |
s20044.wav | 20044 | RBT_EVS_9_6K | US Ring Back Tone |
s20045.wav | 20045 | RBT_EVS_13_2K | US Ring Back Tone |
The .wav
files for tones other than g711 a and u law are in
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 thetoneAndAnnouncementProfile
associated with the ingress TG is enabled.
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.
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 Tone playing is not dependent upon AI and PEM headers interworking. When a tone is configured on the SBC, If the flag 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 If the flag The SBC supports interworking between a network supporting PEM header to a network supporting Al header. To support this functionality, the flag 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. The SBC uses the following "early-media-authorization" status' on a per TG level: The default status of early media authorization status shall be "No". 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 When the SBC receives 180 response with PEM header, while forwarding 180 response: If the SBC plays tone, the SBC inserts AI:rt and MSC plays the local tone 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. The SBC has flexibility for tone generation criteria, such as: The toneGenerationCriteria profile specifies conditions under which tone is generated. The conditions are as follows: The SBC monitors the RTP packets when all or either of the following conditions are met. 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: If the packets_received count in the monitoring period is: 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: The SBC is enhanced to play LRBT locally without considering PEM header. To achieve this functionality, the flag The SBC plays tone locally when it receives: 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 The SBC supports early media authorization in UPDATE, 200 OK to UPDATE, and PRACK messages towards the Trunk Group that supports PEM. 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). aiToPemInterworking
:aiToPemInterworking
is disabled, the SBC plays tone based on the LMSD format. For more information, refer to Tones and Announcements. 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). acceptAlertInfo
is enabled on the egress TG, and the INVITE message is received with PEM: SUPPORTED,aiToPemInterworking
is disabled, the SBC falls back to the existing LMSD interwoking functionality. For more information, refer to LMSD Interworking without Tones. aiToPemInterworking
is enabled, the SBC supports interworking between AI header (received in the LMSD format) and PEM header.
P-Early Media to Alert-Info Header Interworking
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.
Interworking between PEM and AI HeadersacceptAlertInfo
flag is enabled on the Trunk Group towards which 180 provisional response message is sent.PEM to PEM Interworking
monitorRTP
is enabled, the SBC forwards 180 response without PEM and monitors RTP.Tone Generation Profile
Monitoring RTP
defaultGatingMethod
is set as none
. For more information on the flag defaultGatingMethod
, refer to SIP Trunk Group - Media - CLI. Monitoring Profile
CDMA
Playing Tone Locally
withOrWithOutSdp
is added to the toneAndAnnouncementProfile
. withOrWithOutSdp
is not available for Forced and Dynamic LRBT flavors.SBC does not Stop Playing Tone when UPDATE is Received from the UAS
monitorRtpOnEgressUpdate
is added to the egressIpAttributes
of the IP Signaling Profile.