Strange flow DTMF capture on tcpdump

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, CA开发者_JAVA技巧PTURE 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?

---

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).

---

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.