 | 1 | initial version |
From the menu try setting the Time display format to 'Seconds since previous displayed packet', and then filter the packet list for RTP. You'll see that the time column of the packet overview pane matches the delta column of the RTP stream analysis dialog.
As for the rest, you need to start making a clear distinction between Voice (encoded in G711, i.e., PT=8) and Events (encoded in RFC 2833, i.e., PT=101). So "the digit 8 is sent rfc2833 G711" makes no sense.
What happens in this analysis is that the first packet shown signals the start (hence the RTP marker) of Event sequence of RTP packets. The way these packets are encoded and the rate at which these are send is determined by RFC 2833 and what is negotiated at sessions establishment, e.g., through SDP. In this case the packets come in at an approximate 20 ms rate, whereby the RTP packet content probably defines the presence of a DTMF digit with an increasingly long duration.
This continues until the last packet with PT=101, which should be an Event packet with the End bit set (actually the last three Event packets should have that). After the termination of the Event packet stream the normal Voice packet stream commences again, as signified by the last packet having its RTP marker bit set.
Now the tricky part is how both these streams are generated, from which packetising clocks. From the delta of the RTP Event packets it can be determined that their packetising rate is 20ms. From the last delta it may appear that the Voice packets have a packetising rate of 30ms. But this is a transition, so we may be mislead.
What we do know is that the RTP Event packets start 20ms after the last Voice packet, and that there are 16 of them. 16 x 20 ms = 320 ms, which is equivalent to 320 / 30 = 10 Voice packets of 30 ms. So after the RTP event packets the packetising clocks of the RTP Event and Voice stream are in sync. Given the fact that the next Voice packet appears 30ms after that confirms that the Voice stream packetising clock is 30 ms.
