Introduction
This article describes a method for troubleshooting improper detection of RFC 2833 DTMFs in either an RTP or DS0 endpoint when using the Dialogic® NaturalAccess™ Fusion™ VoIP API.
In order to perform the analysis, we start by running msppsamp in order to create a Fusion channel on the Dialogic CG Series Media Board.
Then, using a Wireshark trace that has captured RTP streams containing the RFC 2833 DTMFs in question, we extract the stream and play it towards the CG Series Board using a tool called rtpplay.exe.
Tools
Wireshark Version 1.2.5 or later which can be downloaded from the Internet.
rtpplay.exe which is a Windows utility used to play RTP streams to a designated IP address and port.
msppsamp.exe which is a Natural Access Fusion demo program delivered with the Natural Access installation.
ctatest.exe which is a Natural Access demo program delivered with the Natural Access installation.
Files referenced in the procedure below are available for download in a single zip file.
Procedure
- Use Wireshark 1.2.5 to open the file rfc2833.pcap from the zip file.
- To list all the RTP streams by selecting Telephony-->RTP-->Show All Streams.
- When the RTP Streams box appears, select the stream of interest
- To verify that you have selected the correct stream, click on Prepare Filter and click Close.
- In the main screen, to the right of the Filter box, click Apply. You will now see all packets associated with that RTP stream
- Scroll down to verify that it contains the DTMF packets. Below you can see a packet for DTMF 0 highlighted and below that you can see the Payload type highlighted showing that that the payload ID is 101 (telephone-event).
- Once you have identified the stream, save it by going back to Telephony-->RTP-->Show All Streams. Click on the RTP stream that contains the DTMFs and click the Save button and save the file as, for example, dtmfstream.dat. For the purposes of this note, you can use the file payloadid-101.dat (in the zip file) which contains RFC 2833 DTMFs with a payload ID of 101.
- Boot the CG 6565 using the oamsys.cfg and cg6565fusion.cfg files in the zip file. You will probably need to change the following line in the cg6565fusion.cfg file : IPC.AddRoute[0].DestinationAddress so that it conforms to your network addressing scheme.
- To verify that the board is configured correctly for IP, type cgroute print. Then ping the IP address.
- Launch the Natural Access Fusion msppsamp demonstration program (delivered with the NaturalAccess installation) using the DOS batch file mspp.bat in the zip file. Be sure to change the host and CG board IP addresses accordingly. Refer to the comments in the mspp.bat file. Keep in mind that the IP address defined by IPC.AddRoute[0].DestinationAddress in the cg6565fusion.cfg file needs to match the -l address in the mspp.bat file.
- Launch the Natural Access ctatest demonstration program (delivered with the NaturalAccess installation) by typing ctatest -s1 -S.
- Make a switch connection between timeslots 0 and 1 by using the switchit.bat (see the zip file) . Timeslot 0 is used by Fusion so that data received on port 50000 (see -u parameter in mspp.bat) is played out to this timeslot. By making a switched connection between timeslots 0 and 1, ctatest can be used to monitor the output to timeslot 0.
- If using the payloadid-101.dat file provided in the zip file, then you need to adjust the payload ID for the channel. This is done through msppsamp by typing b, then 5 and then entering 101 for the payload ID.
- With msppsamp and ctatest running, play the RTP stream payloadid-101.dat using rtpplay by typing (in a separate window):
rtpplay -T -f %1 10.128.16.200/50000 - You will see the RFC 2833 DTMFs being detected in the window running msppsamp (left) and DTMF tones being detected by ctatest on the right.
Analysis
For details on RFC 2833 DTMFs, refer to this URL: www.faqs.org/rfcs/rfc2833.html (Dialogic is not responsible for the content of external sites).
For RFC 2833 DTMFs, each digit is comprised of several RTP packets. Each packet contains a few fields that are of interest for this discussion.
- Event ID: Identifies the DTMF key
- End of Event: Indicates whether this packet is the last for the current digit. Refer to the screenshot of the Wireshark trace above, specifically the End of Event in the section RFC 2833 RTP Event. For this packet, it is set to False and therefore there are more packets to follow for this digit. It is not uncommon to see the 'end' packet being sent up to three times as can be seen in the msppsamp window on the left.
- Event Duration: Current duration of this digit (not the actual packet) in timestamp units. Typically the duration for the first packet for a digit is 0 but is not required to be 0. The duration of the last packet for a digit indicates the complete duration of the RFC 2833 event in timestamp units. Timestamp units are specified in the SDP. For this trace, the sampling rate for RFC 2833 events is 8000 Hz. Therefore, if you take the duration of the 'end' packets and divide by 8000, it will yield the actual length of the DTMF. For example, in this trace, the duration in the end packet (packet 2584) for DTMF 8 is 2000 which when divided by 8000 yields 250 ms.
When the RFC 2833 DTMF packets are received in the Fusion channel, the channel needs to decode them and then play a steady DTMF tone to the DS0 until the 'end' packet is received. ADI needs about 50 ms of tone in order to detect a DTMF tone. The Fusion channel needs to account for latency in the arrival of the RFC 2833 DTMF packets and therefore it needs to continually play the tone to the DS0 even in the event that some of the DTMF packets have been delayed in reaching the RTP endpoint.
In cases where DTMF detection is failing, the cause could be in the detection at the RTP endpoint or at the DS0 endpoint.
Failure to detect DTMFs in the RTP endpoint are typically due to an incorrect payload ID for the RFC 2833. In the picture of the Wireshark trace above, you will see Payload Type: telephone-event (101). In the procedure above we configured the channel to recognize 101 as the RFC 2833 payload ID. If the sender of the DTMFs were to use a different payload ID, the Fusion channel would not detect these packets.
Failure to detect DTMFs in the DS0 could be caused by the Fusion channel not playing a continuous DTMF tone. This is likely due to latency in the arrival of RFC 2833 DTMF packets. By default, the decoder will play 3 frames of DTMF tone to the DS0. In the case of the G.711 codec, the Fusion channel plays 10 ms frames to the DS0. For each RFC 2833 packet received the channel plays 30 ms of DTMF tone based upon a default playout value of 3 frames. Therefore, if the time between arriving RFC 2833 DTMFs is greater than 30 ms, there will be a gap in the tone being played to the DS0 and the DTMF detector will not detect the tone. In this case, modifying the playout value is one option to accommodate for this behavior. For details on configuring the playout value, refer to the Dialogic® NaturalAccess™ Fusion™ VoIP API Manual.
Links
The Wireshark tool is available at http://www.wireshark.org/ (Dialogic is not responsible for the content of external websites)