In this section:
The
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/evlog/announcements
For more information on configuring tones and announcements, see following:
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.The
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:
The
The
The
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:
In a transcode call scenario, the
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 seven 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.
amrwbOctetAligned (AMR-WB-OA, 9 variants)
amrBandwidthEfficient (AMR-NB-BWE, 8 variants)
amrOctetAligned (AMR-NB-OA, 8 variants)
The SBC supports playing default ringtones with 41 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:
The .wav
files for tones other than g711 a and u law are in Sonus proprietary format.
The SBC supports playing tones when an Alert-Info 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 Alert-Info header (Alert-Info: <http:/LMSD/tone?sig-id=rt>). The Alert-Info 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:
acceptAlertInfo
is enabled on the egress TG.announcementBasedTone
in the toneAndAnnouncementProfile
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.
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.
The SBC is enhanced to stop playing LRBT upon receipt of any of the following messages:
For more information on Tone and Announcement feature, refer to:
The SBC supports the following Alert-Info to P-Early Media interworking functionality using the SIP trunk group flag Tone playing is not dependent upon Alert-Info and P-Early Media headers interworking. These functionalities interact with each other based on the Trunk Group and Signaling profile configuration on the SBC, to which tone profile is configured and attached: When a tone is configured on the SBC, If the flag When all the tone playing criteria are fulfilled, the SBC inserts P-Early Media header as SENDRECV (P-Early Media: SENDRECV) and sends it towards the ingress network. When the SBC fails to play tone, the SBC inserts P-Early Media header as INACTIVE (P-Early Media: INACTIVE) and sends it towards the ingress network. When tone is not configured on the SBC; and the IPSP flag If the flag aiToPemInterworking
:aiToPemInterworking
is disabled on the egress TG, the SBC plays tone based on the LMSD format. For more information, refer to Tones and Announcements. aiToPemInterworking
is enabled on the egress TG, the SBC supports interworking between Alert-Info and P-Early Media headers. The SBC plays tone when it receives Alert-Info 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 P-Early Media: SUPPORTED,aiToPemInterworking
is disabled on the egress TG, the SBC falls back to the existing LMSD interwoking functionality. For more information, refer to LMSD Interworking without Tones. aiToPemInterworking
is enabled on the egress TG, the SBC supports interworking between Alert-Info header (received in the LMSD format) and P-Early Media header.