Roaming calls and RTP path minimization. The issue is that roaming calls are separated into different parts in Wireshark looking like multiple calls instead of a single call. Here is my comment to a person more knowledgable than myself, with their follow up answer. My question is "why can't Wireshark understand that this is one phone call (roaming mobile call) and display it as a single call?". My original Question related to a single call flow. "The attached call flow ladder diagram (time sequence identical to original pcap). Note the relative intermixed left column 1s and 0s. If this were truly one call in a roaming scenario, or some other sequential exchange during the same call, wouldn’t it be more evenly divided (mostly 0s at the top and mostly 1s at the bottom)? This was really apparent in Wireshark because it color codes the two separate calls when you select both before generating the flow diagram. This looks more like two separate calls just intermixed in time as they both arrive essentially in parallel." Answer: "This is exactly what a roaming scenario looks like. A calls B (A’s MSC sends B’s home MSC an INVITE). MSC B determines that mobile B is roaming in MSC C. (this is done with IS-41 signaling, MSC C sends MSC B a TLDN). MSC B sends an INVITE to MSC C using the TLDN so that MSC C knows the call is for mobile B. MSC C alerts mobile B. When mobile B answers, the 200 OK INVITE goes from MSC C to MSC B then from MSC B to MSC A. At that time path minimization happens. MSC B sends and empty re-invite to MSC C. When MSC C responds with its SDP, MSC B sends a re-INVITE to MSC A containing C’s SDP. When MSC A responds with SDP, MSC B sends A’s SDP to C. This allows MSC A and MSC C to exchange RTP directly. This also can happen with Call Forwarding Immediate. For Call Forwarding No Answer (to voice mail for example), you will see A to B set up then, later B to C set up. When answer occurs, path minimization will also occur, but CFNA will look a bit different since the two legs were set up in series instead of parallel. If these were independent calls, you would not see the same SDP RTP IP/port passed from one dialog to the another. That is a sign of path minimization." asked 13 Dec '12, 05:32  TomEverett |
One Answer:
The question is "Why should it?". This tool is just for that purpose, showing you the raw and dirty details of the sessions making up the "call". You'll want to see all the transactions between the nodes involved, especially when something is not working as expected. answered 13 Dec '12, 07:56  Jaap ♦ |
I am completely baffled by your comment. No detail is lost if all you want to do is know the association between calls. Currently if two calls are part of the same roaming call which make up the complete call flow then "complete" is ambiguous and misleading. Having some idea of calls associated with the same logical phone conversation is beneficial.
Also for the process of extracting and replaying call scenarios, not knowing which parts of the call are related makes it more difficult to identify what needs to be extracted. In my world, live captures result in giga byte files with MANY intermixed calls that are difficult enough to analyze. All I am asking is if there is some way to simplify analysis of these types of call flows.
Digg into the code and maske it better?
@TomEverett: It's very simple to ask, but if you've ever dealt with multivendor UC/US combinations, the multitude of RFC's (try figuring out the many ways to do call transfer) involved with SIP, the (sometimes) errant operations of B2B UAs, etc, you'll know this is a (very) tall order. Then multiply that by all the other call control protocols supported by Wireshark and the task becomes immense.
This then can be seen as outside the scope of what Wireshark is intended for. What you seek is a SIP Session Analyzer, but the few I found even don't do what you want.
"multivendor UC/US combinations, the multitude of RFC's, the (sometimes) errant operations of B2B UAs, etc"
I live in this world that is why I posted the question. If you feel my comment or request is outside the scope of Wireshark just say so. Just don't assume that I don't know what I am talking about.
I have looked at and used many SIP analyzers, some even very expensive, and all have their own strengths and weaknesses. As you very accurately pointed out "the few I found even don't do what you want" this is a problem that needs a solution. The very definition of engineering. Wireshark is a very useful tool. It could be better, or it could spin off into other more focused tools for things like SIP. Either way this added functionality would be a good thing.
This will be my last post on this issue.