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.

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. The following table provides a matrix for maximum channels supported on DSP core and SPA-DSP and the complexity type:

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.

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.

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 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.[3]. 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 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 in the Configuring the Cisco DSP SPA for the ASR 1000 Series Aggregation Services Routers chapter.