Wireshark question
John
I used wireshark to capture a SIP session with G711 audio and extract the
RTP packets.
When I select telephony -> RTP -> Stream Analysis and save the payload
as a .au file (channel = forward) the audio is distorted (clicks/pops).
However, when I select Telephony -> RTP -> Stream Analysis and click the
Player button and then the Decode button, a window pops up with 2 charts.
I don't know why there are two charts. On one of the charts I see the spikes
that causes the pops and clicks in the audio. But when I click the play
button
the audio sounds fine.
So I am not sure whether there is a bug in Wireshark or if the encoded G711
audio
in the RTP packets contains errors.
I am hoping somebody could take a quick look at the capture and tell me what
they think?
Thank you.
Here is a link to the files:
When you open the capture file in wireshark the RTP packets will show up as
UDP packets. You can change this by right-clicking one of the UDP packets
and choose "Decode As.." and then select RTP in the window that pops up and
hit OK.
John
> I took a look at the file. No SIP there, but just rtp, g.711 ulaw. _lots_
> of jitter. Way beyond the requirements for a stable SIP call.
Yes, I deleted all other packets except RTP.
I installed a softphone on a stationary computer and made a call from that
phone
to a softphone on my Android cell phone. The Android phone received the
SIP call via WiFi on a different network. So that might explain the jitter
you saw?
> Your observation is the standard jitter problem. When you play the stream
> in retrospect, all the packets are there, so wireshark can play out all
> the sound.
I don't agree. I think Wireshark is not capable of demultiplexing RTP packet
streams which is what the capture shows...The RTP stream is a stream of
multiplexed
RTP packets...some with payload type 101 and others with payload type 0.
Anyway...The payload type 101 packets shouldn't be there as they are
"out-of-band" DTMF tones...You don't signal DTMF tones _and_ send RTP
packets on top of that...that doesn't make any sense in my head. Either you
signal DTMF tones or you send the actual DTMF audio in RTP packets.
> But when the actual telephones did the call, you had a window of somewhere
> between 18 and 42 milliseconds for the packets to get there. Depending
> on the actual SIP implementation. (Or, RTP audio side). And a significant
> part of these packets got there, but too late to be useful.
That's a whole other issue :o)
Morten Reistad
John <jo...@nospam.thanks> wrote:
>
>> I took a look at the file. No SIP there, but just rtp, g.711 ulaw. _lots_
>> of jitter. Way beyond the requirements for a stable SIP call.
>
>Yes, I deleted all other packets except RTP.
>
>I installed a softphone on a stationary computer and made a call from that
>phone
>to a softphone on my Android cell phone. The Android phone received the
>SIP call via WiFi on a different network. So that might explain the jitter
>you saw?
I have no way of confirming what the reason for the jitter is, just that
it is there, and that it would make the use of ptime=20 ulaw encoding
a pretty doomed endeavour.
Try ptime=40 or 60, and use GSM 06.10, or a G.729 windowed redundancy
encoding, if your softphones support that. Or increase the jitter buffer
to 200 ms or thereabouts.
>> Your observation is the standard jitter problem. When you play the stream
>> in retrospect, all the packets are there, so wireshark can play out all
>> the sound.
>
>I don't agree. I think Wireshark is not capable of demultiplexing RTP packet
>streams which is what the capture shows...The RTP stream is a stream of
>multiplexed
>RTP packets...some with payload type 101 and others with payload type 0.
>Anyway...The payload type 101 packets shouldn't be there as they are
>"out-of-band" DTMF tones...You don't signal DTMF tones _and_ send RTP
>packets on top of that...that doesn't make any sense in my head. Either you
>signal DTMF tones or you send the actual DTMF audio in RTP packets.
The stream is plain ulaw. I checked it again. There are som other non-rtp
packets in there, but they are inconsequential. From wiresharks analysis
you need a jitter buffer of around 400 milliseconds to successfully play
this stream perfectly, but a buffer of 200 ms together with good plc
should give somewhat acceptable sound.
Frankly, you need to analyse this with far more professionalism if you
are going to make any headway. You are struggling with more than one
problem, probably with several.
Please post a full packet trace if you want more help.
>> But when the actual telephones did the call, you had a window of somewhere
>> between 18 and 42 milliseconds for the packets to get there. Depending
>> on the actual SIP implementation. (Or, RTP audio side). And a significant
>> part of these packets got there, but too late to be useful.
>
>That's a whole other issue :o)
No, this is what your exact problem is. Or, one of them. The jitter on
this network is really bad, enough to make even the surfing experience
bad.
-- mrr
John
> Please post a full packet trace if you want more help.
>
Give me a couple of days and I will post it.
Thank you :o)