In this article, I will show how to use PCAP to solve one particular problem that occurs between the system owner and provider.
One of our clients had a problem with his provider because calls sent to this provider were dropped. The provider claimed that there were no CDRs coming from our client to the provider‘s system, ergo there was no traffic sent – “we see no hits from you in CDR.“
A simple look at one of calls from the captured SIP packets shows us this:
It is clearly visible that INVITE is sent to the provider and the provider replies with a “503 Service Unavailable“ message.
The SIP response in the question looks like this:
SIP/2.0 503 Service Unavailable From: <sip:4414540xxxxx@188.40.xxx.xxx>;tag=gZ27c2F5vS13N To: <sip:33344792254xxxx@185.32.xxx.xxx:5060>;tag=1bf5c16c-6efd824e-2752e7-7fa356e66578-100007f-13c4-7217 Call-ID: a674bff6-ed0e-11ea-96d4-79d91148-975 CSeq: 24969096 INVITE Via: SIP/2.0/UDP 136.243.xxx.xxx;branch=z9hG4bK266.988ea0344416a2c58415cb3549a2b822.0 Via: SIP/2.0/UDP 188.40.xxx.xxx;received=188.40.xxx.xxx;rport=5060;branch=z9hG4bKQcyZB6veZ9KZH Retry-After: 5 Content-Length: 0
This clearly shows the message was received from the provider‘s system.
By providing this PCAP as evidence to the provider, it is possible to move past the phase: “there is no CDR, that means your traffic hasn‘t reached our system, that means this is not our fault.“
The cause of this problem can be different in each case, but very often the system rejects the calls before registering the CDRs for one or more of the reasons outlined below:
- The SIP message was malformed and it was rejected
- A call loop or relay attempt was detected and rejected
- Internal traffic limiting on the SBC before reaching the CDR log part of the configuration
- The anti-flood mechanism was activated; thus, the call attempt dropped instantly with a 503 response code
There could be other reasons, but the exact reason should be explained by the provider.
Knowing what is wrong allows us to fix the problem and renew the traffic.
Do not be surprised if a provider silently fixes the flawed configuration on his system, tells you to try again, and traffic starts to flow without any problems. When you ask what the problem was, very often you will not get an honest answer — „I don‘t know, maybe it was temporary. Nobody changed anything etc.“
And that‘s okay. The main take away point from this is that by providing hard evidence with PCAP, you can speed up the problem resolution. It is not important whose fault it was – the most important thing is to keep good relations with your provider, move forward, and keep traffic flowing.