Downloads |
Table Of Contents
Prerequisites for SIP Support for Media Forking
Restrictions for SIP Support for Media Forking
Information About SIP Support for Media Forking
Benefits of SIP Support for Media Forking
Voice Plus DTMF-Relay Media Streams
Multiple Codec Selection Order and Dynamic Payload Codecs
How to Configure SIP Support for Media Forking
Configuring Codec Complexity on Cisco 7200 Series Routers
Mapping Payload Types to Dynamic Payload Codecs
Configuring Multiple Codec Selection Order
Monitoring SIP Support for Media Forking
Verifying Codec Complexity Settings
Verifying Media Forking on SIP Calls
Troubleshooting SIP Support for Media Forking
Configuration Examples for SIP Support for Media Forking
SIP Network Using Media Forking Example
Edge Gateway Configuration Example
Party A Initial Call Setup Trace Example
Party B Initial Call Setup Trace Example
Party A Add Second Stream Trace Example
Party C Add Second Stream Trace Example
SIP Support for Media Forking
The SIP Support for Media Forking feature provides the ability to create midcall multiple streams (or branches) of audio associated with a single call and then send those streams of data to different destinations. The SIP Support for Media Forking feature allows service providers to use technologies such as speech recognition, voice authentication, and text-to-speech conversion to provide sophisticated services to their end-user customers. An example is a web-browsing application that uses voice recognition and text-to-speech (TTS) technology to make reservations, verify shipments, or order products.
Feature Specifications for SIP Support for Media Forking
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for SIP Support for Media Forking
•
•
•
•
Prerequisites for SIP Support for Media Forking
The following are general prerequisites for Session Initiation Protocol (SIP) deployment:
•
•
For more information about configuring IP, refer to the following document:
Cisco IOS IP Configuration Guide, Release 12.2
•
For more information about configuring VoIP, refer to the following document:
Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
The following are specific prerequisites for the SIP Support for Media Forking feature:
•
•
•
•
Restrictions for SIP Support for Media Forking
Unsupported Features in the SIP Support for Media Forking Feature
•
•
•
•
•
•
•
Restrictions on Codec Usage
•
•
•
Restrictions on Forking Functionality and Voice Feature Cards
•
–
–
For full functionality, the NM-HDV should be configured for high-complexity mode of operation.
•
•
Restrictions on DTMF-Relay
•
•
•
•
Restrictions on Media Streams
•
•
•
•
•
•
Information About SIP Support for Media Forking
To configure the SIP Support for Media Forking feature, it is helpful to understand the following concepts:
•
•
Benefits of SIP Support for Media Forking
The SIP Support for Media Forking feature allows service providers to deploy a core SIP network server and use technologies such as speech recognition, voice authentication, and text-to-speech conversion to provide sophisticated services to their end-user customers. Service providers use the multiple media streams provided by media forking to monitor the progress of customers through specific applications or requests, which in turn helps the customer transition easily from one facet of the application to another. One example is a web-browsing application that uses voice recognition and text-to-speech (TTS) technology to make reservations, verify shipments, or order products.
SIP media streams are created and deleted only through re-Invite messages; no CLI is required.
Overview of Media Streams
With the SIP Support for Media Forking feature you can create up to three Real-Time Transport Protocol (RTP) media streams to and from a single DS0 channel. In addition, separate gateway destinations (IP address or UDP port) are maintained for each of the streams. The streams are bidirectional; media received from the destination gateways are mixed in the DSP before being sent to the DS0 channel, and pulse code modulation (PCM) received from the DS0 is duplicated and sent to the destination gateways.
Originating gateways establish multiple media streams on the basis of Session Description Protocol (SDP) information included in midcall re-Invites received from a destination gateway, third-party call controller, or other SIP signaling entity. Only one SIP call leg is involved in media forking at the gateway, so the SIP signaling entity that initiates the re-Invites must be capable of aggregating the media information for multiple destinations (such as IP address, port number, payload types, or codecs) into one SDP description. Multiple m-lines in the SDP are used to indicate media forking, with each m-line representing one media destination.
Note
The ability to create midcall multiple streams (or branches) of audio associated with a single call and send those streams of data to different destinations is similar to a three-way or conference call. A media-forked call has some differences. For example, in a three-way call, each party hears all of the other parties. But in a media-forked call, only the originating caller (the controller) hears the audio (voice and DTMF digits) from all the other participants. The other participants hear audio only from the originating caller and not from each other.
Another difference between a three-way call and a media-forked call is that media streams can be configured on the gateway. Three-way calls send the audio to all of the other parties involved in the call. However, media-forking permits each media stream to be independently configured. For example, one media stream to one party may include both voice and DTMF digits, whereas another media stream to another party may include only DTMF digits.
The SIP Support for Media Forking feature supports three types of media streams: voice, DTMF-relay only, and voice plus DTMF-relay.
Voice Media Streams
Voice-only media streams send all audio from the DS0 channel, and the audio is encoded according to the selected codec. Voice-only media streams have the following characteristics:
•
•
•
•
DTMF-Relay Media Streams
DTMF-relay provides reliable digit relay between VoIP gateways and a standardized means of transporting DTMF tones in RTP packets. DTMF-relay media streams have the following characteristics:
•
•
•
•
Voice Plus DTMF-Relay Media Streams
Voice plus DTMF-relay media streams send both encoded voice and DTMF-relay packets and have the following characteristics:
•
•
•
•
•
•
•
Multiple Codec Selection Order and Dynamic Payload Codecs
When using multiple codecs you must create a voice class in which you define a selection order for codecs, and you can then apply the voice class to VoIP dial peers. The voice class codec global configuration command allows you to define the voice class that contains the codec selection order. Then you use the voice-class codec dial-peer configuration command to apply the class to individual dial peers.
If there are any codecs that use dynamic payload types (g726r16, g726r24), Cisco IOS software assigns the payload types to these codecs in the order in which they appear in the configuration, starting with the first available payload type in the dynamic range. The range for dynamic payload types is from 96 to 127, but Cisco IOS software preassigns the following payload types by default:
Because the payload types have been reserved by the default assignments shown in the table, Cisco IOS software automatically assigns 98 to the first dynamic codec in the dial-peer configuration, 99 to the second, and 102 to the third.
Some of these preassigned payload types can be changed with the modem relay (dial-peer) command. The modem relay (dial-peer) command allows changes to the available payload types that can be used for codecs.
For outgoing calls on the originating gateway, all of the codecs that are configured in the codec list used by the dial peer are included in the SDP of the Invite message.
On the terminating gateway, Cisco IOS software always uses the dynamic payload types that the originating gateway specified in the SDP of the Invite message. This practice avoids the problem of misaligned payload types for most call types. The exception is when a delayed-media Invite message is received. A delayed-media Invite can be used by a voice portal to signal a terminating gateway before re-Inviting a forking gateway. If a delayed-media Invite is used, the Invite message does not contain SDP information, and the terminating gateway must advertise its own codecs and payload types. It does this in the SDP of its response message (either a 183 or a 200 OK). The terminating gateway assigns payload types to dynamic codecs using the same rules as the originating gateway. However, if there is a difference in either the preassigned dynamic payload types or the order in which the dynamic codecs are listed in the codec list used by the dial peer, the payload types may not be assigned consistently on the originating and terminating gateways. If the terminating gateway selects a different payload type for a dynamic codec, the call may fail.
If a G.726 codec is assigned in the first active stream of the call, there are some scenarios in which the voice portal sends a delayed-media re-Invite message to the second or third terminating gateway. Then, it is necessary to ensure that the originating gateway and the second and third terminating gateways have the same preassigned payload types and the same order of dynamic codecs in the codec list for the dial peer being used for the call. Otherwise, the added media stream may be rejected by the originating gateway if the payload types do not match.
To configure codec selection order, perform the tasks described in the following sections:
•
•
Media Forking Applications
A web-browsing application that uses voice recognition and text-to-speech (TTS) technology to make reservations, verify shipments, or order products is a typical application of media forking. In Figure 1, a client (party A) uses a telephone to browse the web. Party A calls the voice portal (party B), and the call is routed through the originating gateway. The voice portal operates like a standard voice gateway and terminates calls to a voice response system that has voice recognition and TTS capabilities. This voice response system takes input from party A by DTMF digits or voice recognition and returns responses (for example, stock quotes retrieved from the web) to party A.
The voice portal, or party B, is also capable of third-party call control (3pcc) and can set up a call between party A and a third participant (party C) without requiring direct signaling between party A and party C. One example of a possible call between parties A and C is if party A found a restaurant listing while browsing the web and wanted to speak directly to the restaurant to make reservations.
Another feature of the voice portal is that once the call between parties A and C is established, the voice portal can continue to monitor the audio from party A. By doing so, the voice portal can terminate the connection between parties A and C when a preestablished DTMF digit or voice command is received. Party B retains the connection between itself and party A, in case party A has any further requests. Continuing with the restaurant example, the continuous connection is important if party A decides to query yet another restaurant. Party A simply goes back to the connection with party B, who sets up a call with the new restaurant.
Figure 1 Media Forking Application
Another important aspect of media forking is that although there can be more than one media destination, there is only one signaling destination (in this case, the voice portal). The call leg that was originally set up (from the originating gateway to the voice portal) is maintained for the life of the session. The media destinations are independent of the signaling destination, so media streams (or new destinations) can be added and removed dynamically through re-Invite messages. Media streams are created and deleted only through re-Invite messages rather than through any command-line interfaces (CLIs).
If you configure the timer receive-rtcp command for a gateway, a Session Initiation Protocol (SIP) media inactivity timer is started for each active media stream. The timer monitors and disconnects calls if no RTCP packets are received within a configurable time period. If any of the timers expire, the entire call is terminated—not just the stream on which the timer expired. If a stream is put on call hold, the timer for that stream is stopped. When the stream is taken off hold, the timer for that stream is started again.
There is a maximum of three VoIP media streams that can be established per call. Figure 2 shows the maximum number of streams.
Figure 2 Multiple Streams
Media Forking Initiation
Media forking is initiated by specifying multiple media fields (m-lines) in the SDP of a re-Invite message. The rules for adding and deleting multiple m-lines conform to RFC 2543, SIP: Session Initiation Protocol Appendix B.
Multiple streams are not created through command-line interfaces.
How to Configure SIP Support for Media Forking
See the following sections for configuration, monitoring, and troubleshooting tasks for this feature:
•
•
•
•
Configuring Codec Complexity on Cisco 2600 Series Routers, Cisco 3600 Series Routers, Cisco 37xx Routers, and Cisco AS5300 Routers
Configuring the correct codec complexity is required for media-forked calls. For the Cisco AS5300 access server, codec complexity is determined by the VCWare code that is loaded on the voice feature card (VFC). To download Cisco VCWare software, refer to the Cisco software download page.
Note
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Codec Complexity on Cisco 7200 Series Routers
On the Cisco 7200 series routers, codec complexity is configured on the DSP interface.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Mapping Payload Types to Dynamic Payload Codecs
The process used by Cisco IOS software to map payload types to dynamic payload codecs is important in media-forked calls because all media streams must use the same payload type.
VoIP dial peers can list codecs in two ways depending on whether a single codec or multiple codecs are to be assigned to the dial-peer. To configure a single codec in the dial-peer mode, perform the following steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Multiple Codec Selection Order
With multiple codecs you can create a voice class in which you define a selection order for codecs, and you can then apply the voice class to VoIP dial peers. The voice class codec global configuration command allows you to define the voice class that contains the codec selection order. Then you use the voice-class codec dial-peer configuration command to apply the class to individual dial peers.
You can configure more than one voice class codec list for your network. The codec lists should be configured and applied to one or more dial peers based on what codecs (and the order) you want supported for the dial peers. You need to define selection order if you want more than one codec supported for a given dial peer.
To configure codec selection order, perform the tasks described in the following sections:
•
•
Creating a Voice Class to Define Codec Selection Order
The order of preference for selecting a codec when the router negotiates with a destination router must be set.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Applying Codec Selection Order to a VoIP Dial Peer
To apply voice-class codec attributes to a VoIP dial peer, perform the following steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
dial-peer voice tag voip
Example:Router(config)# dial-peer voice 16 voip
Defines a VoIP dial peer and enters dial-peer configuration mode.
The tag argument value is a number that identifies the dial peer and must be unique on the router.
Step 4
voice-class codec tag
Example:Router(config-dial-peer)# voice-class codec 99
Assigns a previously configured codec selection preference list (codec voice class) to a VoIP dial peer. The configured codec selection is the voice class that you created in "Creating a Voice Class to Define Codec Selection Order" section.The value of the tag argument maps to the tag number created using the voice class codec global configuration command.
The voice-class command in dial-peer configuration mode is entered with a hyphen. The voice class command in global configuration mode is entered without the hyphen.
Step 5
exit
Example:Router(config-dial-peer)# exit
Exits dial-peer configuration mode.
Note
Monitoring SIP Support for Media Forking
To monitor codec selection order, perform the tasks described in the following sections:
•
•
Verifying Codec Complexity Settings
On a Cisco 2600 series router, Cisco 3600 series router, Cisco 37xx router, or a Cisco 7200 series router, the codec complexity can be verified by entering the show running-config command, which displays the current voice-card setting. If medium-complexity is specified, the codec complexity setting is not displayed. If high-complexity is specified, the setting codec complexity high is displayed. The following example shows an excerpt from the command output if high-complexity has been specified:
Building configuration...Current configuration : 1864 bytes!version 12.2service timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!!memory-size iomem 10voice-card 1codec complexity high!ip subnet-zero
Note
The following example shows an excerpt from the show voice dsp command, which displays the current status of all DSP voice channels, including codecs:
Router# show voice dspDSP#0: state IN SERVICE, 2 channels allocatedchannel#0: voice port 1/0, codec G711 ulaw, state UPchannel#1: voice port 1/1, codec G711 ulaw, state UPDSP#1: state IN SERVICE, 2 channels allocatedchannel#0: voice port 2/0, codec G711 ulaw, state UPchannel#1: voice port 2/1, codec G711 ulaw, state UPDSP#2: state RESET, 0 channels allocatedVerifying Network Dial Peers
Follow the procedure below to verify dial-peer configuration. To learn more about these commands, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, or the Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2.
To verify the network dial peers, enter the following command in privileged EXEC mode:
Router# show dial-peer voice sumdial-peer hunt 0AD PRE PASSTAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET PORT110 voip up up 555110. 0 syst ipv4:172.18.195.49210 voip up up 555330. 0 syst ipv4:172.18.195.49200 pots up up 5553300 0 2/0/1101 pots up up 5551100 0 2/0/0366 voip up up 366.... 0 syst ipv4:172.18.195.49Verifying Media Forking on SIP Calls
The following example shows the show sip-ua calls command. This command is used to display the user agent client (UAC) and user agent server (UAS) information on SIP calls. It includes information about each media stream, up to three media streams if it is a media-forked call. It is useful in debugging, because it shows if an active call is forked.
To verify the UAC and UAS information on SIP calls, enter the following command in privileged EXEC mode:
Router# show sip-ua callsSIP UAC CALL INFOCall 1SIP Call ID : 515205D4-20B711D6-8015FF77-1973C402@172.18.195.49State of the call : STATE_ACTIVE (6)Substate of the call : SUBSTATE_NONE (0)Calling Number : 555 0200Called Number : 5551101Bit Flags : 0x12120030 0x220000Source IP Address (Sig ): 172.18.195.49Destn SIP Req Addr:Port : 172.18.207.18:5063Destn SIP Resp Addr:Port: 172.18.207.18:5063Destination Name : 172.18.207.18Number of Media Streams : 4Number of Active Streams: 3RTP Fork Object : 0x637C7B60Media Stream 1State of the stream : STREAM_ACTIVEStream Call ID : 28Stream Type : voice-only (0)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : inband-voiceDtmf-relay Payload Type : 0Media Source IP Addr:Port: 172.18.195.49:19444Media Dest IP Addr:Port : 172.18.193.190:16890Media Stream 2State of the stream : STREAM_ACTIVEStream Call ID : 33Stream Type : voice+dtmf (1)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : rtp-nteDtmf-relay Payload Type : 101Media Source IP Addr:Port: 172.18.195.49:18928Media Dest IP Addr:Port : 172.18.195.73:18246Media Stream 3State of the stream : STREAM_ACTIVEStream Call ID : 34Stream Type : dtmf-only (2)Negotiated Codec : No Codec (0 bytes)Codec Payload Type : -1 (None)Negotiated Dtmf-relay : rtp-nteDtmf-relay Payload Type : 101Media Source IP Addr:Port: 172.18.195.49:18428Media Dest IP Addr:Port : 172.16.123.99:34463Media Stream 4State of the stream : STREAM_DEADStream Call ID : -1Stream Type : dtmf-only (2)Negotiated Codec : No Codec (0 bytes)Codec Payload Type : -1 (None)Negotiated Dtmf-relay : rtp-nteDtmf-relay Payload Type : 101Media Source IP Addr:Port: 172.18.195.49:0Media Dest IP Addr:Port : 172.16.123.99:0Number of UAC calls: 1SIP UAS CALL INFONumber of UAS calls: 0Troubleshooting SIP Support for Media Forking
To troubleshoot the SIP Support for Media Forking feature, perform the following steps:
•
•
Tip
•
–
–
–
–
•
Configuration Examples for SIP Support for Media Forking
This section provides the following configuration examples:
•
•
•
•
•
•
•
•
•
Note
SIP Network Using Media Forking Example
This section provides a configuration example for a sample SIP network that uses media forking. Figure 3 illustrates the sample network where Party A dials Party B (555-2201). The dial peer for Party B on the originating gateway points to the IP address of SIP_Tester, which is acting as the third-party call controller. The Invite message is sent to SIP_Tester, who then forwards it to Party B. The typical SIP protocol exchange takes place to set up the first stream of the call. The user information portion of the SIP URL for SIP_Tester is 9999, so the dial peers on Party B and Party C are configured with 9999.
SIP_Tester initiates the establishment of the second stream by sending an initial Invite message with no SDP to Party C. Party C rings the terminating phone and responds to SIP_Tester with cause code 183 and an SDP that advertises its media capability. When the terminating phone answers, Party C responds to SIP_Tester with a 200 OK. SIP_Tester creates a re-Invite message with two media lines (m-lines) and sends it to Party A, who creates the second stream to Party C. Party A responds with an ACK that contains its local media information in the SDP. SIP_Tester forwards the ACK with SDP to Party C. A forked call is established.
Figure 3 Sample SIP Network Using Media Forking
Edge Gateway Configuration Example
The edge gateway configuration is used to convert a Foreign Exchange Station (FXS) interface to a T1 interface. It is not involved in media forking or VoIP.
Building configuration...Current configuration : 4455 bytes!version 12.2no service single-slot-reload-enableservice timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!!logging rate-limit console 10 except errors!!voice-card 1!ip subnet-zero!!ip domain-name cisco.comip name-server 172.26.11.21!no ip dhcp-client network-discoveryisdn switch-type primary-dms100isdn voice-call-failure 0call rsvp-sync!!!controller T1 1/0framing esflinecode b8zspri-group timeslots 1-24!controller T1 1/1framing esflinecode b8zspri-group timeslots 1-24!!interface Serial1/0:23no ip addressno logging event link-statusisdn switch-type primary-dms100isdn incoming-voice voiceisdn T310 4000no cdp enable!interface Serial1/1:23no ip addressno logging event link-statusisdn switch-type primary-dms100isdn incoming-voice voiceno fair-queueno cdp enable!interface FastEthernet3/0ip address 172.18.193.136 255.255.0.0duplex autospeed auto!ip classlessip route 172.16.0.0 255.0.0.0 FastEthernet3/0no ip http server!!!!snmp-server packetsize 4096snmp-server manager!voice-port 1/0:23!voice-port 1/1:23!voice-port 2/0/0!voice-port 2/0/1!voice-port 2/1/0!voice-port 2/1/1!dial-peer cor custom!!!dial-peer voice 5552 potsdestination-pattern 5552...port 1/1:23prefix 5552!dial-peer voice 5555 potsdestination-pattern 5555101port 2/0/1!!line con 0exec-timeout 0 0transport preferred noneline aux 0line vty 0 4exec-timeout 0 0password lablogin!!endParty A Configuration Example
The following is the configuration for Party A.
Building configuration...Current configuration : 1864 bytes!version 12.2service timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!!memory-size iomem 10voice-card 1codec complexity high!ip subnet-zero!!ip domain-name cisco.comip name-server 172.26.11.21!isdn switch-type primary-dms100isdn voice-call-failure 0!!voice service voipsip!!!!!!!no voice hpi capture bufferno voice hpi capture destination!fax interface-type fax-mailmta receive maximum-recipients 0!controller T1 1/0framing esflinecode b8zs!controller T1 1/1framing esflinecode b8zspri-group timeslots 1-24!!!!interface Ethernet0/0ip address 172.18.193.14 255.255.0.0half-duplex
