Wireshark or alternative

[x-man]

Hi Guys a bit of help please. I am being asked to do a wireshark trace to find the answer to a SIP trunk problem. Basic is that transferred calls cut off after 10.04 minutes on a very regular basis. I think its the RTP failing but can't find out why. My second line support is just as flumoxed. SP is asking for the wireshark trace because it contains media (RTP) packets.

So the question is believe it or not never needed to do this before how would I set this up on a CX? I don't really get involved in the IT on this site but I suspect that the IT guys are going to want hand holding. I would like to know how to port mirror  a CX (I assume this would have to be done on the switch its connected to?) and what to do if its a dumb switch?

Also I don't have wireshark is there something else that would do the job assuming that I am correct that the Mitel doesn't do any trace that contains RTP?

Hope someone can help.

TIA

[Dogbreath]

MCD won't see the RTP because the handsets send the media streams to/from the SIP gateway [except if you're using the embedded call recording or the caller is leaving a voicemail]. If you really need to see the media stream then you need to port mirror or do your cap upstream of MCD.
For real-time SIP debugging [ie with a port mirror] I like sngrep [but it doesn't do media either].
Calls cutting off after the same length is almost certainly a firewall timeout issue.

You can do a SIP capture on MCD and FTP it off to open with wireshark:
http://mitelforums.com/forum/index.php?topic=2861.0

[iboyd]

No one has built a better mousetrap than Wireshark yet. 

I would ask your IT team to have a Wireshark Sniffer set to get data from the handset AND the SIP gateway.  Easiest way is a build a computer with 2 NICS and install Wireshark on it. Then plug the NIC's into different ports on a switch, then span the ports for the Gateway and the handset to the sniffer's ports and run Wireshark from there. The other helpful tip is to have the Phone and the Gateway on the same switch.

PCAP analysis is best done after you captured all the raw data.  Don't try to do it in real time.  So set your environment up, get your relevant IP's, and maybe run a few test Captures to see what your baseline traffic looks like.  Then get your problem child to make a call and run the PCAP at the same time.

-Ian

[x-man]

Thanks both. I have a pcap of the SIP signalling and that appears OK according to service provider.

Yes, having woken up a bit I realised the faux pas about mirroring the CX when I knew that RTP was between phone and endpoint.

Timeouts have all been adjusted to values way above 10 minutes on the firewall. And on the CX as well.

SP is suggesting that seeing the rtp stream on a trace will reveal all...I am not so sure but I must do it. IT will just have to play ball. I don't think the switches are managed so that will be the first hurdle.


any and all further comments are welcome.

[acejavelin]

If you use an MBG the tool is built into it, it's in the MiVoice Border Gateway blade under Administration - Diagnostics, and select Packet Trace. This is one of the best things about the MBG, besides the seamless integration to the phone system.

[x-man]

Unfortunately no MBG.

[acejavelin]

Then the only other way I know is get yourself a small managed switch and setup a monitor or mirror port. I used to carry one that has port 8 setup to mirror port 1 and if I need to do captures I disconnect the LAN cable from the router and connect it to port 2 of the my switch and connect a patch cable from port 1 to the router, inserting the switch as the last thing before traffic touches the router, and capture data with my laptop connected to port 8. It will capture all data to/from the router on port 1 so you can capture everything.

If the router connects to a managed switch, the customer's IT staff maybe able to setup a monitor/mirror port for you to capture from.

[x-man]

Thanks, yes I am waiting to hear from them as to whether the switch can mirror. My other question really is how to set up wireshark because I have never (believe it or not) had any need to use it up to this point.  I assume you install it and somehow set it to grab any and all data on the mirrored port as you say. I don't want it to do real time but just save it to a file so I can send it to the CP.  I suspect that a laptop is best to capture rather than a server on the same network that may be a few hops away? In this case i asume agin that I will connect the phone to one port and tell the laptop to collect data from the other....?

[VinceWhirlwind]

Yes, use a laptop, because setting a port as a mirror port (destination for mirrored traffic) stops it from operating as a normal ethernet port.
 
And set the ports where you want to grab the traffic as mirror ports (source)

[Dogbreath]

https://ask.wireshark.org/questions/3291/how-do-i-set-the-capture-to-auto-save-periodically

Do a capture and have it roll over every n minutes so that if you get a report of a call dropping you know which n-minute window capture file to send/look at.

[x-man]

Cheers both I'm feeling > < more confident. Problem is this fault is getting more complicated by the day since we are now being told that the way the router (sonicwall) is set up is wrong and it needs SIP-Alg ON not off as we normally would...telecoms is getting too complicated for an old boy like me....

[Dogbreath]

SIP ALG on Sonicwall ["SIP Transformations"] works fine in simple deployments [where all handsets placing calls though a given MCD reach the internet through the same Sonicwall], in my experience, and I have been using it successfully for years.

When turning ALG off/on, I suggest you flush all port 5060 connections from Connection Monitor to be absolutely certain what state it is in.

[x-man]

Cheers, makes me feel a little more confident.

[x-man]

Ok, we have finally bottomed the problem after a lot of investigation. The problem is that when the Mitel transfers the SIP trunk call internally it the treats the call as INTERNAL. This means that the call duration set for INTERNAL calls is used rather than the expected external timer. For some reason the internal timer was on and set to 10 minutes. So after a call was transferred this timer was forcibly releasing the call as the timer was set (the second timer was set to 0 so it cut off immediately instead of giving the expected warning tone).

We have a query with Mitel why an external SIP call is treated as internal after being transferred and I will post here if we get an answer.

[Dogbreath]

I don't get it - does that mean internal calls cut off after 10 minutes  then?