Hi, We are troubleshooting an issue where we are able to see SIP packets in wireshark but the gateway didn't received.
Environment: [sip dialer]-------(lan router)------------[cisco gateway] Is the lan router which blocks the SIP packets?? If so is there a way to detect that packets being blocked? Thanks and Regards asked 05 Jul '15, 23:18  mws |
2 Answers:
UDP is a unreliable transport protocol, tracing on the SIP dialer won't show transport problems elsewhere in the network. The SIP UA should retry and eventually fail the transaction if the situation persists. That's what you could see when tracing at the dialer. answered 06 Jul '15, 03:07  Jaap ♦ |
The x-cisco-cpa is not a header, it's a MIME body type; and as you pointed out when it's enabled it makes the INVITE continue a multi-part body: one for SDP, one for x-cisco-cpa. So perhaps either:
answered 06 Jul '15, 12:35  Hadriel Yes its one of the MIME body type. 1. Just for clarity, if the fragmented IP/UDP pass through a NAT or Firewall, then all packets should be blocked, correct!! In our case, for the first SIP call it allows and SIP INVITE reached to gateway and sip call got succeeded. The next packet was blocked.And after a period of time it allows. As mentioned if the dialer application restarts then for most of the cases the first SIP INVITE succeeds. 2. The gateway is configured for the below cases, and it allows SIP calls with and without x-cisco-cpa body part. Meaning for the regular SIP INVITE the application/sdp is alone present and gateway accepts it. For the CPA calls the SIP INVITE contains both sdp's. There is no case where the SIP Header: Multipart-MIME/x-cisco-cpa present and not having x-cisco-cpa header. And at the time of non working calls, the UDP debug trace in the gateway shows no packets arrived from the dialer. (06 Jul '15, 20:00) mws |
Thanks Jaap, yes and as you said SIP ua retries and fails after 7 attempts. Few points to for understanding. 1.The sip dialer uses x-cisco-cpa sip headers & sends it to cisco gateway. 2.The first SIP call got succeeded. 3.The second SIP call retires and fails after 7 attempts. 4.The UDP trace in cisco gateway shows nothing from this sip dialer ip address for the problematic call.
5.From the sip dialer logs the sip call being sent and in wireshark log, we are able to see the SIP calls going outside. but those packets were lost/blocked somewhere before reaching the gateway.
Interesting case: If the sip dialer removes the x-cisco-cpa header (pl refer point-1), then all the calls are succeeded.
For Success calls: The sip call contains Message body-application/sdp. For the packets blocked/lost calls: The sip call contains Messagebody (multipart/mime)-application/sdp & application/x-cisco-cpa.
With the help of wireshark we are confirming the packet are sent to wire.
Is there a possibility the packets be blocked somewhere in the LAN router?
And the blocking happens randomly like one call it allows and the next call being blocked/lost. If we restart sip dialer application, the first call is succeeding for the most of the times. This behavior shows the team that there is something to be looked in the sip dialer system.
Sorry to dump everything here, trying to explain the scenario what we are facing...because we relayed on wire-shark output.And we don't have doubt on wire-shark.
Finally we asked the LAN router team to check for any blocking calls. Is there anyother way we can troubleshoot this on sip dialer system. Thanks
Are you able to perform a capture at the SIP gateway? Or at least after the router? This could help to confirm where the drop is occurring and allow you to troubleshoot the correct network element.
Since we are taking remote control of gateway using putty.exe console and unable to run wireshark or for port mirroring. The capture after the router was not performed. We have another system where its able to make calls successfully and all SIP INVITE reached to gateway. The only difference we see is the non working system is in separate vlan i.e x.x.A.x and the working system is in separate vlan i.e. x.x.B.x