Strange flow DTMF capture on tcpdump

0
votes

I captured a tcpdump of a SIP call to debug DTMF problem (repeated digits), but I have some problem interpreting it.

From what I understand, when I parse the captured traffic through wireshark's "VOIP CALL", I should see something like this (for digits 123) :

CAPTURE 1
RTP telephone event DTMF One 1
(end of event)
RTP telephone event DTMF Two 2
(end of event)
RTP telephone event DTMF Three 3
(end of event)

But I'm seeing this instead
CAPTURE 2
RTP telephone event DTMF One 1
RTP telephone event DTMF One 1
RTP telephone event DTMF One 1
(end)
RTP telephone event DTMF Two 2
RTP telephone event DTMF Two 2
RTP telephone event DTMF Two 2
(end)
RTP telephone event DTMF Two 3
RTP telephone event DTMF Two 3
RTP telephone event DTMF Two 3
(end)

On 1 system, CAPTURE 2 is detected as 123, but on another system it seems to decode this as having repeated digits. What's the reason for wireshark not grouping them together as a single RTP event?

This is the rtp traffic flow:
CAPTURE 1:

RTP EVENT DTMF 1
RTP EVENT DTMF 1
RTP EVENT DTMF 1 (end)
RTP EVENT DTMF 1 (end)
RTP EVENT DTMF 1 (end)
RTP EVENT DTMF 2
RTP EVENT DTMF 2
RTP EVENT DTMF 2 (end)
RTP EVENT DTMF 2 (end)
RTP EVENT DTMF 2 (end)
RTP EVENT DTMF 3
RTP EVENT DTMF 3
RTP EVENT DTMF 3 (end)
RTP EVENT DTMF 3 (end)
RTP EVENT DTMF 3 (end)
RTP PAYLOAD
...
...
...
RTP PAYLOAD

whereas CAPTURE 2 is:
RTP EVENT DTMF 1
RTP PAYLOAD
RTP EVENT DTMF 1
RTP PAYLOAD
RTP EVENT DTMF 1 (end)
RTP PAYLOAD
RTP EVENT DTMF 1 (end)
RTP PAYLOAD
RTP EVENT DTMF 1 (end)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP EVENT DTMF 2
RTP PAYLOAD
RTP EVENT DTMF 2
RTP PAYLOAD
RTP EVENT DTMF 2 (end)
RTP PAYLOAD
RTP EVENT DTMF 2 (end)
RTP PAYLOAD
RTP EVENT DTMF 2 (end)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP EVENT DTMF 3
RTP PAYLOAD
RTP EVENT DTMF 3
RTP PAYLOAD
RTP EVENT DTMF 3 (end)
RTP PAYLOAD
RTP EVENT DTMF 3 (end)
RTP PAYLOAD
RTP EVENT DTMF 3 (end)
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD
RTP PAYLOAD

Is CAPTURE 2 following RFC2833?

2
siprtpdtmf

2 Answers

3
votes

Actually, the spec encourages you to redundantly-transmit RTP Event packets, because of possible packet loss, and they suggest sending each 3 times at least. Check the start and end times in each duplicated event. If you need to extend the event (key still held down, longer than you want to encode in one event, etc), then you can extend it without ending it.

This is also why the End packets are sent 3 times. (See section 3.6 of RFC 2833).

2
votes

It's perfectly possible for an RFC 2833 "event" to be encoded as multiple RTP packets. Section 3.6 tells us that

If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly.

The RFC defines "one period" as 50ms.

So

RTP EVENT DTMF 1
RTP EVENT DTMF 1
RTP EVENT DTMF 1 (end)

means that we have someone pressing the 1 key for around 150ms.