I have a basic SIP call via G711u codec. (here's CAP) Somehow my switch doesn't see the incoming RTP flow from 188.92.162.85 to 109.201.138.144. Moreover Wireshark 2.0.3 doesn't associate it either (yes, you can play the missing stream)
On the other hand when I use Wireshark 1.12.11 the media magically appears in SIP flow:
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 edited 25 May '16, 09:16  grahamb ♦ showing 5 of 6 show 1 more comments |
One Answer:
It tool me couple days to find these lines I've added 2 years ago in iptables: #voip-spammers -A INPUT -s 188.92.162.85 -j REJECT --reject-with icmp-net-unreachable answered 26 May '16, 03:34 ky4k0b edited 26 May '16, 03:35 |
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).
Am I missing a sendrecv SDP attribute from 188.92.162.85?
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)
@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?
@sindy ye, sure, use it if you need.
ps: switched to G.729 codec and still no change. Keep investigating
@ky4k0b oke, so it's optional to have this attribute. It's been too long I've worked in detail with that.