This is our old Q&A Site. Please post any new questions and answers at

I have a basic SIP call via G711u codec. (here's CAP)

Somehow my switch doesn't see the incoming RTP flow from to Moreover Wireshark 2.0.3 doesn't associate it either (yes, you can play the missing stream)

alt text

On the other hand when I use Wireshark 1.12.11 the media magically appears in SIP flow:

alt text

Can anyone tell me what has changed in VoIP processing in the new Wireshark so I can overcome my problem with 1-way-voice. Thanks

asked 25 May '16, 09:02

ky4k0b's gravatar image

accept rate: 0%

edited 25 May '16, 09:16

grahamb's gravatar image

grahamb ♦

Can anyone tell me what has changed in VoIP processing in the new Wireshark so I can overcome my problem with 1-way-voice.

I'm afraid the issues of VoIP analyis which still exist in Qt (new) Wireshark are not related to the reason why Yevgeniy could not hear the other party in the field, so identifying what has changed in Wireshark would not help you identify the real life issue.

The VoIP analysis is still Work in Progress in Qt Wireshark, and in 2.0.3 (and even in 2.1.0-2945-g66bea39 snapshot), e.g. the SSRC is wrongly displayed if you go Telephony -> RTP -> RTP Streams -> Analyze - the SSRC for "reversed" direction is shown the same as the (correct) one for "forward" direction, the "setup packet" number for one of the streams is a huge number not matching any frame in the capture, ...

The RTP stream from Yevgeniy (109.201... -> 188.92...) doesn't have the Mark bit set in the first packet which might cause issues with some over-sensitive RTP stacks, but if this was the reason of your trouble, it would be the other party who would not hear Yevgeniy, not vice versa. So this is also not the explanation.

Nor have I found anything wrong about the SDP contents. So further analysis steps should answer the following:

  • whether the issue exists only for PCMU streams and/or only for streams coming from 188.92.... to 109.201...,

  • whether 109.201... is a gateway to TDM or audio itself or it forwards the RTP further,

  • whether no "leftover" RTP stream from previous call, possibly from a different source IP, was coming to 109.201....'s UDP port during this call (I don't know what capture filters you have used).

(25 May '16, 13:15) sindy

Am I missing a sendrecv SDP attribute from

(26 May '16, 01:05) Jaap ♦


If the offerer wishes to both send and receive media with its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default.

rfc3264 (c)

(26 May '16, 01:12) ky4k0b

@Jaap, @ky4k0b was faster to react. Even if this would be a reason for Wireshark to (incorrectly) treat one of the streams in a special way, it still wouldn't explain why in real life the 109.201... doesn't play the received RTP, as its own SDP does contain the sendrecv attribute.

@ku4k0b, will you file the bugs noticed? If not, may I use your pcap as the mandatory attachment?

(26 May '16, 01:21) sindy

@sindy ye, sure, use it if you need.

ps: switched to G.729 codec and still no change. Keep investigating

(26 May '16, 01:28) ky4k0b

@ky4k0b oke, so it's optional to have this attribute. It's been too long I've worked in detail with that.

(26 May '16, 04:52) Jaap ♦
showing 5 of 6 show 1 more comments

It tool me couple days to find these lines I've added 2 years ago in iptables:


-A INPUT -s -j REJECT --reject-with icmp-net-unreachable

permanent link

answered 26 May '16, 03:34

ky4k0b's gravatar image

accept rate: 0%

edited 26 May '16, 03:35

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 25 May '16, 09:02

question was seen: 4,228 times

last updated: 26 May '16, 04:52

p​o​w​e​r​e​d by O​S​Q​A