Hello, I have a wireshark trace of an RTP stream with the following properties:
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 edited 27 Jan '16, 05:33 |
One Answer:
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 To do that,
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
answered 27 Jan '16, 07:20  sindy 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:
(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 |
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.
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?
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?