trace DTMF on cisco
Stuff useful and necessary. The truth is not always obvious. In this article I would like to highlight the basic methods of transmitting DTMF signals and their Debug (to fix the material in my head and to parse 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 conversational path) and out-of-band (indulging outside the conversational path by means of any signal channel). Consider the basic methods of DTMF, as well as several ways to trace them.
1. h245 methods:
')
h245-signal:
The method of DTMF transmission using the h.245 signaling channel in the h.323 protocol. This method transmits messages that contain not only the value of the number being transferred, but also its duration.
p245-alphanumeric:
Like the first one, it sends messages on 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.
These methods can be traced using the command
debug h245 asn1
2. cisco-rtp:
As the name implies, this method was invented by cisco engineers, and therefore it was recommended for transmission between cisco equipment. It transmits messages on the same channel as voice traffic, but the messages themselves are encoded differently and identified by different Payload Type indices.
3. SIP INFO:
SIP protocol method. It sends messages over the signaling channel of the SIP protocol and therefore is an out-of-band method. By default it is enabled, but not always used due to the priority of using protocols, so in order to see it you need to enable some of the h.245 methods in the dtmf-relay functions. Tracing is done by the team
4. rtp-nte:
A method that can be used regardless of the protocol. This is a method described in the RFC2833 standard. In-band method that uses special NTE (named telephone events) for DTMF transmission, which are transmitted in the same stream with RTP traffic, but are 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 info 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 conversational path) and out-of-band (indulging outside the conversational path by means of any signal channel). Consider the basic methods of DTMF, as well as several ways to trace them.
1. h245 methods:
')
h245-signal:
The method of DTMF transmission using the h.245 signaling channel in the h.323 protocol. This method transmits messages that contain not only the value of the number being transferred, but also its duration.
p245-alphanumeric:
Like the first one, it sends messages on 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.
These methods can be traced using the command
debug h245 asn1
2. cisco-rtp:
As the name implies, this method was invented by cisco engineers, and therefore it was recommended for transmission between cisco equipment. It transmits messages on the same channel as voice traffic, but the messages themselves are encoded differently and identified by different Payload Type indices.
3. SIP INFO:
SIP protocol method. It sends messages over the signaling channel of the SIP protocol and therefore is an out-of-band method. By default it is enabled, but not always used due to the priority of using protocols, so in order to see it you need to enable some of the h.245 methods in the dtmf-relay functions. Tracing is done by the team
debug ccsip messages4. rtp-nte:
A method that can be used regardless of the protocol. This is a method described in the RFC2833 standard. In-band method that uses special NTE (named telephone events) for DTMF transmission, which are transmitted in the same stream with RTP traffic, but are 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 info will be useful to the reader.
Source: https://habr.com/ru/post/139204/
All Articles