Solved SIP Errors

[Shadragon]

3CX is sending me "Trunk/Provider responds to Request with an error" emails with almost every outbound call now. The calls go through, but I get one of two error message shown below (edited for privacy.) The frequency is about twenty emails an hour during business hours.

Call or Registration to +xxxxxxxxxxx@(Ln.10000@Provider SIP) has failed.
172.xx.xxx.xx replied: 500 Server Internal Error; from IP:172.xx.xxx.xx:5060

Call or Registration to +xxxxxxxxxxx@(Ln.10000@Provider SIP) has failed.
172.xx.xxx.xx replied: 480 Temporarily Unavailable; from IP:172.xx.xxx.xx:5060

The 172.xx.xxx.xx IP is our SIP Provider.

I'm convinced either the SIP trunk or my PBX have a wonky setting, but the SIP provider refuses to help me fault find the connection saying, essentially, the calls are going through so it's working.

Any idea what's going on? Is there a SIP utility to fault find SIP connectivity issues out there so I can interrogate the trunk and see what's wrong? Thanks.

 

[cobaltit]

Wireshark

 

[YiannisH_3CX]

Hello @Shadragon

You can use wireshark as @cobaltit suggested to see how the provider responds to outgoing Invites from the PBX. If the error messages come from the provider then this is something the provider needs to help you with.

 

[Shadragon]

Wireshark shows no irregularities. I was able to capture data when one of the errors came through. I'm sure it's the SIP server at my provider, but how do I prove that.

 

[YiannisH_3CX]

If you successfully managed to capture a call with an error then this should be visible in Wireshark. With the correct data you can contact your provider and ask them to look at the issue.

 

[eddv123]

This is highly likely to be a trunk provider issue as the @YiannisH_3CX has identified.

5xx = is a server error response. For some reason the server cannot fulfil the request. For example 500 Server internal error, 502 Bad gateway.


In your case 500 Server Internal Error generically denotes a temporary server error of some sort, so they maybe having an issue or outage down their end - please confirm.

 

[Shadragon]

There were no errors in the wireshark capture, that's the issue. From what I can see, from us to their end of the SIP trunk is working. It's the providers SIP service that's having the issues.

It appears as if our calls are being refused on their SIP service and returning the calls with 480 codes intermittently. They appear to be unwilling to fault find this on their end, so how can I show it is them?

 

[leejor]

Is the issue limited to certain numbers? Perhaps a certain end destination provider? Did this just begin?
It may be that your provider is having "technical difficulties", with either their own equipment, or with the transport provider(s) that they use. They may be aware of this, but aren't willing to admit that it's their problem.

 

[cobaltit]

@Shadragon

So it very well may be a configuration issue on the 3CX side but the provider should be willing to work with you to troubleshoot. At the very least they should be able to tell you what they are seeing and what changes you should make. Otherwise I suggest changing providers if possible. If not, ask them to escalate the issue. Most providers 1st level support aren't equipped to deal with in-depth SIP issues. If you do end up looking for a new provider I may know one

 

[cobaltit]

@UnDutchable30

You really should create your own post so as not to mix up responses to someone else's issue. You need to talk to WeePee because they are rejecting your calls.

 

[UnDutchable30]

@cobaltit : the thread is about SIP errors, so don't understand your response at all!

 

[leejor]

@cobaltit : the thread is about SIP errors, so don't understand your response at all!

True, but, it began with regards to someone else's SIP errors, whose cause may have no relation to yours. It's is always best to begin your own thread, rather than jumping in on someone else's unless you have a solution for their problem.

 

[YiannisH_3CX]

It appears as if our calls are being refused on their SIP service and returning the calls with 480 codes intermittently. They appear to be unwilling to fault find this on their end, so how can I show it is them?

Since you are seeing this in Wireshark then you should be able to ask them why they are responding to calls with this error. As mentioned this could be a configuration error but they need to tell you what you need to change. If not then i would recommend going with a supported provider if possible.

 

[Shadragon]

OK, I was doing a series of test calls. Just dialing my cell phone from 3CX over and over. I saw this in the call logs. (Fake numbers, for example only)

11/19/2018 5:28:44 PM User Name (555) +15553372174 00:00:08
11/19/2018 5:28:24 PM User Name (555) 3372174 Not Answered
11/19/2018 5:28:19 PM User Name (555) +15553372174 00:00:01

The +1555 plus 7 digit number is needed by my provider, but the second call did not apply the outbound rule.

My outbound rule is set like this:

7 digit numbers > Provider SIP > Prepend +1555

I dial 3372174 in 3CX, so why does the outbound rule not consistently pick up the seven digit number and apply the Prepend?

 

[cobaltit]

Very good question. But since you only posted those lines and not the preceding ones where it shows the decision making process of 3CX and because you've edited the numbers noone can really tell. You'll want to enable verbose logging and try the test again.

 

[leejor]

The 3CX Activity Log will show which rule (name of) was used for the call without the prefix. Rules are matched from the top down, so there must be another rule above, that is being used.

 

[YiannisH_3CX]

Is there only one outbound rule present or do you have multiples? If you have more that one try to move the outbound rule you need to the top of the list. Also make sure that the call did not fail before reaching the Outbound rules.

 

[Shadragon]

Everything before that rule is for three digits, 911, 411, etc. It's the only 7 digit rule in place.

Baffling.

Verbose logging is the next step, I think. Will need to reboot after hours for that.

 

[leejor]

It shouldn't even require Verbose. If you can reproduce, the Activity Log will show which rule is used. Is it the same one? Are calls working, and not, all coming from the same set?

 

[Shadragon]

Here's an example from a few minutes ago.

"2891178" shows up in the call log (Should be +15552891178). Here are the related event log entries for that call.

11/20/2018 2:57:27 PM - Call to T:Line:10000>>+15552891178@[Dev:sip:[email protected]:5060] from L:3242.1[Extn:847] failed, cause: Cause: 480 Temporarily Unavailable/INVITE from 10.1.100.72:5060

11/20/2018 2:57:27 PM - [CM503003]: Call(C:3242): Call to <sip:[email protected]:5060> has failed; Cause: 480 Temporarily Unavailable/INVITE from 10.1.100.72:5060

Where is the rule that was used indicated? Thanks.