August 8, 2012 at 12:02trace DTMF on cisco
The piece is useful and necessary. The truth is not always obvious. In this article, I would like to highlight the main methods of transmitting DTMF signals and their Debug (for fixing material in my head and for analysis for others).
So. Let's get started. First you need to remember that DTMF methods can be 2 types of in-band (transmitted within the spoken path) and out-of-band (transmitted outside the spoken path by means of any signal channel). Consider the basic DTMF methods, as well as several ways to trace them.
1. h245 methods:
h245-signal:
DTMF transmission method by means of the h.245 signaling channel in the h.323 protocol. This method transmits messages that contain not only the meaning of the transmitted digit, but also its duration
p245-alphanumeric:
Like the first one, it transmits messages in the h.245 channel of the h.323 protocol, but its difference from the previous one is that the number is transmitted as an ASCII character with a fixed duration of 500ms.
You can trace these methods using the
debug h245 asn1
2 command . Cisco -rtp:
As the name implies, this method was invented by cisco engineers, which means it is recommended for transmission between cisco equipment. It transmits messages on the same channel as voice traffic, but the messages themselves are encoded differently and are identified by different Payload Type indices.
3. SIP INFO:
SIP protocol method. sends messages over the SIP signaling channel, which means it is an out-of-band method. By default it is enabled, but not always used due to the priority of using protocols, so to see it you need to enable some of the h.245 methods in the dtmf-relay functions. Tracing is done with command
4. rtp-nte:
A method that can be used regardless of the protocol. This is the method described in RFC2833 . in-band method that uses special NTE (named telephone events) for DTMF transfer, which are fartered in the same stream with RTP traffic, but encoded somewhat differently. Descriptions of these events can be found at the above link to the RFC2833 standard as well as in the 4733 standard. Our event is number 101 (Line lockout tone).
PS
G.723.1 and G.729 codecs incorrectly decode NTE, so it is recommended to use the SIP INFO method.
I hope the information will be useful to the reader.
So. Let's get started. First you need to remember that DTMF methods can be 2 types of in-band (transmitted within the spoken path) and out-of-band (transmitted outside the spoken path by means of any signal channel). Consider the basic DTMF methods, as well as several ways to trace them.
1. h245 methods:
h245-signal:
DTMF transmission method by means of the h.245 signaling channel in the h.323 protocol. This method transmits messages that contain not only the meaning of the transmitted digit, but also its duration
p245-alphanumeric:
Like the first one, it transmits messages in the h.245 channel of the h.323 protocol, but its difference from the previous one is that the number is transmitted as an ASCII character with a fixed duration of 500ms.
You can trace these methods using the
debug h245 asn1
2 command . Cisco -rtp:
As the name implies, this method was invented by cisco engineers, which means it is recommended for transmission between cisco equipment. It transmits messages on the same channel as voice traffic, but the messages themselves are encoded differently and are identified by different Payload Type indices.
3. SIP INFO:
SIP protocol method. sends messages over the SIP signaling channel, which means it is an out-of-band method. By default it is enabled, but not always used due to the priority of using protocols, so to see it you need to enable some of the h.245 methods in the dtmf-relay functions. Tracing is done with command
debug ccsip messages4. rtp-nte:
A method that can be used regardless of the protocol. This is the method described in RFC2833 . in-band method that uses special NTE (named telephone events) for DTMF transfer, which are fartered in the same stream with RTP traffic, but encoded somewhat differently. Descriptions of these events can be found at the above link to the RFC2833 standard as well as in the 4733 standard. Our event is number 101 (Line lockout tone).
debug voip rtp session named-event 101PS
G.723.1 and G.729 codecs incorrectly decode NTE, so it is recommended to use the SIP INFO method.
I hope the information will be useful to the reader.