Wanting to understand RTP stream analysis delta value

asked 2018-06-22 00:09:01 +0000

sipnot200ok
1 ●1 ●1 ●2

updated 2018-06-22 04:51:04 +0000

13742 ●711 ●115

Hello, I am wanting to understand what the "delta" value represents in the stream analysis, I cant find a good understanding anywhere. I am looking at a RTP stream and after a dmtf payload event representing a digit 8, I can see the Payload changed to PT=8 packet and it has a Delta value of 30.60 ms

Is this Delta 30.312 ms the G711 packetization interval for the digit? I am trying to determine if the G711 codec being used is set to 20ms or they are using 30ms.

For example below , the digit 8 is sent rfc2833 G711 You can see the last packet has a 30.312 delta (3rd column from left) Thankyou in advance

Pkt#    Seq#    Delta   Jitter      Skew    Bandw   Mrk Status
9753    1956    19.614  0.038745247 0.366   81.312  SET Payload changed to PT=101telephone/event
9754    1957    19.614  0.038745247 0.366   81.664      PT=101 telephone/event
9755    1958    19.614  0.038745247 0.366   82.016      PT=101 telephone/event
9760    1959    19.614  0.038745247 0.366   80.768      PT=101 telephone/event
9768    1960    19.614  0.038745247 0.366   81.12       PT=101 telephone/event
9773    1961    19.614  0.038745247 0.366   79.872      PT=101 telephone/event
9781    1962    19.614  0.038745247 0.366   80.224      PT=101 telephone/event
9793    1963    19.614  0.038745247 0.366   78.976      PT=101 telephone/event
9805    1964    19.614  0.038745247 0.366   77.728      PT=101 telephone/event
9817    1965    19.614  0.038745247 0.366   76.48       PT=101 telephone/event
9829    1966    19.614  0.038745247 0.366   75.232      PT=101 telephone/event
9841    1967    19.614  0.038745247 0.366   73.984      PT=101 telephone/event
9853    1968    19.614  0.038745247 0.366   72.736      PT=101 telephone/event
9858    1969    19.614  0.038745247 0.366   71.488      PT=101 telephone/event
9859    1970    19.614  0.038745247 0.366   71.84       PT=101 telephone/event
9860    1971    19.614  0.038745247 0.366   72.192      PT=101 telephone/event
9882    1972    30.312  10.64182367 -0.004  72.192  SET Payload changed to PT=8

edit retag flag offensive close merge delete

Comments

Apologies it did not format well after I posted it.

sipnot200ok ( 2018-06-22 00:13:32 +0000 )edit

add a comment

answered 2018-06-22 05:50:44 +0000

Jaap

13742 ●711 ●115

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.

edit flag offensive delete link

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Wanting to understand RTP stream analysis delta value

Comments

1 Answer

Your Answer

Question Tools

Stats

Wanting to understand RTP stream analysis delta value edit

Comments

1 Answer

Your Answer

Question Tools

Stats

Wanting to understand RTP stream analysis delta value