Information About DTMF Relay

Information About DTMF Relay


Dual-tone multifrequency (DTMF) is the tone generated on a touchtone phone when the keypad digits are pressed. During a call, DTMF may be entered to access interactive voice response (IVR) systems, such as voice mail and automated banking services.

Although DTMF is usually transported accurately when using high-bit-rate voice codecs such as G.711, low-bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns and tend to distort DTMF tones. As a result, IVR systems may not correctly recognize the tones.

DTMF relay solves the problem of DTMF distortion by transporting DTMF tones “out of band,” or separate from the encoded voice stream.

Relay Types

Cisco gateways currently support the following methods of DTMF relay:

Cisco-proprietary Real-Time Transport Protocol (RTP)—DTMF tones are sent in the same RTP channel as voice data. However, the DTMF tones are encoded differently from the voice samples and are identified by a different RTP payload type code. Use of this method accurately transports DTMF tones, but because it is proprietary, it requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.

H.245 signal or alphanumeric—These methods separate DTMF digits from the voice stream and send them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 User Input Indication messages. The H.245 signaling channel is a reliable channel, so the packets that transport the DTMF tones are guaranteed to be delivered. However, because of the overhead of using a reliable protocol, and depending on network congestion conditions, the DTMF tones may be slightly delayed. All H.323 version 2 compliant systems are required to support the “h245-alphanumeric” method, while support of the “h245-signal” method is optional.

Named Telephone Events (NTEs). Using NTE to relay DTMF tones provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of 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. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF relay method. They also negotiate to determine the payload type value for the NTE RTP packets. User preference for DTMF relay types is not supported, and DTMF relay forking is not supported.

The ability of a gateway to receive DTMF digits in a particular format and the ability to send digits in that format are independent functions. No configuration is necessary to receive DTMF digits from another H.323 endpoint using any of the methods described. The Cisco gateway is capable of receiving DTMF tones transported by any of these methods at all times.

Capabilities and Priorities

Cisco H.323 gateways advertise capabilities using H.245 capabilities messages. By default, they advertise that they can receive all DTMF relay modes. If the capabilities of the remote gateway do not match, the Cisco H.323 gateway transmits DTMF tones as in-band voice.

Configuring DTMF relay on the Cisco H.323 gateway sets preferences for how the gateway handles DTMF transmission. You can enable more than one DTMF relay option for a particular dial peer. If more than one option is enabled and if the peer indicates that it is capable of receiving DTMF in more than one of these formats, the gateway sends DTMF using the method among the supported formats that it considers to be the most preferred. If the remote device supports multiple formats, the gateway chooses the format according to the following priority:

1. cisco-rtp (highest priority)

2. h245-signal

3. h245-alphanumeric

4. rtp-nte

5. None—DTMF sent in-band

Payload Types

In addition, Cisco gateways provide support for asymmetrical payload types. Payload types can differ between local and remote endpoints. Therefore, the Cisco gateway can transmit one payload type value and receive a different payload type value.

The dtmf-relay h245-signal command relays a more accurate representation of a DTMF digit than does the dtmf-relay h245-alphanumeric command because tone duration information is included along with the digit value. This information is important for applications requiring that a key be pressed for a particular length of time. For example, one popular calling card feature allows the caller to terminate an existing call by pressing the # key for more than 2 seconds and then making a second call without having to hang up in between. This feature is beneficial because the access number and personal identification number (PIN) code do not need to be dialed again. Outside-line access charges, which are common at hotels, may also be avoided.

The dtmf-relay h245-alphanumeric command simply relays DTMF tones as ASCII characters. For instance, the DTMF digit 1 is transported as the ASCII character 1. There is no duration information associated with tones in this mode. When the Cisco H.323 gateway receives a DTMF tone using this method, the gateway generates the tone on the PSTN interface of the call using a fixed duration of 500 ms. All systems that are H.323 Version 2-compliant are required to support the dtmf-relay h245-alphanumeric command, but support of the dtmf-relay h245-signal command is optional.

H.245 Tunneling of DTMF Relay in Conjunction with Fast Connect

Through H.245 tunneling, H.245 messages are encapsulated within H.225 messages without using a separate H.245 TCP connection. When tunneling is enabled, one or more H.245 messages can be encapsulated in any H.225 message. H.245 tunneling is not supported as a stand-alone feature; initiation of H.245 tunneling procedures can be initiated only by using the dtmf-relay command and only from an active fast connect call. Furthermore, if dtmf-relay is configured on a Version 2 VoIP dial peer and the active call has been established by using fast connect, tunneling procedures initiated by the opposite endpoint are accepted and supported.

H.245 tunneling is backward compatible with H.323 Version 1 configurations.

Posted in CallManager | Tagged , , | Leave a comment



  • Admission Control Combined with Low Latency Queueing
  • LLQ provides a means to forward voice traffic with strict priority
  • The LLQ is not supported on any tunnels.
  • RSVP support for LLQ on Frame Relay permanent virtual circuits (PVCs) and Asynchronous Transfer Mode (ATM) PVCs is currently not available. Support is planned for future releases.


•RFC 2205 (Resource Reservation Protocol)
•RFC 2210 (RSVP with IETF Integrated Services)
•RFC 2211 (Controlled-Load Network Element Service)
•RFC 2212 (Specification of Guaranteed Quality of Service)
•RFC 2215 (General Characterization Parameters for Integrated Service Network Elements)

Posted in Notes | Leave a comment

Configuring Secure SCCP VG224 (VG2XX) Over TLS with CUCM

This report explains and gives the steps to be done to activate secure VG224 as SCCP , on this report I use the router as Certificate authority (CA) , if you use third party CA , there will be a slight difference ,some steps has to be done manually

•    You must activate security mixed mode on the callmanager
•    You must activate the http server on the Cisco Router by typing (ip http server) , this will allow the enrolment with the CA server
Note: The call manager has two modes, non secure mode and mixed mode, when using mixed mode both IP phone (secure profile and non secure profile can register with the CUCM)
Note: To use mixed mode you must buy the security tokens and use the CTL client to upload the certificate

Router(config)# crypto pki server vg224caserver
Router(cs-server)# database level complete
Router(cs-server)# database url slot0:
Router(cs-server)# issuer-name CN=vg224caserver
Router(cs-server)# grant auto
% This will cause all certificate requests to be automatically granted.
Are you sure you want to do this? [yes/no]: y
Router(cs-server)# no shutdown
% Once you start the server, you can no longer change some of
% the configuration.
Are you sure you want to do this? [yes/no]: y
% Generating 1024 bit RSA keys …[OK]
% Certificate Server enabled.

Note: The    grant auto command is used to allow the automatic acceptance of enrolment to the CA server

Router(config)#crypto pki trustpoint VG224ca
Router(ca-trustpoint)# enrollment url http://X.X.X.X
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# exit
The X.X.X.X is the IP address of the SRST Router, with the configuration above, you say, my certificate name is srstca , it will enroll with the server x.x.x.x , it will be valid for ever

Router(config)# crypto pki authenticate VG224ca
Certificate has the following attributes:
Fingerprint MD5: 4CA53F 50C65894B7D 71DBFD7 75DDBFCA
Fingerprint SHA1: 5C3B6B9E E7 F6A8269DFA458DA6F39F20918A B2 91
% Do you accept this certificate? [yes/no]: y
Trustpoint CA certificate accepted.

Router(config)# crypto pki enroll VG224ca
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Re-enter password:
% The fully-qualified domain name in the certificate will be:
% The subject name in the certificate will be:
% Include the router serial number in the subject name? [yes/no]: y
% The serial number in the certificate will be: D0B9E79C
% Include an IP address in the subject name? [no]: n
Request certificate from CA? [yes/no]: y
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The ‘show crypto pki certificate’ command will also show the fingerprint.

crypto pki server srstcaserver
no grant auto
no shutdown

Note: For security reason deactivate auto enrollment on the CA server

From Cisco Unified Communications Operating System Administration, under certificate management menu download all certificates in PEM listed under CAPF-trust, including :
CAPF, and
Also download any CAPF-xxx certificates that are listed under CallManager-trust only
Note: Not all of the above certificate are needed for recent callmanager >5.x  , importing all of them will ensure the validation of this procedure
Note: the needed certificate for CUCM 8.5 is callmanager.pem, Cisco_Root_CA_2048.pem ,  Cisco_Manufacturing_CA.pem,  CAP-RTP-001.pem , CAPF.pem

Hint: How to decide which certificate to import
The last version of CUCM when  writing this procedure was 8.6 , you may want to refer to last procedure from cisco to verify if there is any modification .
The name of the certification may change in future version, here is a way I could verify the needed certifications. Open the certification file in a text editor program (Notepad++) And verify the end of the certificate , it must match the one indicated by Cisco Guide

Ex :
In the Cisco guide it says execute the following command crypto pki trustpoint CiscoCA
CiscoCA is the name of the trust point or the certificate, you will never find this name on the callmanager Certificate managemanet page (>5.X)
When comparing the certificate in the Cisco guide

You will notice that it ends with 2Q== the only certificate on the call manager that ends with 2Q== is CAP-RTP-001.pem certificate
I have also noticed that CAPF-82c946c6.pem and CAPF.pem is in fact the same certificate
Below is the name of each certificate file name found on the CUCM 8.6 and the only needed certificate to be imported.
CAP-RTP-001.pem= CiscoCA
Cisco_Manufacturing_CA.pem= CiscoManufactureCA
Cisco_Root_CA_2048.pem= CiscoRootCA2048

Callmanager.pem (of the publisher)
Router(config)# crypto pki trustpoint callmanagerPub
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate callmanagerPub
PS: if you have more than one server , then you will need to include their callmanager.pem certificate , please see (3.5.2) at the end of this report

Callmanager.pem (of the subscriber)
Router(config)# crypto pki trustpoint callmanagerSub
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate callmanagerSub

PS: In fact you will need only the callmanager.pem of the callmanager members group servers , so suppose you have callmanager group called Group1 that contain SERV1 , SERV2 and SERV3 , then you will need the three PEM certificate

Router(config)# crypto pki trustpoint CAPF
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate CAPF
Now open the CAPF.pem with a text editor and copy and paste all the text inside ,then hit enter until you get the below prompt :
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
Repeat the same steps to the rest of the certificates:

Router(config)# crypto pki trustpoint CiscoCA
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate CiscoCA

Router(config)# crypto pki trustpoint CiscoManufactureCA
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate CiscoManufactureCA

Router(config)# crypto pki trustpoint CiscoRootCA2048
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# exit
Router(config)# crypto pki authenticate CiscoRootCA2048

Router(config)crypto pki export VG224ca pem terminal
Copy the text and past it to text editor , name your file Vg.pem
Begin and end line must be included



From Cisco Unified Communications Operating System Administration, under certificate management menu, click on upload certificate
Chose callmanager trust type, give a description and point to the vg.pem file that you have exported
You must set some parameters

Chose the secure profile under each port , notice if you configure security on the VG , you must apply it to all ports
PS:  you can’t have a port on secure mode and another port as non secure port


STC application:

no stcapp
stcapp ccm-group 1
stcapp security trustpoint VG224ca
stcapp security mode encrypted

sccp local FastEthernet0/0
sccp ccm identifier 1 version 7.0
sccp ccm identifier 2 version 7.0
sccp ip precedence 3

Note: notice that I have 2 callmanager , so you must import both certificate , create 2 trust  point callmanagePub and callmanagerSub , then import the corresponding file callmanager.pem found on each server

sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2

dial-peer voice 99900 pots
service stcapp
security mode encrypted
port 2/0

PS: you must create a dial peer for each port , if you don’t the port will not register

Posted in CallManager, Gateway, LAB | Tagged , , , , , | Leave a comment

pattern ext-to-ext

The Cisco SRS Telephony router provides flexibility for the integration with any legacy voice-mail system. You can configure multiple tags and tokens for each pattern, depending on the voice-mail system and type of access. The tag in the configuration pattern must match the number defined in the voice-mail system’s integration file to identify the type of call. The keywords—CGN (calling number), CDN (called number), and FDN (forwarding number)—define the type of call information sent to the voice-mail system.



Posted in LAB, Notes | Leave a comment

Voice Over IP – Per Call Bandwidth Consumption

Bandwidth Calculation Formulas

These calculations are used:

  • Total packet size = (L2 header: MP or FRF.12 or Ethernet) + (IP/UDP/RTP header) + (voice payload size)
  • PPS = (codec bit rate) / (voice payload size)
  • Bandwidth = total packet size * PPS

Sample Calculation

For example, the required bandwidth for a G.729 call (8 Kbps codec bit rate) with cRTP, MP and the default 20 bytes of voice payload is:

  • Total packet size (bytes) = (MP header of 6 bytes) + ( compressed IP/UDP/RTP header of 2 bytes) + (voice payload of 20 bytes) = 28 bytes
  • Total packet size (bits) = (28 bytes) * 8 bits per byte = 224 bits
  • PPS = (8 Kbps codec bit rate) / (160 bits) = 50 pps

    Note: 160 bits = 20 bytes (default voice payload) * 8 bits per byte

  • Bandwidth per call = voice packet size (224 bits) * 50 pps = 11.2 Kbps


Posted in LAB, Notes | Leave a comment

MTP Over Subscription

If all n MTP transcoding sessions are utilized, and an n + 1 connection is attempted, the next call will complete without using the MTP transcoding resource. If this call attempted to use the software MTP function to provide supplementary services, the call would connect, but any attempt to use supplementary services would fail and could result in call disconnection. If the call attempted to use the transcoding features, the call would connect directly, but no audio would be received. If a transcoder is required but not available, the call would not connect.


Posted in LAB, Notes | Tagged , , | Leave a comment

RTP timestamp

RTP and RTCP—(Real-Time Transport Protocol and RTP Control Protocol) Protocols used to sequence the audio and video packets. The RTP header contains a time stamp and sequence number, allowing the receiving device to buffer as much as necessary to remove jitter and latency by synchronizing the packets to play back a continuous stream of sound. RTCP is used to control RTP. It gathers reliability information and periodically passes this information onto session participants.




Posted in LAB, Notes | Tagged , | 1 Comment