488 Not Acceptable Here

[gtinet]

We have an intermittent problem with our in house 3CX server where all outgoing calls fail with the following message:

Call or Registration to xxxxxxx@(Ln.10003@639-0509) has failed. xx.xx.xx.xx replied: 488 Not Acceptable Here; from IP:xx.xx.xx.xx:5060
SIP Server ID: 12294 12/09/2020 10:54:55 AM

I keep blaming it on the trunk vendor, but I have checked with them when this is happening and they are not even seeing the call trying to get to their SBC or VOIP switch. The only way to get the server working again is to delete the trunk and recreate it.

I'm looking for any suggestions on how to figure out what the problem is.

Thanks,
Kevin

 

[AWS2P]

isn't it a problem related the ID you send to your provider when trying to call out?

 

[gtinet]

isn't it a problem related the ID you send to your provider when trying to call out?

Possibly, but why would the 3CX start sending out the wrong ID after its been working for several days or weeks. And if that's the case, why wouldn't the trunk vendor see that attempt coming in?

 

[AWS2P]

If it was working well previously and no one did a setting change in trunk or extensions it"s strange
488 sip error can be an audio codec cause if you change to one not supported on provider side.

 

[gtinet]

I pushed back on the SBC/trunk provider again and they admitted they are blocking our calls but don't know why. Thank you for giving it some thought.

 

[Kevin@voxtelesys]

Is your trunk a supported carrier? Does doing a trunk refresh fix the issues or do you have to completely rebuild?

 

[gtinet]

Is your trunk a supported carrier? Does doing a trunk refresh fix the issues or do you have to completely rebuild?

Generic carrier. It goes to a local telco with a Ribbon/Genband/Nortel C15 and SBC. Refreshing the trunk does not bring it back. Just rebuilding it.

 

[gtinet]

Trunk provider says the 3cx server changed from UDP to TCP and the SBC was set to accept UDP only on that trunk group. They changed the trunk group to accept both.

Is that a 3cx setting I can check somewhere? What controls whether the server uses UDP or TCP.

Thanks

 

[sdg]

Trunk provider says the 3cx server changed from UDP to TCP and the SBC was set to accept UDP only on that trunk group. They changed the trunk group to accept both.

Is that a 3cx setting I can check somewhere? What controls whether the server uses UDP or TCP.

Thanks

Under the SIP Trunk -> Options tab, under Advanced you can select the transport protocol

 

[gtinet]

Under the SIP Trunk -> Options tab, under Advanced you can select the transport protocol

Thank you for pointing that out. I see that it's currently set for "Any". I guess that allows the server to decide what's best? Is there a preferred setting for this item?

 

[cobaltit]

Yes there is. It's whatever your provider prefers.

 

[gtinet]

Yes there is. It's whatever your provider prefers.

Obviously. Provider said UDP or TCP is fine. I didn't know if there was a preference from the perspective of the 3CX server.

 

[cobaltit]

Nope. 3CX is the least picky of the 3 pieces involved: PBX, firewall, provider

 

[JohnS_3CX]

The server will decide what is best, if the provider tells it what is best using their registrar DNS records.

Otherwise (since this is a generic provider and not officially supported) they should give you their specific requirements, and you can set/lock them in your trunk settings to ensure compatibility.

 

[YiannisH_3CX]

To add to this, if the provider does not indicate a preference through their DNS records and your trunk is set to ANY under the transport protocol the 3CX will first default to UDP. If the communication via UDP fails then it will try TCP which is probably why you are seeing the switch to TCP. If you know what the provider prefers it is often best to force a protocol to avoid the 3CX server from switching.

 

[gtinet]

Thank you all for your responses, and thank you YiannisH_3CX for your clarification. I will definitely ask the provider to specify which protocol they want. In the meantime, I have it set to TCP and everything is running good.