Solved Server sending BYE to different endpoint

[Tim Mrazek]

• 3CX Version, Enterprise Annual 16.0.3.676
• Server OS, Debian 9
• Is the 3CX Server Hosted and where? Local hosted
• IP Phone Make/Model/Firmware 3CX App
• Provisioning Method: Local / VPN / STUN / SBC Local
• Trunk Provider or Gateway Make/Model Twilio
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

We have been seeing random errors in our providors portal saying that the call was dropped due to no audio received. I looked into it today and the one call I was troubleshooting shows the server sending it's BYE messages to one of the other signaling endpoints at our provider. Should this be happening? I dont see anyting in the SIP messages telling the server to do this. See attached. There are three public IP's on the screenshot of the call flows. the 54.172.60.0 and 54.172.60.1 are the signalling endpoints and 34.203.251.154 is the media endpoint.

 

[Tim Mrazek]

Also, in our trunk settings. we are using an FQDN for the providor and not an individual public IP address.

 

[eddv123]

Twilio load balances using multiple servers - if you run an nslookup to the FQDN whatever.pstn.twilio.com you will see a list of four different servers.

As a provider they normally (like most) use one server for SIP traffic and another for RTP/media.

I ran a test call from my PBX here and got SIP to 54.172.60.x and RTP 34.203.251.94.

What I can see from the trace you have sent however is the BYE message being sent from the endpoint >> 3CX which attempts to sent the BYE multiple times to the provider.

It is eventually returned as is the 200 OK but the messages "look" to be out of sync - your sequence should definitely end with a BYE and 200 OK from 3CX >> Twilio.

The beauty of Twilio as a provider however is that you can trace their platform as well - go to the call logs section of the SIP trunk and download the call example PCAP.

 

[eddv123]

If I had my best guess I would say the issue was related to DNS/IP or resolution.

Check on your server >> SIP trunks whether you have the new "Auto Discovery" setting turned on or off and whether you are using FQDN or have configured IP addresses.

 

[Tim Mrazek]

Yeah, I knew about the multiple IP listting per fqdn for twilio, I have them all whitlisted in my firewall. Both Signalling and media IP ranges as they specified in their documentation. so from my screenshot the flows show the phone hanging up and the 3cx trying to send a BYE to the other Signalling endpoint instead of the one it used originally. And then twilio ends the call after it's timeout period, which I forgot to include the timestamps in the picture, and send a bye from the original signalling endpoint. and 3cx replies with a '481 call dosn't exist'. It seems like 3cx thought the call had already ended or was on a different session. Or something, not sure.

Check on your server >> SIP trunks whether you have the new "Auto Discovery" setting turned on or off and whether you are using FQDN or have configured IP addresses.

Where is this setting? I cant seem to find it on my sip trunks page on any of the tabs.

Thanks

 

[eddv123]

I think it's possible the 481 is sent as the entities involved (due to incorrect sequencing) think the dialogue for this call has already ended.

The auto discover setting was added in v16 SP3 if I recall and can be found on the SIP trunking page -are you using the Twilio template or a generic one?

 

[Tim Mrazek]

Ah, I found the auto discovery checkbox on the right side of the screen after the FQDN box. I'll try setting that.
I am not using a Twilio template. Just used the guide in the docs for this providor. I dont see a template for Twilio available. Is it located somewhere else besides the settings>templates?

 

[SweetAction]

Ah, I found the auto discovery checkbox on the right side of the screen after the FQDN box. I'll try setting that.
I am not using a Twilio template. Just used the guide in the docs for this providor. I dont see a template for Twilio available. Is it located somewhere else besides the settings>templates?

When you add a SIP trunk, you select Twilio from the list. They might be under Worldwide. The form asks for needed info and then puts all the settings in.

 

[eddv123]

Yes it's under worldwide as suggested above, I would second this action since the template is specially tweaked for the provider settings.

 

[StefanW]

Kindly update to U4 and I have a strong feeling your flow will be fixed.

 

[Tim Mrazek]

Ah, the template is when you add a new SIP trunk. Yes I did that when creating it. We have three trunks setup with them. One for TF, one for LD, and another that we split TF calls with another location.

Kindly update to U4 and I have a strong feeling your flow will be fixed.

ok. This will be my first update. Do I need to update all the 3CX apps in order for them to work with 16.4? Or can I update selectively?

 

[eddv123]

This will take you through the SIP trunking provider setup:
https://www.3cx.com/docs/manual/sip-trunks/

The confusing part for those who are not as familiar with 3CX is that Twilio (and some other providers) are found on the Worldwide section of trunks (as they provide and port numbers in global regions and are not just stuck to a specific country).

In regards to the Apps for Android there was a new edition out last year (which should prompt - not auto update the user) IPhone I believe we are still awaiting a revamped update (one has been announced as in the pipeline).

 

[JohnS_3CX]

Hi Tim,

The update should resolve the issue immediately.

As for the apps, if they already worked with Update 3, you should have no problems with Update 4

 

[Tim Mrazek]

After applying the update the 'ringer' issues have pretty much disappeared. We have had one issue happen in 2.5 days. That one issue didn't have the split endpoint issue. I'm gonna say this issue is closed. Thanks for all the help.

 

[JohnS_3CX]

Glad to hear Tim, thanks for updating the thread with your results