This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RTP packet analysis: L16

0

Hello,

I have a wireshark trace of an RTP stream with the following properties:

  • PT = 96
  • Payload contains L16 at 16000Hz

I would like to get basic RTP statistics out of that stream like I am used to get with RTP streams containing G711A/U payload. But when I go to stream analysis, all the statistics are set to zero.

Are there any ways to get those statistics using wireshark?

Please find below a link to the wireshark capture: http://wikisend.com/download/851646/tcp-mmh-not-dropping.pcap

Best regards, Julien.

asked 27 Jan '16, 05:19

jpa's gravatar image

jpa
16226
accept rate: 0%

edited 27 Jan '16, 05:33

1

Are you sure the reason is the payload type? Do ssrc, rtp seq no, rtp timestamp values look the way they should? Publishing an example of such capture somewhere and providing a link to it allows others to have a look and see whether it is a Wireshark issue or whether the source of those RTP packets has one.

(27 Jan '16, 05:25) sindy
1

OK, while the ssrc, seq no and timestamp seem fine, the RTP payload size is unusual: 512 bytes = 256 samples per packet, which means a p-time of 16 ms for a 16 kHz sample rate/mono. But most important, RFC3550 says the following:

The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or MAY be specified dynamically for payload formats defined through non-RTP means.

So as Wireshark does not know the actual payload type and its timestamping rules, because a matching SDP is missing in the capture, it cannot choose the correct way to evaluate the timestamp. Nor can it use the payload type number because it is a dynamic one.

Is it possible for you to capture also the call control protocol carrying the SDP or none is used in your application?

(27 Jan '16, 05:59) sindy

No control protocol is used since by design it was not needed to add one.

Are there any ways to input such informations manually to wireshark?

(27 Jan '16, 06:07) jpa

One Answer:

1

As the RTP timestamp contents differs depending on the payload type, and the payload type for your L16 capture is dynamic, the RTP analysis doesn't know the meaning of the RTP timestamps in it and so cannot compare frame timestamps (assigned during capture) to RTP timestamps in order to evaluate jitter etc.

To my best knowledge, there is no way to tell Wireshark how to treat a particular dynamic payload type using any Wireshark configuration. But you can forge a SIP INVITE carrying the necessary SDP, populating the SDP with information matching the destination of your RTP flow (connection socket, codec list and codec parameters), capture that packet, edit its frame time before merging chronologically with your original capture, and merge it with it.

To do that,

  • you can use SIPp,

  • you can create the INVITE using a text editor, convert the text to hex, add the ethernet, IP and UDP headers, calculate the checksums, and then import that hex into Wireshark. If I were you, I wouldn't do that manually, and if you would use code, you could as well generate a .pcap file straight away.

  • probably the easiest way is to set up a telnet session to some tolerant server, start the capture, copy-paste the text of the INVITE into the client window and hope that the telnet application sends it as a single packet. In this case, you may have to use Decode as to tell Wireshark that this TCP packet is a SIP one after merging.

I've just tried the SIPp method, it really does help the RTP analysis a lot.

The text of the INVITE for the capture you've posted looks like this (you have to remove the excess \ from the From and To contents, that's a bug of this site):

INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK-14828-1-0 From: <\sip:unavailable>;tag=1 To: test number <\sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 INVITE Contact: sip:[email protected]:5060 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 135

v=0 o=user1 53655765 2353687637 IN IP4 10.10.10.10 s=- c=IN IP4 10.20.1.39 t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 L16/16000

answered 27 Jan '16, 07:20

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 27 Jan '16, 07:20

Thanks for the hint, I just tried it but it's still not ok :(

I have generated a SIP/SDP INVITE packet using sipp. This SIP/SDP packet contains the correct SDP for L16 16000Hz.

I merged the RTP stream I had with this extra SIP/SDP INVITE packet, but still wireshark is not able to give me any statistics...

Please see the merged file on the following link: - http://wikisend.com/download/913750/rtp-and-sdp-merged.pcapng

BTW: how do you change the frame time, I think that's what is making the merge not ok and so the statistics not being calculated...

(27 Jan '16, 08:37) jpa
1

Just a little bit (actually, exactly two) needs to be fixed in your SDP:

  • the port on the m= line is the destination one which is correct,

  • the IP address on the c= line is the source one (10.20.1.40) instead of correct destination one (10.20.1.39).

(27 Jan '16, 08:43) sindy

Arf indeed the c line was not correct, thanks a lot, now wireshark is able to give me the statistics :)

(27 Jan '16, 09:03) jpa
1

As usually - the site's symbolics is not self-explanatory enough:

by pressing the "thumbs up" button at the answer, you've raised my karma (thank you), but you haven't marked the answer as useful for other folks eventually coming with a similar question. To do so, you have to accept the answer by clicking the checkmark icon. This raises the karma of the author of the answer even more than the "thumbs up", but the most important thing is that the question is then visible as "usefully answered" in the list as its number of answers is then shown at green background. Nobody than the author of the question can do this (while anyone can press the "thumbs up"). Please don't ask me why it is done like this.

(27 Jan '16, 09:24) sindy

The reason for it is "because it's coded that way", See this OSQA question on permissions to mark an answer as accepted.

(27 Jan '16, 09:54) grahamb ♦

@grahamb, it is just my ambiguous order of sentences causing your misunderstanding, and I'm not sure this is the right place to discuss it, so we shall probably delete these comments later on? It should be easy for you as site admin to find my e-mail if you feel like continuing the discussion.

I definitely don't dispute the fact that no one than the author of the question may accept answers; I claim that so many authors of questions intend to do so but choose the wrong icon, so there must be something wrong about the graphics which misleads them (so if I feel like asking them to do it properly, I usually end up with 25+15 instead of just 25). So I'd like something like those two icons to be moved right next to each other, the checkmark one more to the left or more to the top, and the thumbs up one to be noticeably inactive for the authors of the question until they press the checkmark for at least one of the answers. If I get the logic right, you cannot make their first press of the thumbs up be automatically counted also as pressing the checkmark because you must keep the possibility to upvote (and also withdraw the upvote!) independent from operating the checkmark.

I cannot see further/deeper as I never had a chance to choose which one from several answers I want to accept :-)

(27 Jan '16, 10:17) sindy

That would require a change to OSQA, feel free to take the issue up with them.

My cynicism runs deep though, users frequently fail to mark an answer as accepted, even with reminders (have you looked at the "canned comments" options?), and no amount of re-arranging the graphical deckchairs is likely to change that.

Even with admin privs, I'm loathe to mark an answer as accepted as I might have mis-understood something in the question or answer. I do upvote answers occasionally though.

(27 Jan '16, 10:44) grahamb ♦
showing 5 of 7 show 2 more comments