Overview of the Cisco DSP SPA for the ASR 1000 Series Aggregation Services Routers
This chapter provides an overview of the release history, features, and MIB support for the Cisco Voice SPA for the ASR 1000 Series on the Cisco ASR 1000 Series Aggregation Services Routers. The Cisco Voice SPA is also referred to as the SPA-DSP in this document.
Support for the Adaptive Multi-Rate Wideband (AMR-WB) feature was provided on the SBC on the Cisco ASR 1000 Series Aggregation Services Routers.
Cisco IOS XE Release 3.4.0S
Support for the termination and generation of Real-Time Transport Control Protocol (RTCP) on the SPA-DSP was added on the Cisco ASR 1000 Series Router. To enable the RTCP, the
command was introduced on the Cisco ASR 1000 Series Aggregation Services Routers.
Cisco IOS XE Release 3.3.0S
show voice dsp group all
command output was modified for SPA-DSP on the Cisco ASR 1000 Series Aggregation Services Routers.
Cisco IOS XE Release 3.2.0S
Introduced a new DSP SPA, for the ASR 1000 Series to enable transcoding and transrating services for voice.
Table 24-1is the software and hardware compatibility requirement matrix for installing a SPA-DSP:
Table 24-1 SPA-DSP Hardware and Software Requirements
Type of DSP SPA (Product ID)
ASR1000 Router Chassis supported
Route Processor supported
Minimum Cisco IOS XE Software Release supported
ASR 1002, ASR 1002-X, ASR 1004, and ASR 1006
RP1 and RP2
SIP10 and SIP40
ESP10, ESP40, and ESP100
Cisco IOS XE Release 3.2s
Rules for Installing SPA-DSP
This section provides detailed information about the rules for installing SPA-DSP on Cisco ASR 1000 Series Aggregation Services Routers. For installing a SPA-DSP, you need to adhere to the following rules.
1. The Cisco ASR 1000 Series Aggregation Services Routers must be installed with Advanced Enterprise Services K9 (AESK9) only.
Table 1-2 provides details regarding the feature set, Universal Software Image Part Number, and Technology Package License Part Number required for installation of SPA-DSP.
Table 24-2 Cisco ASR 1001 and ASR 1000 Series Chassis Software Images
For the equivalent feature set on ASR 1000 Series (ASR 1002-F/ASR 1002/ASR 1002-X/ASR 1004/ ASR 1006/ASR 1013)
To order Universal
Software Image Part Number
With Technology Package License Part Number
Advanced Enterprise Services K9 (AESK9)
2. Requires Cisco IOS XE Release 3.3.0S or later for all Cisco ASR 1000 Series Aggregation Services Routers including the Cisco ASR 1001 Router.
3. Requires one CUBE feature license.
Overview of the Cisco DSP SPA
The Cisco DSP SPA has been introduced on Cisco ASR 1000 Series Aggregation Services Routers to provide voice transcoding and transrating functionalities. The DSP SPA is a half-height SPA. The Product ID of DSP SPA is SPA-DSP. The SPA-DSP is a service SPA and does not have external physical interfaces on the front panel. The SPA-DSP has 21 Digital Signal Processors (DSPs) which perform the encoding and decoding of voice streams. The SPA-DSP works in conjunction with the SBC application to provide the voice transcoding and transrating functionalities. The CUBE (ENT) can also use the SPA-DSP for transcoding and transrating.
The SPA-DSP in the transcoder case, provides functionality to translate one type of media stream using a specific codec type to another type of media stream that uses a different type of codec technologies. This not only includes translation between differing codecs, but also functionality such as the translation between different packetization settings (transrating), and the ability to perform DTMF interworking.
The SBC on the Cisco ASR1000 Series Router, externally known as Cisco Unified Border Element, Service Provider - CUBE (SP) can be configured as a Unified SBC or as a Distributed SBC. When configured as a distributed SBC, the SPA-DSP can be used externally as a centralized resource for other SBCs.
High-Level System Details
Based on the type of operational management, the SPA-DSP functions can be divided into two modules: Data Plane and Control Plane.
The data plane module is responsible for processing and sending the data. The SPA-DSP does not have any interfaces towards the network. The DSPs on the SPA process the voice packets that they receive from the QFP side and send the transcoded voice packets back to the QFP.
After initial set up a boot image is uploaded to the SPA-DSP. The full SPA-DSP image is then uploaded and the SPA-DSP is controlled through the DSP control packets.
Note The SPA-DSP does not have a CPU or a hard disk.
Understanding Codecs and Maximum Channels Supported
Each SPA-DSP comprises of seven SP2603 DSP chips having a total of 21 DSP cores (3 DSP cores per SP2603). Based on the complexity of codec (low, medium, high), the density or maximum number of channels supported per DSP core and maximum channels supported per SPA-DSP are defined.
Table 1-3 provides a matrix for maximum channels supported on DSP core and SPA-DSP and the complexity type:
Table 24-3 Codec-Density-Supported Matrix
Codec Complexity or Service
Maximum Supported Density per DSP Core
Maximum Supported Density per SPA-DSP
LC (Low complexity) Voice/xcode
MC (Medium complexity) Voice/xcode
HC (High Complexity) Voice/xcode
Table 24-4 SPA-DSP-Supported Transcoding Codec List
G.711 A Law 64000 bps
G.711 u Law 64000 bps
G.723.1 5300 bps
G.723.1 6300 bps
G.726 16000 bps
G.726 24000 bps
G.726 32000 bps
G.726 40000 bps
G.729ab 8000 bps
G.729a 8000 bps
G.729b 8000 bps
G.729 8000 bps
The Cisco SPA-DSP for the ASR 1000 Series includes some of the following basic features:
Enhances the Cisco ASR 1000 Series Aggregation Services Router capabilities by providing DSP based voice transcoding and transrating solutions.
Translates one type of media stream (voice) to another type of media stream that uses different media encoding and decoding technologies.
Enables translation between different packetization settings (transrating), and provides DTMF interworking.
Provision to configure S/BC as a Unified SBC or Distributed SBC with on-board DSPs or as a centralized DSP providing transcoding for number of external SBCs.
Faceplates LEDs to indicate SPA status.
Voltage and temperature monitoring.
Supports online insertion and removal (OIR).
Provides a jitter buffer to be able to do packet loss concealment.
Enables transcoding of voice packets for IPv4 (VoIPv4) as well as IPv6 (VoIPv6).
Inband DTMF Interworking
The Dual-Tone Multifrequency (DTMF) dialing consists of simultaneous voice-band tones generated when a button is pressed on a telephone. The use of DTMF signaling for this feature enables support for advanced telephony services. Currently there are a number of application servers and service creation platforms that do not support media connections. To provide value-added services to the network, these servers and platforms need to be aware of signaling events from a specific participant in the call. Once the server or platform is aware of the DTMF events that are being signaled, it can use third-party call control, or other signaling mechanisms, to provide enhanced services. Examples of the types of services and platforms that are supported by this feature are various voice web browser services, Centrex switches or business service platforms, calling card services, and unified message servers. All of these applications require a method for the user to communicate with the application outside of the media connection. The DTMF Events Through SIP Signaling feature provides this signaling capability.
This feature is related to the SIP INFO Method for DTMF Tone Generation feature, which adds support for out-of-band DTMF tone generation using the SIP INFO method. Together the two features provide a mechanism to both send and receive DTMF digits along the signaling path. The SPA-DSP supports the detection and reporting of inband DTMF tones and their conversion to RFC2833 based DTMF tones or out-of-band signalling (and vice versa).
Note The SPA-DSP supports the conversion from RFC2833 DTMF tones to inband tones.
Managing Jitters for Voice Packets
This section explains how jitter in voice packets are managed by SPA-DSP to provide smooth flow of voice streams. Jitter is defined as the variation in the delay of received packets. In a packet-voice environment, the sender is expected to reliably transmit voice packets at a regular interval (for example, send one frame every 20 ms). These voice packets can be delayed throughout the packet network and not arrive at that same regular interval at the receiving station (for example, they might not be received every 20 ms). The difference between when the packet is expected and when it is actually received is defined as a jitter.
To handle the jitters, the SPA-DSP maintains a jitter buffer to store a certain amount of voice frames in the buffer and wait for the voice frames that arrive late. The jitter buffer size is determined by counting the number of packets that arrive late and creating a ratio of packets that late arriving to the number of packets that are successfully processed. This ratio can be used to determine the jitter buffer size that is used to calculate a predetermined and allowable later-packet ratio. After the jitter buffer is full with the specific voice packets, it plays all the RTP audio stream for VoIP in a steady stream to the SPA-DSP to be able to convert them into a steady audio stream.
Comfort Noise and Voice Activity Detection (VAD)
This section discusses about how to deal with voice packets and silence periods during a voice call. It also provides information about how these voice quality issues can be rectified by using the voice activity detection (VAD) feature. The IP-based telephony systems need a voice activity detector to detect silence periods in the voice signal and temporarily discontinue transmission of the signal during the silence period. This saves bandwidth and allows the far-end to adjust its jitter-buffer. The downside is that during silence periods, the far-end phone has to generate its own signal to play to the listener. Usually, comfort noise is played out to the listener to mask the absence of an audio signal from the far-end. Comfort noise is usually modeled on the far-end noise so that there is not a stark contrast when you switch from the actual background noise to the comfort noise.
There are two possibilities to which comfort noise is injected in a voice call. The foremost is the use of VAD. Whenever VAD kicks-in, comfort noise packets are introduced in the audio stream. The second possibility (not a major contributor) is the kicking-in of echo-cancellation. Whenever echo-cancellation becomes active, comfort noise packets are introduced in the audio stream. The characteristics of these comfort packets is determined through an algorithm which includes monitoring on-going speech and receiving a signature of the background noise.
The SPA-DSP provides VAD and comfort noise functionalities by default. You can enable the local VAD settings by using the
vad on override
command from the config-dspfarm-profile mode. Using the vad on override command will override the external VAD settings. To disable the local VAD settings, use the
vad off override
command from the config-dspfarm-profile command mode.
The restrictions for using the voice features on the SPA-DSP are:
From Cisco IOS XE Release 3.4.0S onwards, the SPA-DSP supports the termination and generation of RTCP data. The RTCP is a sister protocol of the Real-time Transport Protocol (RTP). RTCPs basic functionality and packet structure is defined in RTP specification RFC 3550, superseding its original standardization in 1996 (RFC 1889).
The primary functions of the RTCP are:
Provides out-of-band statistics and control information pertaining to the RTP flow.
Works in conjunction with the RTP in the delivery and packaging of multimedia data although the RTCP does not transport any media streams itself.
Sends the RTP on an even-numbered UDP, with the RTCP messages being sent, over the next highest odd-numbered port.
Provides feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session.
Gathers statistics for media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application can use the statistical details to control the QoS parameters, perhaps by limiting the RTP flow or using a different codec.
Understanding the RTCP Packet Types
The RTCP recognizes several types of packets, including—sender report, receiver report, source description, and bye packets. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of the RTCP is the Extended Report packet type introduced by RFC 3611..
The following provides description about the various RTCP Packet types:
Sender Report (SR): The SR is sent periodically by the active senders in a conference to report the transmission and reception statistics pertaining to the RTP packets sent during the interval. The SR includes an absolute timestamp, which is the number of seconds that have elapsed since midnight on January 1, 1900. The absolute timestamp allows a receiver to synchronize the RTP messages. It is particularly important when both audio and video are transmitted simultaneously, because audio and video streams use independent relative timestamps.
Receiver Report (RR): The RR is for passive participants, QoS those that do not send the RTP packets. The report informs the sender and other receiver about QoS.
Source Description (SDES): The SDES message is used to send the CNAME item to the participants of a session. The SDES can also be used to provide additional information, such as the name, e-mail address, telephone number, and address of the owner or controller of the source.
End of participation (BYE): A source sends a BYE message to shut down a stream. It allows an end point to announce that it is leaving the conference. Although, other sources can detect the absence of a source, this message is a direct announcement. It is also useful to a media mixer.
Application-Specific message (APP): The application-specific message provides a mechanism by which to design application-specific extensions for the RTCP.
The restrictions for implementing the RTCP service on the SPA-DSP in Cisco IOS XE Release 3.4.0S are:
The length of the CNAME in the RTCP packets sent by endpoints should not exceed 40 bytes.
If one endpoint does not send the RTP packets, the SPA-DSP neither generates the RTCP packets nor sends the RTCP packets to the other side.
Terminating and Generating the RTCP by the SPA-DSP
The termination and generation of the RTCP is done by the SPA-DSP. From Cisco IOS XE Release 3.4.0S onwards, the SPA-DSP can terminate and generate the RTCP data. When the RTCP Termination and Generation feature is configured using the rtcp-regenerate command, and if a transcoding-based call is established, the appropriate control signals are sent to the SPA-DSP to generate and terminate the RTCP.
When the SPA-DSP receives the RTCP packet, it processes the packet and effectively terminates it. The SPA-DSP then generates new RTCP packet for transmission, and populates them with the appropriate RTCP content based on the associated stream till the current date. The RTCP packets that are generated include sender and receiver reports, and SDES packets (only CNAME is supported currently). For information regarding the configuration procedure, refer to the “Configuring the RTCP on the SPA-DSP” section.
The following MIBs are supported in Cisco IOS XE Release 3.2 for the DSP SPA on Cisco ASR 1000 Series Routers:
Cisco-Specific Common MIBs
For more information about MIB support on a Cisco ASR 1000 Series Routers, refer to the
Cisco ASR 1000 Series Aggregation Services Routers MIB Specifications Guide
, at the following URL:
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to email@example.com
. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL: