When provider does not see your calls in their CDR

1 min read

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.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *