Table Of Contents
MGCP Based Fax (T.38) and DTMF Relay
Monitoring and Maintaining DTMF Relay
DTMF Relay Configuration Example
MGCP Based Fax (T.38) and DTMF Relay
Feature History
This document includes the following sections:
–
Monitoring and Maintaining DTMF Relay
–
DTMF Relay Configuration Example
MGCP Based Fax (T.38)
For a description of MGCP Based Fax (T.38), refer to Cisco Fax Services over IP Application Guide.
MGCP Based DTMF Relay
DTMF relay conforms to RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, developed by the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group. Per RFC 2833, DTMF is relayed using Named Telephony Events (NTEs) in Real-Time Transport Protocol (RTP) packets.
This feature provides two modes of implementation for each component: gateway (GW)-controlled mode and call agent (CA)-controlled mode. In GW-controlled mode, GWs negotiate DTMF transmission by exchanging capability information in Session Description Protocol (SDP) messages. That transmission is transparent to the CA. GW-controlled mode allows use of the DTMF Relay feature without upgrading the CA software to support the feature.
In CA-controlled mode, CAs use MGCP messaging to instruct GWs to process DTMF traffic.
DTMF relay provides a way to transport DTMF digits in an RTP voice stream when the voice codec cannot accurately reproduce the digits, or the sender or receiver digital signal processor (DSP) cannot perform digit sampling. Each DTMF digit is encoded as an RTP named event packed, which is transmitted and received instead of the usual digit samples carried in voice packets. The named events are sent as RTP packets over UDP. The packets are encoded with a payload type which is negotiated during connection establishment between the GWs using SDP.
The three current implementations of DTMF relay for MGCP are Cisco proprietary, Named Signaling Event (NSE), and out-of-band. With the MGCP Based DTMF Relay feature, support is added for RFC 2833 to provide a standardized method of DTMF transport using NTEs. Support of RFC 2833 is standards-based and allows greater interoperability with other GWs and CAs.
If DTMF relay is not configured, the DSPs on the GWs send and receive DTMF digits in band in the voice codec.
During an MGCP call sequence, GWs exchange SDP information using create connection (CRCX) and modify connection (MDCX) requests as shown below:
•
CRCX—Sent from the CA to the originating GW (OGW)
•
ACK—Sent from the OGW and contains the OGW's SDP information
•
CRCX—Sent from the CA to the terminating GW (TGW) and contains the OGW's SDP information
•
ACK—Sent from the TGW and contains the TGW's SDP information
•
MDCX—Sent from the CA to the OGW and contains TGW's SDP information
•
ACK—Sent from the OGW
If either the Cisco proprietary mode or the NSE mode is used, each GW is unaware of the remote GW's DTMF relay configuration because it is not indicated in the SDP. Each side determines whether to use DTMF relay, based on its locally-configured mode setting and a combination of voice codec and codec filter settings. Each side uses its locally configured RTP payload type when encoding RTP named event packets. Interoperability of endpoints relies on matching command line interface (CLI) configurations. The value used for NSE mode is configured using the mgcp tse payload command. The payload type for Cisco proprietary mode is 121. This value is used regardless of the configured payload value.
Benefits
•
MGCP support for RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
•
More reliable DTMF relay.
•
Greater interoperability with third-party equipment.
•
GW-controlled and CA-controlled modes allow for phased network upgrades.
Restrictions
•
For DTMF relay, the dynamic RTP payload range supported is 98 through 119.
Supported Platforms
Table 1 Cisco IOS Release and Platform Support for this Feature
Platform 12.2(2)XB 12.2(8)T 12.2(11)T 12.2(15)TCisco 1751
Not supported
Not supported
Not supported
X
Cisco 1760
Not supported
Not supported
Not supported
X
Cisco 2420
X
X
X
X
Cisco 3600 series
X
Not supported1
Not supported
X
Cisco 3660
X
X
X
X
Cisco 3725/Cisco 3745
Not supported
X
X
X
Cisco MC3810
X
X
X
X
Cisco AS5300
X
Not supported
X
X
Cisco AS5850
Not supported
Not supported
X
X
Cisco AS5400
X
Not supported
X
X
Cisco AS5850
Not supported
Not supported
X
X
1 The entire Cisco 3600 series except for the Cisco 3660 is not supported in Cisco IOS Releases 12.2(8)T and 12.2(11)T.
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:
Availability of Cisco IOS Software Images
Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.
Supported MIBs and RFCs
MIBs
None
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
RFCs
•
RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
Prerequisites
Complete the following tasks on your network before configuring this feature:
•
Configure IP routing
•
Configure Voice over IP
•
Configure voice ports on the GWs
•
Set up the call agent
•
Configure MGCP on the GWs
Configuring DTMF Relay
Verifying DTMF Relay
Step 1
Enter the show running command to display the current configuration settings. Example 1 shows that DTMF relay is configured in GW-controlled mode.
Example 1 DTMF Relay in GW-Controlled Mode
!mgcpmgcp call-agent 172.18.195.147 2427 service-type mgcp version 0.1mgcp dtmf-relay voip codec all mode nte-gwmgcp modem passthrough voip mode camgcp package-capability dtmf-packagemgcp default-package mo-packagemgcp tse payload 110no mgcp timer receive-rtcp!mgcp profile default!
Troubleshooting Tips
To minimize adverse impact when upgrading your network to use the DTMF Relay feature, perform the following general procedures:
Step 1
Upgrade the CA, if necessary, to insure that it can pass DTMF SDP transparently. Then transition the Cisco GW portion of the network, if necessary, to MGCP.
Step 2
For each node in the network, upgrade to an image compatible with the MGCP Based DTMF Relay feature, but leave it configured in its current (legacy) DTMF relay mode. In this configuration, the new DTMF transfer mode in the DTMF Relay feature is used only if asked for in a request; otherwise, the legacy configuration is used.
Step 3
Configure the DTMF Relay feature for each node in the network. Also configure GW-controlled mode.
Step 4
Upgrade the call agent, if necessary, to support the DTMF Relay feature.
Step 5
Configure each node in the network to CA-controlled mode.
•
Type I—No DTMF relay LCO, but can blindly pass DTMF relay SDP between GWs
•
Type II—DTMF relay LCO and recovery from DTMF relay NACK, with no SDP interpretation
Upgrading from Cisco Proprietary Mode
This procedure assumes that the following prerequisites have been met:
•
Each GW in the network is configured with DTMF Relay mode cisco, and identical values for DTMF relay codec and Telephony Signaling Events (TSE) payload.
•
Each CA has been upgraded to one of the supported types.
For each GW, perform the following steps:
Step 1
Enter the copy run start . command.
Step 2
Install the image containing the MGCP Based DTMF Relay feature.
Step 3
Reboot the GW and return it to service.
Verify that all GWs have the software containing the DTMF Relay feature and are running legacy configurations.
For each GW, then change the configured DTMF Relay mode to nte-gw.
Upgrading from DTMF Disabled
This procedure assumes that the following prerequisites have been met:
•
Each GW in the network is configured with DTMF relay disabled, and identical TSE payload values.
•
Each CA has been upgraded to support the new LCO and SDP for DTMF relay.
For each GW, perform the following steps:
Step 1
Enter the copy run start . command.
Step 2
Install the image containing the DTMF Relay feature.
Step 3
Reboot the GW and return it to service.
Verify that all GWs have the software containing the MGCP Based DTMF Relay feature and are running legacy configurations.
For each GW, change the configured DTMF relay mode to nte-gw, and the configured DTMF relay codec to a valid value (for example, low-bit-rate).
All GWs in the network should be set to nte-gw mode.
Monitoring and Maintaining DTMF Relay
DTMF Relay Configuration Example
In the following example, DTMF relay is configured in GW-controlled mode:
!mgcpmgcp call-agent 172.18.195.147 2427 service-type mgcp version 0.1mgcp dtmf-relay voip codec all mode nte-gwmgcp modem passthrough voip mode camgcp package-capability dtmf-packagemgcp default-package mo-packagemgcp tse payload 110no mgcp timer receive-rtcp!mgcp profile default!Command Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.
New Commands
Modified Commands
debug voip rtcp
To enable debugging for Real-Time Transport Control Protocol (RTCP) packets, use the debug voip rtcp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug voip rtcp {error | packet | session}
no debug voip rtcp
Syntax Description
error
Prints out a trace for error cases.
packet
Provides debug output for RTCP packets.
session
Provides all session debug information.
Defaults
Debugging for RTCP packets is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When used without a keyword, this command turns on debugging for all events. This command severely impacts performance; use with caution.
Examples
The following example shows sample output for the debug voip rtcp command.
Router# debug voip rtcp1w0d: voip_rtcp_create_session: callID=37, dstCallID=36 laddr=172.19.169.85, lp01w0d: voip_rtcp_get_cname: cname=0.0.0@172.19.169.851w0d: voip_rtcp_send_event: event=EV_NEW1w0d: voip_rtcp_new: rtcp_interval=1893Router#1w0d: voip_rtcp_send_event: event=EV_STATS1w0d: voip_rtcp_stats_req: rtcp_interval=34481w0d: voip_rtcp_stats_req:delay=45 lost_packets=0 rtt=0Router#1w0d: recv:1w0d: SR: ssrc=0x1272A94D sr_ntp_h=0xAF44E045 sr_ntp_l=0xA6CE39C sr_timestamp=021w0d: SDES: ssrc=0x1272A94D name=1 len=19 data=0.0.0@172.19.169.771w0d: rtcp_round_trip_delay: ssrc=0x1D86A955Router#1w0d: voip_rtcp_send_event: event=EV_STATS1w0d: voip_rtcp_stats_req: rtcp_interval=63941w0d: voip_rtcp_stats_req:delay=40 lost_packets=0 rtt=01w0d: recv:1w0d: SR: ssrc=0x1272A94D sr_ntp_h=0xAF44E047 sr_ntp_l=0xFFB007F6 sr_timestamp=61w0d: SDES: ssrc=0x1272A94D name=1 len=19 data=0.0.0@172.19.169.771w0d: rtcp_round_trip_delay: ssrc=0x1D86A955Router#1w0d: voip_rtcp_remove_ccb1w0d: voip_rtcp_send_event: event=EV_DESTROY1w0d: voip_rtcp_destroy_idle1w0d: voip_rtcp_close_session1w0d: Cleaning up sess=62F95F58, sp=19544, dp=17130debug voip rtp
To enable debugging for Real-Time Transport Protocol (RTP) named event packets, use the debug voip rtp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug voip rtp {error | session [nse | multicast | conference | dtmf-relay | named-event] | packet remote-ip ipaddress remote-port portnum packetnum | packet callid idnum packetnum]}
no debug voip rtp
Syntax Description
Defaults
Debugging for RTP named event packets is not enabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command severely impacts performance and should be used only for single-call debug capture. Cisco does not recommend using this command when using fax relay, because it can adversely affect fax relay.
Examples
The following example illustrates the output for the debug voip rtp session named-event command. The example is for a gateway that sends digits 1, 2, 3, then receives digits 9,8,7. The payload type, event ID, and additional packet payload are shown in each log.
The first three packets indicate the start of the tone (initial packet and two redundant). The last three packets indicate the end of the tone (initial packet and two redundant). The packets in between are refresh packets that are sent every 50 milliseconds (without redundancy).
Router# debug voip rtp session named-event00:09:29: Pt:99 Evt:1 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:03 01 90 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:03 03 20 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:03 04 B0 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:83 04 C8 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:83 04 C8 <<<Rcv>00:09:29: Pt:99 Evt:1 Pkt:83 04 C8 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 01 90 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 03 20 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:03 04 B0 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:83 05 18 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:83 05 18 <<<Rcv>00:09:29: Pt:99 Evt:2 Pkt:83 05 18 <<<Rcv>00:09:29: Pt:99 Evt:3 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:3 Pkt:03 00 00 <<<Rcv>00:09:29: Pt:99 Evt:3 Pkt:03 00 00 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:03 01 90 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:03 03 20 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:03 04 B0 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:03 06 40 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:83 06 80 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:83 06 80 <<<Rcv>00:09:30: Pt:99 Evt:3 Pkt:83 06 80 <<<Rcv>00:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 01 9000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 03 2000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 04 B000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:02 06 4000:09:31: <Snd>>> Pt:99 Evt:9 Pkt:82 06 5800:09:31: <Snd>>> Pt:99 Evt:9 Pkt:82 06 5800:09:31: <Snd>>> Pt:99 Evt:9 Pkt:82 06 5800:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 01 9000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 03 2000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 04 B000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:02 06 4000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:82 06 9000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:82 06 9000:09:31: <Snd>>> Pt:99 Evt:8 Pkt:82 06 9000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 00 0000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 01 9000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 03 2000:09:31: <Snd>>> Pt:99 Evt:7 Pkt:02 04 B000:09:32: <Snd>>> Pt:99 Evt:7 Pkt:02 06 4000:09:32: <Snd>>> Pt:99 Evt:7 Pkt:82 06 5800:09:32: <Snd>>> Pt:99 Evt:7 Pkt:82 06 5800:09:32: <Snd>>> Pt:99 Evt:7 Pkt:82 06 58mgcp dtmf-relay
To ensure accurate forwarding of digits on compressed codecs, use the mgcp dtmf-relay command in global configuration mode. To disable this process for noncompressed codecs, use the no form of this command.
Voice Over IP
mgcp dtmf-relay voip codec {all | low-bit-rate} mode {cisco | nse | out-of-band | nte-gw | nte-ca}
no mgcp dtmf-relay voip
Voice over AAL2
mgcp dtmf-relay voaal2 codec [all | low-bit-rate]
no mgcp dtmf-relay voaal2
Syntax Description
Defaults
no mgcp dtmf-relay for all codecs
Command Modes
Global configuration
Command History
Usage Guidelines
Only Voice over IP supports the mode options for forwarding digits on codecs.
Examples
The following example shows how to configure a codec for VoAAL2:
Router(config)# mgcp dtmf-relay voaal2 codec allThe following example shows how to set the dtmf-relay codec and mode to GW:
Router(config)# mgcp dtmf-relay codec mode nte-gwRelated Commands
mgcp timer
To configure how the gateway detects the Real-Time Transport Protocol (RTP) stream host, use the mgcp timer command in global configuration mode. Use the no form of this command to restore the default value.
mgcp timer {receive-rtcp timer | net-cont-test timer | nse-response t38 timer}
no mgcp timer
Syntax Description
Defaults
The receive-rtcp timer default is 5.
The net-cont-test timer default is 200.
The nse-response t38 timer default is 200.
Command Modes
Global configuration
Command History
Usage Guidelines
The receive-rtcp option is the timer used by a gateway to disconnect a VoIP call when the IP connectivity is lost with the remote gateway. After receiving each packet from the remote gateway, the receiving gateway starts a timer for the timer period. If the timer expires before receiving the next packet from the remote gateway, the receiving gateway disconnects the call and notifies the call agent.
The net-cont-test option uses the terminating gateway to verify the network connectivity with the originating gateway before ringing the called party. To do this, the terminating gateway sends a command packet to the originating gateway and starts a timer for the timer period. If the timer expires before receiving any acknowledgement from the originating gateway, the terminating gateway does not ring the called party, disconnects the call, and alerts the call agent.
The nse-response t38 option sets the timer for awaiting T.38 NSE responses. This timer is configured to tell the terminating GW how long to wait for an NSE from a peer GW. The NSE from the peer GW can either acknowledge the switch and its readiness to accept packets, or indicate that it cannot accept T.38 packets.
Examples
The following example sets the receive-rtcp timer to 25 milliseconds:
Router(config)# mgcp timer receive-rtcp 25The following example sets the net-cont-test timer to 1500 milliseconds (1.5 seconds):
Router(config)# mgcp timer net-cont-test 1500The following example shows the MGCP fax relay feature enabled and a GW wait time of 300 milliseconds for an NSE from a peer GW.
Router(config)# mgcp timer nse-response t38 300Related Commands
show mgcp
To display values for MGCP parameters, use the show mgcp command in privileged EXEC mode.
show mgcp
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The show mgcp command provides administrative high-level information about the values configured for MGCP parameters on the router. For more specific types of information, see the show mgcp connection, show mgcp endpoint, show mgcp nas, show mgcp profile, and show mgcp statistics commands.
Examples
The following is sample output for the show mgcp command:
Router# show mgcpMGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONEMGCP call-agent: 172.18.195.147 2300 Initial protocol service is SGCP 1.5MGCP block-newcalls DISABLEDMGCP send RSIP for SGCP is ENABLEDMGCP quarantine mode discard/stepMGCP quarantine of persistent events is ENABLEDMGCP dtmf-relay for VoIP disabled for all codec typesMGCP dtmf-relay voaal2 codec allMGCP voip modem passthrough mode: NSE, codec: g711ulaw, redundancy: DISABLED,MGCP voaal2 modem passthrough mode: NSE, codec: g711ulawMGCP TSE payload: 100MGCP T.38 Named Signalling Event (NSE) response timer: 200MGCP Network (IP/AAL2) Continuity Test timer: 3000MGCP 'RTP stream loss' timer: 2MGCP request timeout 500MGCP maximum exponential request timeout 4000MGCP gateway port: 2427, MGCP maximum waiting delay 3000MGCP restart delay 0, MGCP vad DISABLEDMGCP xpc-codec: DISABLED, MGCP persistent hookflash: DISABLEDMGCP persistent offhook: ENABLED, MGCP persistent onhook: DISABLEDMGCP piggyback msg DISABLED, MGCP endpoint offset DISABLEDMGCP simple-sdp DISABLEDMGCP undotted-notation DISABLEDMGCP codec type g711ulaw, MGCP packetization period 20MGCP JB threshold lwm 30, MGCP JB threshold hwm 150MGCP LAT threshold lmw 150, MGCP LAT threshold hwm 300MGCP PL threshold lwm 1000, MGCP PL threshold hwm 10000MGCP CL threshold lwm 1000, MGCP CL threshold hwm 10000MGCP playout mode is adaptive 60, 4, 200 in msecMGCP IP ToS low delay disabled, MGCP IP ToS high throughput disabledMGCP IP ToS high reliability disabled, MGCP IP ToS low cost disabledMGCP IP RTP precedence 5, MGCP signaling precedence: 3MGCP default package: line-packageMGCP supported packages: gm-package dtmf-package trunk-package line-packagehs-package atm-package ms-package dt-package res-packamt-packageMGCP T.38 Fax is ENABLEDMGCP T.38 Fax ECM is DISABLEDMGCP T.38 Fax NSF Override is DISABLEDMGCP T.38 Fax Low Speed Redundancy: 0MGCP T.38 Fax High Speed Redundancy: 0
Related Commands
Glossary
AAL2—ATM Adaptation Layer 2. Supports traffic needing precise timing, such as compressed voice and video.
CA—call agent.
call agent—An intelligent entity in an IP telephony network that handles call control in an MGCP model Voice-over-IP network.
CRCX—Create Connection request. Used in an MGCP call sequence by GWs to exchange SDP information.
DTMF—dual-tone multifrequency. Tones made by pushing buttons on a telephone.
fx: extension—An extension of the local connection option used by the CA to instruct the GW to be in CA-controlled mode or GW-controlled mode.
GWs—gateways.
MDCX—modify connection request. Used in an MGCP call sequence by GWs to exchange SDP information.
media gateway—Equipment that connects the PSTN or a PBX with the Voice-over-IP network. It is controlled by a call agent using MGCP.
MGC—media gateway controller. Another name for call agent.
MGCP—Media Gateway Control Protocol.
NSE—Named Signaling Event. Format of RTP packets used for applications such as modem relay and fax relay. NSEs have different payload values than NTEs.
NTE—Named Telephony Event. Format of RTP packets used to transport DTMF digits as defined in RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
payload type—Payload types are defined in RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. A payload type is a number from 96 through 127 that identifies the type of payload carried in the packet (for example, a payload type of 121 denotes a Cisco DTMF relay payload; a payload type of 122 denotes a fax payload). The payload type should be identical on the GW and call agent.
PSTN—Public Switched Telephone Network.
RTCP—RTP Control Protocol. The protocol monitors an RTP connection and conveys information about the ongoing session.
RTP—Real-Time Transport Protocol. The protocol provides end-to-end network transport functions for applications transmitting real-time data and services such as payload type identification, sequence numbering, time stamping, and delivery monitoring.
SDP—Session Description Protocol. Messages containing capabilities information that are exchanged between GWs.
TGW—see trunking gateway.
trunking gateway—An external gateway control protocol (xGCP) media gateway that provides connectivity between the PSTN and VoIP networks.
