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-duplexfair-queue 64 256 235ip rsvp bandwidth 7500 7500!interface Ethernet0/1no ip addressshutdownhalf-duplex!interface Serial1/1:23no ip addressno logging event link-statusisdn switch-type primary-dms100isdn incoming-voice voiceno cdp enable!ip classlessip route 0.0.0.0 0.0.0.0 172.18.193.1no ip http server!!call rsvp-sync!voice-port 1/1:23!!mgcp profile default!dial-peer cor custom!!!dial-peer voice 2100 voipdestination-pattern 55521..session target ipv4:172.18.193.88!dial-peer voice 2200 voipdestination-pattern 55522..session protocol sipv2session target ipv4:172.18.207.18:5062dtmf-relay rtp-ntecodec g711ulaw!dial-peer voice 9999 voipdestination-pattern 9999session protocol sipv2session target ipv4:172.18.207.18:5062!dial-peer voice 5557 potsdestination-pattern 55571..direct-inward-dialport 1/1:23!sip-uaretry invite 3retry response 3retry bye 3retry cancel 3timers trying 501!!line con 0exec-timeout 0 0transport preferred noneline aux 0line vty 0 4password labloginline vty 5 15login!no scheduler allocate!endParty B Configuration Example
The following is the configuration for Party B.
Building configuration...Current configuration : 1769 bytes!version 12.2service timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!!memory-size iomem 10clock timezone gmt 1ip subnet-zero!!ip domain-name cisco.comip name-server 172.26.11.21!!!interface FastEthernet0/0ip address 172.18.193.88 255.255.0.0no ip mroute-cacheduplex autospeed autofair-queue 64 256 235no cdp enableip rsvp bandwidth 7500 7500!ip classlessip route 0.0.0.0 0.0.0.0 172.18.193.1no ip http server!snmp-server engineID local 00000009020000107BDC8FA0snmp-server community public ROsnmp-server packetsize 2048call rsvp-sync!voice-port 1/0/0no supervisory disconnect lcfo!voice-port 1/0/1no supervisory disconnect lcfo!dial-peer cor custom!!!dial-peer voice 2100 potsdestination-pattern 5552100port 1/0/0!dial-peer voice 2101 potsdestination-pattern 5552101port 1/0/1!dial-peer voice 2200 potsdestination-pattern 5552200port 1/0/0!dial-peer voice 2201 potsdestination-pattern 5552201port 1/0/1!dial-peer voice 9999 voipdestination-pattern 9999session protocol sipv2session target ipv4:172.18.207.18:5062codec g711ulaw!sip-uaretry invite 3retry response 3retry bye 3retry cancel 3timers trying 501!!line con 0exec-timeout 0 0transport preferred noneline aux 0line vty 0 4password labloginline vty 5 15login!!endParty C Configuration Example
The following is the configuration for Party C.
Building configuration...Current configuration : 1638 bytes!version 12.2service timestamps debug datetime msecservice timestamps log uptimeno service password-encryption!!memory-size iomem 10ip subnet-zero!!ip domain-name cisco.comip name-server 172.26.11.21!!!interface Ethernet0/0ip address 172.18.193.80 255.255.0.0half-duplexfair-queue 64 256 235ip rsvp bandwidth 7500 7500!interface Ethernet0/1no ip addressshutdownhalf-duplex!ip classlessip route 0.0.0.0 0.0.0.0 172.18.193.1no ip http server!!call rsvp-sync!voice-port 1/0/0no supervisory disconnect lcfo!voice-port 1/0/1no supervisory disconnect lcfo!!dial-peer cor custom!!!dial-peer voice 3100 potsdestination-pattern 5553100port 1/0/0!dial-peer voice 3101 potsdestination-pattern 5553101port 1/0/1!dial-peer voice 3200 potsdestination-pattern 5553200port 1/0/0!dial-peer voice 3201 potsdestination-pattern 5553201port 1/0/1!dial-peer voice 9999 voipdestination-pattern 9999session protocol sipv2session target ipv4:172.18.207.18:5062dtmf-relay rtp-ntecodec g711ulaw!sip-uaretry invite 3retry response 3retry bye 3retry cancel 3!!line con 0exec-timeout 0 0transport preferred noneline aux 0line vty 0 4exec-timeout 0 0password lablogintransport input noneescape-character BREAKline vty 5 15login!!endParty A Initial Call Setup Trace Example
The following is the initial call setup trace for Party A using the debug ccsip message command.
*Mar 1 00:32:02.431: Sent:INVITE sip:5552201@172.18.207.18:5062;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.193.14:5060From: "5555101" <sip:5555101@172.18.193.14>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>Date: Mon, 01 Mar 1993 00:32:02 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14Supported: timer,100relMin-SE: 1800Cisco-Guid: 27401485-351474124-2149117103-281843893User-Agent: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEMax-Forwards: 6Timestamp: 730945922Contact: <sip:5555101@172.18.193.14:5060;user=phone>Expires: 180Allow-Events: telephone-eventContent-Type: application/sdpContent-Length: 299v=0o=CiscoSystemsSIP-GW-UserAgent 2763 7166 IN IP4 172.18.193.14s=SIP Callc=IN IP4 172.18.193.14t=0 0m=audio 16412 RTP/AVP 0 100 101c=IN IP4 172.18.193.14a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20*Mar 1 00:32:02.499: Received:SIP/2.0 183 Session ProgressVia: SIP/2.0/UDP 172.18.207.18:5062From: "5555101" <sip:5555101@172.18.193.14;user=phone>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14CSeq: 101 INVITERequire: 100relRSeq: 5413Contact: <sip:9999@172.18.207.18:5062;user=phone>Content-Type: application/sdpContent-Length: 223v=0o=SIP_Tester 1239625037 1770029373 IN IP4 172.18.207.18s=SIP Prot Test Callt=0 0m=audio 17236 RTP/AVP 0 100c=IN IP4 172.18.193.88a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20*Mar 1 00:32:02.539: Sent:PRACK sip:9999@172.18.207.18:5062;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.193.14:5060From: "5555101" <sip:5555101@172.18.193.14>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagDate: Mon, 01 Mar 1993 00:32:02 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14CSeq: 102 PRACKRAck: 5413 101 INVITEContent-Length: 0*Mar 1 00:32:02.563: Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: "5555101" <sip:5555101@172.18.193.14;user=phone>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14CSeq: 102 PRACKContact: <sip:9999@172.18.207.18:5062;user=phone>Content-Length: 0*Mar 1 00:32:03.609: Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: "5555101" <sip:5555101@172.18.193.14;user=phone>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14CSeq: 101 INVITEContact: <sip:9999@172.18.207.18:5062;user=phone>Content-Type: application/sdpContent-Length: 223v=0o=SIP_Tester 1239625037 1770029374 IN IP4 172.18.207.18s=SIP Prot Test Callt=0 0m=audio 17236 RTP/AVP 0 100c=IN IP4 172.18.193.88a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20*Mar 1 00:32:03.633: Sent:ACK sip:9999@172.18.207.18:5062;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.193.14:5060From: "5555101" <sip:5555101@172.18.193.14>;tag=1D556B-24F1To: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagDate: Mon, 01 Mar 1993 00:32:02 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14Max-Forwards: 6Content-Length: 0CSeq: 101 ACKParty B Initial Call Setup Trace Example
The following is the initial call setup trace for Party B using the debug ccsip message command. Also, call status is displayed with the show sip-ua calls command.
*Mar 1 00:43:13.655: Received:INVITE sip:5552201@172.18.193.88;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>Date: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 487666621@172.18.207.18Supported: 100relCSeq: 101 INVITEContact: <sip:9999@172.18.207.18:5062;user=phone>Content-Type: application/sdpContent-Length: 278v=0o=SIP_Tester 1818337819 831652457 IN IP4 172.18.207.18s=SIP Prot Test Callt=0 0m=audio 16452 RTP/AVP 0 100 101c=IN IP4 172.18.193.14a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20*Mar 1 00:43:13.683: Sent:SIP/2.0 100 TryingVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 00:43:13 gmtCall-ID: 487666621@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContent-Length: 0*Mar 1 00:43:13.715: Sent:SIP/2.0 183 Session ProgressVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 00:43:13 gmtCall-ID: 487666621@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITERequire: 100relRSeq: 5450Allow-Events: telephone-eventContact: <sip:5552201@172.18.193.88:5060;user=phone>Content-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 243v=0o=CiscoSystemsSIP-GW-UserAgent 1886 7999 IN IP4 172.18.193.88s=SIP Callc=IN IP4 172.18.193.88t=0 0m=audio 17936 RTP/AVP 0 100c=IN IP4 172.18.193.88a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20*Mar 1 00:43:13.779: Received:PRACK sip:5552201@172.18.193.88;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 487666621@172.18.207.18CSeq: 102 PRACKRAck: 0 101 INVITEContent-Length: 0*Mar 1 00:43:13.791: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 00:43:13 gmtCall-ID: 487666621@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 102 PRACKContent-Length: 0*Mar 1 00:43:17.251: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 00:43:13 gmtCall-ID: 487666621@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContact: <sip:5552201@172.18.193.88:5060;user=phone>Content-Type: application/sdpContent-Length: 243v=0o=CiscoSystemsSIP-GW-UserAgent 1886 7999 IN IP4 172.18.193.88s=SIP Callc=IN IP4 172.18.193.88t=0 0m=audio 17936 RTP/AVP 0 100c=IN IP4 172.18.193.88a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20*Mar 1 00:43:17.343: Received:ACK sip:5552201@172.18.193.88;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5552201" <sip:5552201@172.18.193.88;user=phone>;tag=279390-CBDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 487666621@172.18.207.18CSeq: 101 ACKContent-Length: 0show sip-ua callsSIP UAC CALL INFONumber of UAC calls: 0SIP UAS CALL INFOCall 1SIP Call ID : 487666621@172.18.207.18State of the call : STATE_ACTIVE (6)Substate of the call : SUBSTATE_NONE (0)Calling Number : 9999Called Number : 5552201Bit Flags : 0x1212003A 0x20000Source IP Address (Sig ): 172.18.193.88Destn SIP Req Addr:Port : 172.18.207.18:5062Destn SIP Resp Addr:Port: 172.18.207.18:5062Destination Name : 172.18.207.18Number of Media Streams : 1Number of Active Streams: 1RTP Fork Object : 0x0Media Stream 1State of the stream : STREAM_ACTIVE (5)Stream Call ID : 9Stream Type : voice-only (0)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : inband-voice (0)Dtmf-relay Payload : 0Media Source IP Addr:Port: 172.18.193.88:17936Media Dest IP Addr:Port : 172.18.193.14:16452Number of UAS calls: 1Party A Add Second Stream Trace Example
The following is the second stream trace added by Party A. Also, call status is displayed with the show sip-ua calls command.
*Mar 1 00:33:05.178: Received:INVITE sip:5555101@172.18.193.14;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagTo: "5555101" <sip:5555101@172.18.193.14;user=phone>;tag=1D556B-24F1Date: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14Supported: 100relCSeq: 101 INVITEContact: <sip:9999@172.18.207.18:5062;user=phone>Content-Type: application/sdpContent-Length: 635v=0o=SIP_Tester 1239625037 1770029375 IN IP4 172.18.207.18s=SIP Prot Test Callt=0 0m=audio 17236 RTP/AVP 0 100c=IN IP4 172.18.193.88a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20m=audio 17114 RTP/AVP 0 100 101 101 100c=IN IP4 172.18.193.80a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194*Mar 1 00:33:05.222: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagTo: "5555101" <sip:5555101@172.18.193.14>;tag=1D556B-24F1Date: Mon, 01 Mar 1993 00:33:05 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContact: <sip:5555101@172.18.193.14:5060;user=phone>Content-Type: application/sdpContent-Length: 431v=0o=CiscoSystemsSIP-GW-UserAgent 2763 7167 IN IP4 172.18.193.14s=SIP Callc=IN IP4 172.18.193.14t=0 0m=audio 16412 RTP/AVP 0 100c=IN IP4 172.18.193.14a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20m=audio 18802 RTP/AVP 0 101 100c=IN IP4 172.18.193.14a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20*Mar 1 00:33:05.234: Received:ACK sip:5555101@172.18.193.14;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: <sip:5552201@172.18.207.18;user=phone>;tag=tester-tagTo: "5555101" <sip:5555101@172.18.193.14;user=phone>;tag=1D556B-24F1Date: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14CSeq: 101 ACKContent-Length: 0show sip-ua callsSIP UAC CALL INFOCall 1SIP Call ID : 1A3F2B6-14F311CC-801AECAF-10CC98B5@172.18.193.14State of the call : STATE_ACTIVE (6)Substate of the call : SUBSTATE_NONE (0)Calling Number : 5555101Called Number : 5552201Bit Flags : 0x12120030 0x20000Source IP Address (Sig ): 172.18.193.14Destn SIP Req Addr:Port : 172.18.207.18:5062Destn SIP Resp Addr:Port: 172.18.207.18:5062Destination Name : 172.18.207.18Number of Media Streams : 2Number of Active Streams: 2RTP Fork Object : 0x83064DC8Media Stream 1State of the stream : STREAM_ACTIVE (5)Stream Call ID : 11Stream Type : voice-only (0)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : inband-voice (0)Dtmf-relay Payload : 0Media Source IP Addr:Port: 172.18.193.14:16412Media Dest IP Addr:Port : 172.18.193.88:17236Media Stream 2State of the stream : STREAM_ACTIVE (5)Stream Call ID : 12Stream Type : voice+dtmf (1)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : rtp-nte (6)Dtmf-relay Payload : 101Media Source IP Addr:Port: 172.18.193.14:18802Media Dest IP Addr:Port : 172.18.193.80:17114Number of UAC calls: 1SIP UAS CALL INFONumber of UAS calls: 0Party C Add Second Stream Trace Example
The following is the second stream trace added by Party C. Also, call status is displayed with the show sip-ua calls command.
*Mar 1 00:44:19.763: Received:INVITE sip:5553201@172.18.193.80;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5553201" <sip:5553201@172.18.193.80;user=phone>Date: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 2108310431@172.18.207.18Supported: 100relCSeq: 101 INVITEContact: <sip:9999@172.18.207.18:5062;user=phone>Content-Length: 0*Mar 1 00:44:19.792: Sent:SIP/2.0 100 TryingVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5553201" <sip:5553201@172.18.193.80;user=phone>;tag=2895C8-53BDate: Mon, 01 Mar 1993 00:44:19 GMTCall-ID: 2108310431@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContent-Length: 0*Mar 1 00:44:19.828: Sent:SIP/2.0 183 Session ProgressVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5553201" <sip:5553201@172.18.193.80;user=phone>;tag=2895C8-53BDate: Mon, 01 Mar 1993 00:44:19 GMTCall-ID: 2108310431@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITERequire: 100relRSeq: 6083Allow-Events: telephone-eventContact: <sip:5553201@172.18.193.80:5060;user=phone>Content-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 523v=0o=CiscoSystemsSIP-GW-UserAgent 8259 5683 IN IP4 172.18.193.80s=SIP Callc=IN IP4 172.18.193.80t=0 0m=audio 18988 RTP/AVP 0 100 101c=IN IP4 172.18.193.80a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20*Mar 1 00:44:20.985: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5553201" <sip:5553201@172.18.193.80;user=phone>;tag=2895C8-53BDate: Mon, 01 Mar 1993 00:44:19 GMTCall-ID: 2108310431@172.18.207.18Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContact: <sip:5553201@172.18.193.80:5060;user=phone>Content-Type: application/sdpContent-Length: 523v=0o=CiscoSystemsSIP-GW-UserAgent 8259 5683 IN IP4 172.18.193.80s=SIP Callc=IN IP4 172.18.193.80t=0 0m=audio 18988 RTP/AVP 0 100 101c=IN IP4 172.18.193.80a=rtpmap:0 PCMU/8000a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20*Mar 1 00:44:20.997: Received:ACK sip:5553201@172.18.193.80;user=phone SIP/2.0Via: SIP/2.0/UDP 172.18.207.18:5062From: "SIP_Tester" <sip:9999@172.18.207.18:5062;user=phone>;tag=tester-tagTo: "5553201" <sip:5553201@172.18.193.80;user=phone>;tag=2895C8-53BDate: Mon, 01 Mar 1993 01:01:01 GMTCall-ID: 2108310431@172.18.207.18CSeq: 101 ACKContent-Type: application/sdpContent-Length: 277v=0o=SIP_Tester 2029259292 42666129 IN IP4 172.18.207.18s=SIP Prot Test Callt=0 0m=audio 16728 RTP/AVP 0 101 100c=IN IP4 172.18.193.14a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=ptime:20show sip-ua callsSIP UAC CALL INFONumber of UAC calls: 0SIP UAS CALL INFOCall 1SIP Call ID : 186464186@172.18.207.18State of the call : STATE_ACTIVE (6)Substate of the call : SUBSTATE_NONE (0)Calling Number : 9999Called Number : 5553201Bit Flags : 0x1212003A 0x20000Source IP Address (Sig ): 172.18.193.80Destn SIP Req Addr:Port : 172.18.207.18:5062Destn SIP Resp Addr:Port: 172.18.207.18:5062Destination Name : 172.18.207.18Number of Media Streams : 1Number of Active Streams: 1RTP Fork Object : 0x0Media Stream 1State of the stream : STREAM_ACTIVE (5)Stream Call ID : 7Stream Type : voice+dtmf (1)Negotiated Codec : g711ulaw (160 bytes)Codec Payload Type : 0Negotiated Dtmf-relay : rtp-nte (6)Dtmf-relay Payload : 101Media Source IP Addr:Port: 172.18.193.80:19352Media Dest IP Addr:Port : 172.18.193.14:16770Number of UAS calls: 1Additional References
For additional information related to the SIP Support for Media Forking feature, refer to the following references:
Related Documents
Cisco SIP Functionality
Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2 T
Session Initiation Protocol (SIP) for VoIP, Release 12.2(8)T
Session Initiation Protocol Gateway Call Flows, Release 12.2(4)T
Call Transfer Capabilities Using the Refer Method, Release 12.2(8)T
SIP Media Inactivity Timer, Release 12.2(8)T
Dual Tone Multifrequency Relay for SIP Calls Using Named Telephone Events, Release 12.2(2)XB
Cisco IOS References
Cisco IOS Debug Command Reference, Release 12.2 T
Cisco IOS IP Configuration Guide, Release 12.2
Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services, Release 12.2 T
Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2 T
Cisco IOS IP Command Reference, Volume 3 of 3: Multicast, Release 12.2 T
Cisco IOS Dial Technologies Configuration Guide, Release 12.2
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
1 Not all supported standards are listed.
MIBs
•
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
1 Not all supported MIBs are listed.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
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 cco-locksmith@cisco.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:
RFCs
RFC 2543
RFC 2833
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
1 Not all supported RFCs are listed.
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 T command reference publications.
New Commands
Modified Commands
debug ccsip events
To enable tracing of events that are specific to SIP service provider interface (SPI), use the debug ccsip events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ccsip events
no debug ccsip events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command previously traced all events posted to SIP SPI from all interfaces and also provided general SIP SPI information. Beginning with Cisco IOS Release 12.2(15)T, the debug ccsip events command displays only debugging information specifically related to SIP SPI events. Media stream and SIP SPI information is now reported in the debug ccsip media and debug ccsip info command output.
Examples
The following is sample output from the debug ccsip events command for a Cisco 3660:
Router# debug ccsip eventsSIP Call events tracing is enabledRouter#Nov 15 18:20:25.779: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUPNov 15 18:20:25.779: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTIONNov 15 18:20:25.783: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGENov 15 18:20:25.815: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTIONNov 15 18:20:25.819: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGENov 15 18:20:28.339: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTIONNov 15 18:20:28.339: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGENov 15 18:20:50.844: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTIONNov 15 18:20:50.844: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGENov 15 18:20:50.848: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECTRelated Commands
debug ccsip all
Enables all SIP-related debugging.
debug ccsip info
Enables tracing of general SIP SPI information.
debug ccsip media
Enables tracing of SIP call media streams.
debug ccsip info
To enable tracing of general SIP service provider interface (SPI) information, use the debug ccsip info command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ccsip info
no debug ccsip info
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Beginning in Cisco IOS Release 12.2(15)T, the debug ccsip info command is a separate option that displays general SIP SPI information for debug purposes. In past releases, this output was part of the debug ccsip events command.
Examples
The following is sample output from the debug ccsip info command for a Cisco 3660:
Router# debug ccsip infoSIP Call info tracing is enabledRouter#Nov 15 18:19:22.670: ****Adding to UAC tableNov 15 18:19:22.670: adding call id E to tableNov 15 18:19:22.670: CCSIP-SPI-CONTROL: act_idle_call_setupNov 15 18:19:22.670: act_idle_call_setup:Not using Voice Class CodecNov 15 18:19:22.670: act_idle_call_setup: preferred_codec set[0] type :g729r8 bytes: 20Nov 15 18:19:22.670: sipSPICopyPeerDataToCCB: From CLI: Modem NSE payload = 100, Passthrough = 0,Modem relay = 0, Gw-Xid = 1SPRT latency 200, SPRT Retries = 12, Dict Size = 1024String Len = 32, Compress dir = 3Nov 15 18:19:22.670: ****Deleting from UAC tableNov 15 18:19:22.670: ****Adding to UAC tableNov 15 18:19:22.670: sipSPIUsetBillingProfile: sipCallId for billing records = 20A40C3B-D92C11D5-8015E1CC-C91F3F10@12.18.195.49Nov 15 18:19:22.674: CCSIP-SPI-CONTROL: act_idle_connection_createdNov 15 18:19:22.674: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 172.18.193.190:5060, local_port 56981Nov 15 18:19:22.674: CCSIP-SPI-CONTROL: sipSPIOutgoingCallSDPNov 15 18:19:22.674: convert_codec_bytes_to_ptime: Values :Codec: g729r8 codecbytes :20, ptime: 10Nov 15 18:19:22.674: sip_generate_sdp_xcaps_list: Modem Relay disabled. X-cap not neededNov 15 18:19:22.674: sipSPIAddLocalContactNov 15 18:19:22.674: sip_stats_methodNov 15 18:19:22.690: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 172.18.193.190:5060Nov 15 18:19:22.690: CCSIP-SPI-CONTROL: act_sentinvite_new_messageNov 15 18:19:22.690: CCSIP-SPI-CONTROL: sipSPICheckResponseNov 15 18:19:22.690: sip_stats_status_codeNov 15 18:19:22.690: Roundtrip delay 16 milliseconds for method INVITENov 15 18:19:22.706: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 172.18.193.190:5060Nov 15 18:19:22.706: CCSIP-SPI-CONTROL: act_recdproc_new_messageNov 15 18:19:22.706: CCSIP-SPI-CONTROL: sipSPICheckResponseNov 15 18:19:22.706: sip_stats_status_codeNov 15 18:19:22.706: Roundtrip delay 32 milliseconds for method INVITENov 15 18:19:22.706: sipSPIGetSdpBody : Parse incoming session descriptionNov 15 18:19:22.706: HandleSIP1xxSessionProgress: Content-Disposition received in 18x response:session;handling=requiredNov 15 18:19:22.706: sipSPIDoMediaNegotiation: number of m lines is 1Nov 15 18:19:22.706: sipSPIDoAudioNegotiation: Codec (g729r8) Negotiation Successful on Static PayloadNov 15 18:19:22.706: sipSPIDoPtimeNegotiation: One ptime attribute found - value:10Nov 15 18:19:22.706: convert_ptime_to_codec_bytes: Values :Codec: g729r8 ptime :10, codecbytes: 20Nov 15 18:19:22.710: convert_codec_bytes_to_ptime: Values :Codec: g729r8 codecbytes :20, ptime: 10Nov 15 18:19:22.710: sipSPIDoDTMFRelayNegotiation: m-line index 1Nov 15 18:19:22.710: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not found in Preferred DTMF-RELAY option list!Nov 15 18:19:22.710: sip_sdp_get_modem_relay_cap_params:Nov 15 18:19:22.710: sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0Nov 15 18:19:22.710: sip_do_nse_negotiation: NSE Payload 100 found in SDPNov 15 18:19:22.710: sip_do_nse_negotiation: Remote NSE payload = local one = 100, Use itNov 15 18:19:22.710: sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem relayNov 15 18:19:22.710: sipSPIDoQoSNegotiation - SDP body with media descriptionNov 15 18:19:22.710: ccsip_process_response_contact_record_routeNov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_bridge: confID = 4, srcCallID = 14, dstCallID = 13Nov 15 18:19:22.710: sipSPIUupdateCcCallIds: old src/dest ccCallids: -1/-1, new src/dest ccCallids: 14/13Nov 15 18:19:22.710: sipSPIUupdateCcCallIds: old streamcallid=-1, new streamcallid=14Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_caps_indNov 15 18:19:22.710: ccsip_get_rtcp_session_parameters: CURRENT VALUES: stream_callid=14, current_seq_num=0x1B1BNov 15 18:19:22.710: ccsip_get_rtcp_session_parameters: NEW VALUES: stream_callid=14, current_seq_num=0x180CNov 15 18:19:22.710: ccsip_caps_ind: Load DSP with negotiated codec : g729r8, Bytes=20Nov 15 18:19:22.710: ccsip_caps_ind: set forking flag to 0x0Nov 15 18:19:22.710: sipSPISetDTMFRelayMode: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE_AND_OOBNov 15 18:19:22.710: sip_set_modem_caps: Negotiation already Done. Set negotiated Modem capsNov 15 18:19:22.710: sip_set_modem_caps: Modem Relay & Passthru both disabledNov 15 18:19:22.710: sip_set_modem_caps: nse payload = 100, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, relay=0, sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32Nov 15 18:19:22.710: ccsip_caps_ind: Load DSP with codec : g729r8, Bytes=20Nov 15 18:19:22.710: CCSIP-SPI-CONTROL: ccsip_caps_ackNov 15 18:19:22.710: ccsip_caps_ack: set forking flag to 0x60FD1EACNov 15 18:19:22.710: CCSIP-SPI-CONTROL: act_recdproc_connection_createdNov 15 18:19:22.710: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(2) created to 172.18.193.190:5060, local_port 51663Nov 15 18:19:22.714: sip_stats_methodNov 15 18:19:22.722: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 172.18.193.190:5060Nov 15 18:19:22.722: CCSIP-SPI-CONTROL: act_recdproc_new_messageNov 15 18:19:22.722: CCSIP-SPI-CONTROL: sipSPICheckResponseNov 15 18:19:22.722: sip_stats_status_codeNov 15 18:19:22.722: Roundtrip delay 48 milliseconds for method PRACKNov 15 18:19:24.706: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 172.18.193.190:5060Nov 15 18:19:24.706: CCSIP-SPI-CONTROL: act_recdproc_new_messageNov 15 18:19:24.706: CCSIP-SPI-CONTROL: sipSPICheckResponseNov 15 18:19:24.706: sip_stats_status_codeNov 15 18:19:24.706: Roundtrip delay 2032 milliseconds for method PRACKNov 15 18:19:24.706: sipSPIGetSdpBody : Parse incoming session descriptionNov 15 18:19:24.710: CCSIP-SPI-CONTROL: sipSPIUACSessionTimerNov 15 18:19:24.710: CCSIP-SPI-CONTROL: act_recdproc_continue_200_processingNov 15 18:19:24.710: CCSIP-SPI-CONTROL: act_recdproc_continue_200_processing: *** This ccb is the parentNov 15 18:19:24.710: sipSPICompareRespMediaInfoNov 15 18:19:24.710: sipSPIDoMediaNegotiation: number of m lines is 1Nov 15 18:19:24.710: sipSPIDoAudioNegotiation: Codec (g729r8) Negotiation Successful on Static PayloadNov 15 18:19:24.710: sipSPIDoPtimeNegotiation: One ptime attribute found - value:10Nov 15 18:19:24.710: convert_ptime_to_codec_bytes: Values :Codec: g729r8 ptime :10, codecbytes: 20Nov 15 18:19:24.710: convert_codec_bytes_to_ptime: Values :Codec: g729r8 codecbytes :20, ptime: 10Nov 15 18:19:24.710: sipSPIDoDTMFRelayNegotiation: m-line index 1Nov 15 18:19:24.710: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not found in Preferred DTMF-RELAY option list!Nov 15 18:19:24.710: sip_sdp_get_modem_relay_cap_params:Nov 15 18:19:24.710: sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0Nov 15 18:19:24.710: sip_do_nse_negotiation: NSE Payload 100 found in SDPNov 15 18:19:24.710: sip_do_nse_negotiation: Remote NSE payload = local one = 100, Use itNov 15 18:19:24.710: sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem relayNov 15 18:19:24.710: sipSPIProcessMediaChangesNov 15 18:19:24.710: ccsip_process_response_contact_record_routeNov 15 18:19:24.710: CCSIP-SPI-CONTROL: sipSPIProcess200OKforinviteNov 15 18:19:24.710: sip_stats_methodNov 15 18:19:24.710: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote port: 5060Nov 15 18:19:37.479: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 172.18.193.190:52180Nov 15 18:19:37.483: ****Found CCB in UAC tableNov 15 18:19:37.483: CCSIP-SPI-CONTROL: act_active_new_messageNov 15 18:19:37.483: CCSIP-SPI-CONTROL: sact_active_new_message_requestNov 15 18:19:37.483: sip_stats_methodNov 15 18:19:37.483: sip_stats_status_codeNov 15 18:19:37.483: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call disconnect(16) for outgoing callNov 15 18:19:37.483: udpsock_close_connect: Socket fd: 2 closed for connid 2 with remote port: 5060Nov 15 18:19:37.483: CCSIP-SPI-CONTROL: act_disconnecting_disconnectNov 15 18:19:37.483: CCSIP-SPI-CONTROL: sipSPICallCleanupNov 15 18:19:37.483: sipSPIIcpifUpdate :CallState: 4 Playout: 10230 DiscTime:1745148 ConnTime 1743871Nov 15 18:19:37.483: ****Deleting from UAC tableNov 15 18:19:37.483: Removing call id ENov 15 18:19:37.483: freeing ccb 63330954Related Commands
debug ccsip media
To enable tracing of SIP call media streams, use the debug ccsip media command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ccsip media
no debug ccsip media
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Beginning in Cisco IOS Release 12.2(15)T, the debug ccsip media command is a separate option that displays debugging information specific to SIP media stream processing. In past releases, this output was part of the debug ccsip events command.
Examples
The following is sample output from the debug ccsip media command for a Cisco 3660:
Router# debug ccsip mediaSIP Call media tracing is enabledRouter#Nov 15 18:19:53.835: sipSPISetMediaSrcAddr: media src addr for stream 1 = 172.18.195.49Nov 15 18:19:53.835: sipSPIReserveRtpPort: reserved port 16500 for stream 1Nov 15 18:19:53.867: sipSPIReplaceSDPNov 15 18:19:53.871: sipSPICopySdpInfoNov 15 18:19:53.871: sipSPIUpdCallWithSdpInfo:Preferred Codec : g729r8, bytes :20Preferred DTMF relay : inband-voicePreferred NTE payload : 101Early Media : NoDelayed Media : NoBridge Done : NoNew Media : NoDSP DNLD Reqd : NoNov 15 18:19:53.871: sipSPISetMediaSrcAddr: media src addr for stream 1 = 172.18.195.49Nov 15 18:19:53.871: sipSPIUpdCallWithSdpInfo:M-line Index : 1State : STREAM_ADDING (3)Callid : -1Negotiated Codec : g729r8, bytes :20Negotiated DTMF relay : inband-voiceNegotiated NTE payload : 0Media Srce Addr/Port : 172.18.195.49:16500Media Dest Addr/Port : 172.18.193.190:19148Nov 15 18:19:53.871: sipSPIProcessRtpSessionsNov 15 18:19:53.871: sipSPIAddStream: Adding stream 1 (callid 16) to the VOIP RTP libraryNov 15 18:19:53.871: sipSPISetMediaSrcAddr: media src addr for stream 1 = 172.18.195.49Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: for m-line 1Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: rtcp_session infoladdr = 172.18.195.49, lport = 16500, raddr = 172.18.193.190, rport=19148Nov 15 18:19:53.871: sipSPIUpdateRtcpSession: No rtp session, creating a new oneNov 15 18:19:53.871: sipSPISetStreamInfo: num_streams = 1Nov 15 18:19:53.871: sipSPISetStreamInfo: adding stream type 0 from mline 1Nov 15 18:19:53.871: sipSPISetStreamInfo: caps.stream_count=1, caps.stream[0].stream_type=0x1, caps.stream_list.xmitFunc=voip_rtp_xmit, caps.stream_list.context=0x634F1F2C (gccb)Nov 15 18:19:55.555: sipSPICompareSDPNov 15 18:19:55.555: sipSPICompareStreams: stream 1 dest_port: old=19148 new=19148Nov 15 18:19:55.555: sipSPICompareStreams: Flags set for stream 1: RTP_CHANGE=No CAPS_CHANGE=NoNov 15 18:19:55.555: sipSPICompareSDP: Flags set for call: NEW_MEDIA=No DSPDNLD_REQD=NoNov 15 18:19:55.555: sipSPIReplaceSDPNov 15 18:19:55.555: sipSPICopySdpInfoNov 15 18:19:55.555: sipSPIUpdCallWithSdpInfo:Preferred Codec : g729r8, bytes :20Preferred DTMF relay : inband-voicePreferred NTE payload : 101Early Media : NoDelayed Media : NoBridge Done : YesNew Media : NoDSP DNLD Reqd : NoNov 15 18:19:55.555: sipSPISetMediaSrcAddr: media src addr for stream 1 = 172.18.195.49Nov 15 18:19:55.555: sipSPIUpdCallWithSdpInfo:M-line Index : 1State : STREAM_ACTIVE (3)Callid : 16Negotiated Codec : g729r8, bytes :20Negotiated DTMF relay : inband-voiceNegotiated NTE payload : 0Media Srce Addr/Port : 172.18.195.49:16500Media Dest Addr/Port : 172.18.193.190:19148Related Commands
show sip-ua calls
To display active user agent client (UAC) and user agent server (UAS) information on SIP calls, use the show sip-ua calls command in privileged EXEC mode.
show sip-ua calls
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The show sip-ua calls command displays active UAC and UAS information on SIP calls. It includes information about multiple media streams, up to three media streams if it is a media-forked call. It is useful in debugging multiple media streams because it is the only command that indicates whether an active call is forked.
Examples
The following is sample output from the show sip-ua calls command for a Cisco 3660:
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 : 5550200Called 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: 0Table 1 describes significant fields in this output:Related Commands
Glossary
3pcc—third-party call controller. In the SIP Support for Media Forking feature, the third-party call controller gateway can signal a call to a gateway on behalf of another gateway.
audio—What the user hears on the telephone. Includes both voice and DTMF digits.
branch—A fork consists of multiple media streams. Each of these streams is referred to as a branch.
call—In SIP, a call consists of all participants in a conference who are invited by a common source. A SIP call is identified by a globally unique call identifier. A point-to-point IP telephony conversation maps into a single SIP call.
CLI—command-line interface.
codec—coder-decoder. Transforms analog signals into a digital bit stream and digital signals back into analog signals. In VoIP applications, it specifies the voice coder rate of speech for a dial peer.
complex forking—A forking scenario in which at least one of the branches is transmitting using a compressed codec and at least one of the other branches is transmitting using a noncompressed (G.711) codec. See also simple forking.
conference—A call in which all parties receive and send media.
dial peer—An addressable call endpoint that contains configuration information including the voice protocol, a codec type, and a telephone number associated with the call endpoint.
DNS—Domain Name System. Used to translate H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to assist in locating remote gatekeepers and to reverse-map raw IP addresses to host names of administrative domains.
DSP—digital signal processor. DSP modules provide voice compression and packetization services to the VoIP card so that it can be configured and expanded.
DTMF—dual-tone multifrequency. Tones that are generated when a button on a touch-tone phone is pressed. When the tone is generated, it is compressed, transported to the other party, and decompressed.
DTMF-relay— DTMF-relay provides reliable digit relay between VoIP gateways when a low-bandwidth codec is used. DTMF-relay provides a standardized means of transporting DTMF tones in Real-Time Transport Protocol (RTP) packets and is identified by dynamic payload types in the SDP.
dynamic payload—Payloads that are defined at the initiation of a session and that are not assigned to specific RTP formats.
endpoint—A terminal or gateway that acts as a source or sink of voice data. An endpoint can call or be called, and it generates or terminates the information stream.
fork—A fork consists of all the media streams (branches) that are generated and transmitted by an endpoint. Only one party (the controller) receives the media from all of the other parties. The other parties receive media from the controller.
forking—A transmit function of the endpoint. It is used to forward a request in several directions simultaneously; for example to find a user when the user may be at one of several locations.
FQDN—fully qualified domain name. Complete domain name including the host portion; for example, serverA.companyA.com.
FXS—Foreign Exchange Station. An FXS interface connects directly to a standard telephone and supplies ring, voltage, and dial tone.
Invite—A SIP message that initiates a SIP session. It indicates that a user is invited to participate, provides a session description, indicates the type of media, and provides insight regarding the capabilities of the called and calling parties.
IP—Internet protocol. A connectionless protocol that operates at the network layer (Layer 3) of the OSI model. IP provides features for addressing, type-of-service specification, fragmentation and reassembly, and security. IP is defined in RFC 791. This protocol works with TCP and is usually identified as TCP/IP. See also TCP and TCP/IP.
ISDN—Integrated Services Digital Network.
NTE—named telephony event. Format of RTP packets used to transport DTMF digits (or dynamic payload types) as defined in RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
payload types—Define the content and format of RTP packets and the resulting stream of data generated by RTP flow. Payload types are identified in the payload field of the RTP header in each RTP packet. There are two methods for specifying payload types: static and dynamic.
PSTN—public switched telephone network. PSTN refers to the local telephone company.
QoS—quality of service. Measure of performance for a transmission system that reflects its transmission quality and service availability. QoS refers to the ability of a network to provide better service to selected network traffic over various underlying technologies. QoS is not inherent in a network infrastructure. Rather, you must institute QoS by strategically deploying features that implement it throughout the network.
re-Invite—An Invite request sent during an active call leg.
RTCP—Real-Time Control Protocol. Monitors the QoS of an IPv6 RTP connection and conveys information about the ongoing session.
RTP—Real-Time Transport Protocol. A network protocol used to carry packetized audio and video traffic over an IP network.
RTP-NTE—Real Time Protocol-Named Telephony Event. RTP-NTE is described in RFC 2833 and prevents the generation of spurious digits at the receiving gateway. It must be used when DTMF-relay is configured in a forked call.
SDP—Session Description Protocol. Messages that contain capabilities information that are exchanged between gateways.
session—A SIP session includes a set of multimedia senders and receivers and the data streams that flow between the senders and receivers. A SIP multimedia conference is an example of a session. The called party can be invited several times by different calls to the same session.
simple forking—A forking scenario in which all of the branches of the fork use the same voice codec compression. See also complex forking.
simple mixing—A mixer receives multiple streams of the same codec type and combines them into one stream that is sent to the telephony interface.
SIP—Session Initiation Protocol. An application-layer protocol originally developed by the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force (IETF). Their goal was to equip platforms to signal the setup of voice and multimedia calls over IP networks. SIP features are compliant with IETF RFC 2543, published in March 1999.
SIP URL—Session Initiation Protocol Uniform Resource Locator. Used in SIP messages to indicate the originator, recipient, and destination of the SIP request. Takes the basic form of user@host, where user is a name or telephone number, and host is a domain name or network address.
speech—Encoded data delivered via the RTP stream. Excludes fax, modem, and DTMF relay. Includes DTMF digits which are sent as inband audio when DTMF relay is not enabled.
SPI—service provider interface. A general category for VoIP protocols.
static payload—Static payloads are assigned to specific RTP formats and are generally grouped for specific applications, for example audio and video conferencing.
stream—A fork consists of multiple media streams or branches. Each branch is referred to as a stream.
TCP—Transmission Control Protocol. Connection-oriented transport layer protocol that provides reliable full-duplex data transmissions. TCP is part of the TCP/IP protocol stack. See also TCP/IP and IP.
TCP/IP—Transmission Control Protocol/Internet Protocol. Common name for the suite of protocols developed by the U.S. Department of Defense in the 1970's to support the construction of worldwide internetworks. TCP and IP are the two best known protocols in the suite. See also TCP and IP.
TEL URL—Telephone Uniform Resource Locator. Describes voice call connections to a terminal. Can also be any connection through a voice messaging system or a service that can be operated using DTMF tones. Takes the basic form of tel:telephone-subscriber-number, where tel indicates a URL and requests the local entity to place a voice call, and telephone-subscriber-number is the number to receive the call.
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.
VFC—voice feature card.
voice—A specific type of audio, also referred to as speech.
VoIP—Voice over IP. The ability to carry normal telephone-style voice over an IP-based network.
