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

Sip trace, can not see B leg

0

HI,

strange thing is happaning on my server when I try to trace sip/rtp taffic:)

I am having sip proxy which relays call throught RTP server for media. When I am doing trace on sip proxy I can see bouth legs, when I am doing wireshark trace on RTP proxy I can see only one leg (A). Interesting is that I can see bouth legs on sip proxy (invite from rtp) but on RTP I can not see this invite that was sent to rtp proxy (B leg).

When I use tcpdump I can see whole trace (A and B leg).

p.s.: with the same config on test invirovment I can see bouth legs. I am doing trace with "-i any" so interface should not be an issue.

what could be on issue?

tnx! miha

asked 02 Mar '14, 23:58

miha-'s gravatar image

miha-
1111
accept rate: 0%


2 Answers:

0

When I use tcpdump I can see whole trace (A and B leg).

that sounds like the solution for you. If tcpdump works, do the capture part with tcpdump and the analysis part with Wireshark.

If that is not an option, please add more details about your environment. At least, but not limited to:

  • OS and OS version
  • Wireshark version
  • tcpdump / lipcap version
  • interfaces you are capturing on (ethernet, wlan, etc.)
  • what exactly is A- and B-leg?

Regards
Kurt

answered 03 Mar '14, 14:24

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 03 Mar '14, 14:58

HI,

wireshark version: 1.8.10-4.el6 os: centos 6.4 tcpdump: 14:4.0.0-3.20090921gitdf3cb4.2.el6 libcap: 2.16-5.5.el6 capturing on: -i any (basicly is this eth0)

A and B leg:)

UAC (a) -> sip_proxy-> (a leg) media_server() (b leg)->sip_proxy->UAC(b)

Incoming invite is a leg and outgoing is B leg.

I am using media_server/media_gw for RTP handling and PBX futures. I can see leg from UAC (a) but can not see leg to UAC (b) spiking of RTP. Also request INVITE I can see only from sip_proxy but can not see invite to sip_proxy (if you are positioned on meida_server). Interesting is that I can see invite if I trace on sip_proxy :)

You be any issue with vmware as media_server is running on vmware?

p.s.: now using tcpdump

tnx!

miha

(03 Mar '14, 23:24) miha-

From your diagram, the SIP proxy forwards the INVITE to the media server, and the server initiates a new invite toward the SIP proxy, correct? So, the media server is actually a back-to-back user agent (B2BUA) from a SIP standpoint? Can you upload the packet capture you DO have and post the link (http://cloudshark.org/)? That might clear up a couple topology questions I still have.

If you do a "tshark -D" command, do you see the physical interface listed that serves the second leg? If you do a simple "tshark -i {that interface}" trace, do you see anything at all? Are you 100% sure about the interface that traffic is going out on?

Also, in troubleshooting SIP call legs you've got to be mindful of your terminology. "UAC" refers to a role of client in a given transaction, so you can never have a "UAC A" sending an invite to a "UAC B", even if there are two legs, it's UAC -> UAS, UAC -> UAS. An end user UA is still the "server" for the invite transaction.

From your diagram...... is this an IMS call flow (ignore this question if you don't know what that is)?

(04 Mar '14, 14:49) Quadratic

0

Ok, there's a terminology crisis here that makes this question confusing. What is an "RTP Proxy"? I assume you mean like a media gateway? To be clear, am I correct in saying that the SIP legs are visible but one RTP leg is not? Is the service actually working and you can't trace it, or is it just a visibility problem? If it's not working, what is the signaling mechanism between the SIP proxy and the media gateway (or is there one)? Typically the control toward an RTP gateway would be something like H.248/Megaco (so if it's not working, and the SIP/SDP info looks correct, I'd start there before tracing the media).

You also mention "the RTP" sending a SIP invite... Does that mean this is not a media gateway or 'RTP Proxy', but rather just another SIP UA, thus you have one media leg established between the two UAs who are using a SIP proxy to establish the media path between them (so two SIP legs, and one RTP leg)? I assume this isn't the case because you mention two media legs, but then why is the media gateway initiating SIP invites to a SIP proxy (confusion)?

A network diagram or illustration would be most welcome here. :)

If the service is working but you just aren't able to see one of the media legs, it's hard to say what the problem is except that it's with your trace. Confirm the media IP info and ensure you're not setting any filter to remove it from your capture. In concept, a '-i any' with no filter, on the media gateway itself with a working voice call should be able to catch both legs so if it can't I'd probably start by making sure the specific interface that captures the B leg is in your interface list for the 'any'.

answered 03 Mar '14, 21:40

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

edited 03 Mar '14, 21:50

alt text

HI,

bellow you can find a network diagram. Regarding of "working" everything works fine as RTP goes right and also signaling is ok.

And if I open pcap than with wireshark after tracing with tcpdump I can see all invites and also RTP stream in bouth direction, otherwise if I trace with wireshark I cann see signaling you from sip proxy and also RTP you from UAC A to media server.

I am capturing with "-i any" on all interfaces.

If I use tcpdump on media server I can see boutgh legs (from sip proxy and to sip proxy), with wireshark/tshark I can see only leg from sip proxy. If I trace on sip proxy I can see bouth legs.

(05 Mar '14, 00:05) miha-

Thanks Miha.

If you do a "tshark -D" do you get the interface that is sending message 3 in that diagram in the list? Are you positive of this? When you do a "tshark -i any", do you use any filters at all? If tcpdump catches it and tshark doesn't, the only things I can think of would be it not having the interface or filters.

This last comment isn't related to your question, but your SIP terminology is wrong here. "UAC B" is actually a UAS in this transaction because it receives the invite. Further, it looks like the media server is a B2BUA (back-to-back user agent),so it is the UAS to UAC A, and it is the UAC to the final UAS.

(05 Mar '14, 15:42) Quadratic

Hi Quadratic,

I did not use any filters but also tried with "-R sip" and no luck. I am using "-i any" so this should not cause any problems. The same way I am tracing on proxy and I am reciving this invite with tshark:)

Should vmware cause any problems with this (drivers, etc)?

I can tell you that I have same configuration on test environment, just media_server is not running on vmware and it is running on deticated machine/server and I can trace "bouth invite's". Could this be causing problem with some vmware drivers?

Regadring SIP terminology you are right;)

tnx! miha

(06 Mar '14, 00:36) miha-

@miha-

Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information.

(06 Mar '14, 01:36) grahamb ♦

Miha, if you do a "tshark -D", do you see the interface that should have the missing leg? If you trace that interface specifically rather than 'any', do you see anything at all?

For your vmware question, it shouldn't matter as a virtual NIC should be traceable. If you're running a virtual network with a VMWare VDS, for example, you could actually do the packet capture out of the VDS as well.

(06 Mar '14, 15:47) Quadratic