There are multiple ways in which DTMF tones are transmitted over a VoIP connection. These include:
Inband – In this method, the DTMF tones are transmitted just as normal voice audio using the same codec and with no special coding to identify it as different from the voice.
RFC2833 – In this case, DTMF is transmitted based on the defined standards for DTMF tones, fax tones etc.
SIP signaling – This can be done only through SIP channels where DTMF tones are transmitted through an SIP message after a handshake with the receiving end for negotiating preferences and establishing the parameters for the call.
DTMF over VoIP is more prone to errors, as the receiving end often fails to recognize the DTMF or interprets it incorrectly. One of the possible causes of trouble is when there is switching between in‐band DTMF and RFC2833 modes in the VoIP route. For example, assume a VoIP device is transmitting an in‐band DTMF signal and a switch converts it to RFC2833 DTMF for further transmission, which finally terminates in a system that requires a regeneration of the in‐band audible tones. Sometimes, the switch fails to completely remove the audible DTMF tones while converting to RFC2833, thus resulting in a combined garbled message received by the voicemail system, causing it to report an error.
Yet another cause of concern is packet loss, which creates issues in DTMF over VoIP transmissions. Changing the DTMF settings is one way of troubleshooting such problems, and the RFC2833 DTMF setting is the most reliable. The in‐band DTMF where the G729 codec is used is the most un‐reliable due to compression related issues.
So, in terms of SIP, how is this RFC 2833 stream created and managed? Through Session Description Protocol (SDP), of course. SDP is used to describe the voice stream (e.g. G.729) and it’s also used to inform the recipient that RFC 2833 is available. Specifically, it uses something called telephone-event. Here is an example of an SDP media description that you might see in the body of an Invite message. Note the format of “0 – 16.” This represents the ten digits plus *, #, A, B, D, E, and Flash.
m=audio 12346 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
That’s probably about as much as you really need to understand about RFC 2833 and how it works. Its purpose is to create a separate stream for DTMF to allow voice codecs to strictly deal with creating the best possible voice stream using the fewest number of bytes. If you remember that you will be ahead of the game.
references:
https://www.specialtyansweringservice.net/wp-content/uploads/resources_papers/dtmf-tone/Dual-Tone-Multi-Frequency-Signalling.pdf
Inband – In this method, the DTMF tones are transmitted just as normal voice audio using the same codec and with no special coding to identify it as different from the voice.
RFC2833 – In this case, DTMF is transmitted based on the defined standards for DTMF tones, fax tones etc.
SIP signaling – This can be done only through SIP channels where DTMF tones are transmitted through an SIP message after a handshake with the receiving end for negotiating preferences and establishing the parameters for the call.
DTMF over VoIP is more prone to errors, as the receiving end often fails to recognize the DTMF or interprets it incorrectly. One of the possible causes of trouble is when there is switching between in‐band DTMF and RFC2833 modes in the VoIP route. For example, assume a VoIP device is transmitting an in‐band DTMF signal and a switch converts it to RFC2833 DTMF for further transmission, which finally terminates in a system that requires a regeneration of the in‐band audible tones. Sometimes, the switch fails to completely remove the audible DTMF tones while converting to RFC2833, thus resulting in a combined garbled message received by the voicemail system, causing it to report an error.
Yet another cause of concern is packet loss, which creates issues in DTMF over VoIP transmissions. Changing the DTMF settings is one way of troubleshooting such problems, and the RFC2833 DTMF setting is the most reliable. The in‐band DTMF where the G729 codec is used is the most un‐reliable due to compression related issues.
So, in terms of SIP, how is this RFC 2833 stream created and managed? Through Session Description Protocol (SDP), of course. SDP is used to describe the voice stream (e.g. G.729) and it’s also used to inform the recipient that RFC 2833 is available. Specifically, it uses something called telephone-event. Here is an example of an SDP media description that you might see in the body of an Invite message. Note the format of “0 – 16.” This represents the ten digits plus *, #, A, B, D, E, and Flash.
m=audio 12346 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
That’s probably about as much as you really need to understand about RFC 2833 and how it works. Its purpose is to create a separate stream for DTMF to allow voice codecs to strictly deal with creating the best possible voice stream using the fewest number of bytes. If you remember that you will be ahead of the game.
references:
https://www.specialtyansweringservice.net/wp-content/uploads/resources_papers/dtmf-tone/Dual-Tone-Multi-Frequency-Signalling.pdf
No comments:
Post a Comment