v16 Update 3 Alpha Brings Advanced DNS & Reconnect Controls

[YiannisH_3CX]

Can 3CX explain more how this works as to my knowledge DNS resolution has worked just fine for long time.

New DNS Options for SIP Trunks – using the new “Auto Discovery” with transport and IP mode options, ensures better control and provides flexibility over DNS resolutions

This update gives us (and you) a little more control over the DNS resolution and the transport selection afterwards. Up until now the transport (UDP,TCP,TLS) was selected automatically based on the DNS resolution. You can still do this by leaving everything default and having the auto discovery selected.
The difference now is you can select the desired transport from the options menu or you can disable auto discovery and force a port. So you can now replicate the previous behaviour but you can also select the desired transport and IP mode.
There will be more details regarding this coming soon.

 

[YiannisH_3CX]

This update breaks the SIP trunks!
Guys please check with your SIP trunk providers before releasing this update!

Can you please let us the provider you are referring to so we can check?

 

[StefanW]

is reconnect going to be (or already) supported in the iOS client?

yes in the next version which should then also take the new UI. If you are in the TestFlight of iOS (the way we can ship Beta to iOS) you will see it earlier.

 

[TecMate]

Regarding

New DNS Options for SIP Trunks

– using the new “Auto Discovery” with transport and IP mode options, ensures better control and provides flexibility over DNS resolutions.

Unfortunately this implementation seems to be the opposite of "better control..."
Currently there is no way (short of packet capture) for the admin to determine whether the SIP registration is TCP or UDP or is using the DNS SRV records or A records or what.

How would I change a SIP Trunk to TCP port xxxx using the choose the provider's DNS records?

Auto Discovery should be on by default or depending on the SIP trunk carrier's profile. Then have the options for the admin to select TCP or UDP and port number.

That way when things go wrong with DNS there would options to revert to a manual setting.

Also creating hidden options in 3CX like adding transport-tcp.sip-provider.com to force TCP instead of UDP isn't great.

Shouldn't there just be a selection button next to the host name with (AutoDiscover/TCP/UDP)?

And the methods 3CX uses for Auto Discovery should be well documented.

Such as:
During Auto Discovery 3CX does the following:

1. performs a DNS SRV lookup for _sip._tcp.hostname.com if that fails
2. performs a DNS SRV lookup for _sip._udp.hostname.com if that fails
3. does a DNS A record for hostname.com and tries TCP then UDP and the port number given in the SIP trunk settings if that fails attempts port 5060
4. once a successful registration is made 3CX stores that info until the Trunk is disabled and then the Auto Discovery takes place again once the Trunk is re-enabled or on reboot of the server.

 

[Evolute IT]

Shouldn't there just be a selection button next to the host name with (AutoDiscover/TCP/UDP)?

That's already what it is in the Alpha.

 

[cobaltit]

Unfortunately this implementation seems to be the opposite of "better control..."
Currently there is no way (short of packet capture) for the admin to determine whether the SIP registration is TCP or UDP or is using the DNS SRV records or A records or what.

Super confused by this statement. Does it really matter what the registration method is if it works? And if it doesn't, you have a couple ways to figure how how you should be registering. If you are using a 3CX supported provider it works out of the box with the template. Otherwise you can simply look up the DNS records yourself or your provider can simply tell you how to register which all do.

How would I change a SIP Trunk to TCP port xxxx using the choose the provider's DNS records?

Auto Discovery should be on by default or depending on the SIP trunk carrier's profile. Then have the options for the admin to select TCP or UDP and port number.

That way when things go wrong with DNS there would options to revert to a manual setting.

Umm you don't change the SIP trunk to TCP using the providers records. Autodiscover handles that assuming the provider is publishing the correct records. And all of the 3CX supported providers should work out of the box (assuming that's what you mean by the carrier profile). And all the auto discover button changes is making the autodiscover more obvious. The actual mechanism has been there for a while and the manual control hasn't gone anywhere.

And the methods 3CX uses for Auto Discovery should be well documented.

You mean like this?

https://www.3cx.com/docs/sip-trunk-dns-record-resolution/

Lots of

 

[Benedikt Machens]

Can 3CX explain more how this works as to my knowledge DNS resolution has worked just fine for long time.

New DNS Options for SIP Trunks – using the new “Auto Discovery” with transport and IP mode options, ensures better control and provides flexibility over DNS resolutions

Some more informations would be great about this. I already had trouble with IPv6 DNS and also IPv6 as itself. Because if you have several IPv6 adresses on a system this can break if the PBX tooks the wrong IP (quite bad idea to use the link-local IPv6 for external communication). So "auto discovery" is nice, but a little technical description can help to discover if it is a automatic helper or automatic killer

Regards

 

[YiannisH_3CX]

Some more informations would be great about this. I already had trouble with IPv6 DNS and also IPv6 as itself. Because if you have several IPv6 adresses on a system this can break if the PBX tooks the wrong IP (quite bad idea to use the link-local IPv6 for external communication). So "auto discovery" is nice, but a little technical description can help to discover if it is a automatic helper or automatic killer

As i mentioned in a previous reply more information will become available in the future as we are nearing the release version.
In short when the trunk is set to "Auto Discovery" the PBX will follow the NAPTR or SRV records of the provider (if available) similar to the way it is currently done.
The difference is that now you have 2 additional options with the transport and IP mode selectors you can force a specific transport protocol or an IP mode.
For example lets assume your provider has NAPTR records that point to UDP, but the provider also supports TCP. You can now select TCP from the transport selector and force the PBX to register using TCP and not UDPm bypassing the NAPTR records.

 

[bkreeger]

It would be helpful to have a little more information that "breaks the trunks", come on get technical!

It would also be good to know if you are using a 3CX supported provider or not.

Also I hope you are not using an Alpha revision on a live/customer site ....... these are for testing/production environments only.

We see no issues so far in testing the new DNS Auto Discovery feature.

 

[TecMate]

Super confused by this statement. Does it really matter what the registration method is if it works? And if it doesn't, you have a couple ways to figure how how you should be registering. If you are using a 3CX supported provider it works out of the box with the template. Otherwise you can simply look up the DNS records yourself or your provider can simply tell you how to register which all do.



Umm you don't change the SIP trunk to TCP using the providers records. Autodiscover handles that assuming the provider is publishing the correct records. And all of the 3CX supported providers should work out of the box (assuming that's what you mean by the carrier profile). And all the auto discover button changes is making the autodiscover more obvious. The actual mechanism has been there for a while and the manual control hasn't gone anywhere.



You mean like this?

https://www.3cx.com/docs/sip-trunk-dns-record-resolution/

Lots of

cobaltit
First. Thank you for the link to the DNS record resolution documentation. That's exactly what I was looking for! So again thank you.

Second. Yes, is does matter what the registration method is especially when it's NOT working out of the box. Case in point; I am using a recently Certified 3CX Trunk Template and specifically having call registration and DNS resolution problems that I am trying to troubleshoot with the assistance of the SIP Trunk provider's engineers. My point was troubleshooting these problems would be much easier if the controls for the registration methods were right there in the SIP Trunk settings with a drop-down next to the Registrar Hostname like:

• Autodiscover
• NAPTR
• SRV
• SIPS TCP
• TCP
• UDP

Port #

I have done the nslookup and all of the testing troubleshooting steps I can think of.

If you're interested the problem I'm referring to is posted here https://www.3cx.com/community/threads/3cx-dns-srv-resolution-issues.67708/

 

[N_G]

@DanTron - if you are using a certified provider you should stick to the template provided and troubleshoot any issues you have with their support without changing the template. They will be network or firewall issues, nothing to do with the template. The template provided will be tested and working.

 

[autohaus]

I have a Gigaset N870 DECT System. Since this alpha version Gigaset's central phonebook is provisioned. But firstname and lastname are swapped.

If a 3cx contact has serveral phonenumbers the gigaset _phonebook.xml will have a separate entry for each number. For example if a contact "John Doe" has a mobile, home and work number you'll get three different phonebook entries for John Doe. Thus resulting in "too much entries found" message in my Gigaset phone.

Before this, I exported my 3cx contacts to a csv file and converted them to xml. No problems with multiple numbers in a Gigaset contact.

Automatic contact export is great, but it should work as expected.

 

[autohaus]

Here is Gigaset's N870/N670 xml Template for a central phonebook:
https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=902955346

For 3CX to create a correct gigaset _phonebook.xml, you have to swap "surname" and "name" during creation of that file.
A Gigaset contact can have numbers for: home1, home2, office1, office2, mobile1, mobile2. No need to create a separate contact for each number.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE LocalDirectory>
<list>
<entry home2="" surname="Lastname" mobile1="" mobile2="" office1="0049123456789" office2="" name="Firstname" home1=""/>
<entry home2="" surname="User" mobile1="0049987654321" mobile2="" office1="" office2="" name="First" home1=""/>
</list>

 

[JohnS_3CX]

Hi @autohaus

You can change this option from the MC under contacts, and the phones will swap the order at the next refresh

 

[autohaus]

Hi JohnS_3CX,
in my MC contact settings I have: lastname, firstname.

But that setting ist only to select in which order these fields are displayed on the phone during a call. It is not logical, that depending on this setting the exported fields will be swapped (Lastname stays lastname).

Please export these fields as gigaset expects them ( surname = 3cx_lastname, name = 3cx_firstname). Otherwise Gigasets's search function doesn't work.

 

[JohnS_3CX]

That setting affects the way the company phonebook entries will appear on device directories.

First Name, Last Name -> Sends this in the appropriate fields
<entry surname="Peterson" name="James" office1="000" office2="" home1="" home2="" mobile1="" mobile2=""/>

Last Name, First Name -> Sends this in the reverse fields
<entry surname="James" name="Peterson" office1="000" office2="" home1="" home2="" mobile1="" mobile2=""/>

As you see, it clearly swaps the order the names are sent. If we always send them in the correct order like example 1, and the manufacturer does not have a "Sort" option on the DECT device, you will not the option to swap the order. The Gigaset S650H for example, does not have an option to sort the contacts by name or surname when it comes to the Online Directory.

In your case, since you want it to work the way the manufacturer intended, I suggest to use the option as below, and your search function will always work correctly. Just remember that the changes will not apply until the base downloads the contacts again.

 

[ltctech]

I ran into this today:
https://www.3cx.com/community/threads/3cx-sends-notify-to-local-ip-address.57955/

Essentially unless a phone knows exactly what its external IP and port(s) are then any form of Subscribe (VM, BLF) or Refer (transfer) will fail. It's maddening when Invites are sent and received correctly along with RTP regardless of Contact headers. However, when a Notify needs to be sent, 3CX blindly follows the Contact header regardless of where the Subscribe or Refer actually came from.

Why is the implementation inconsistent across SIP requests? Is this fixed in Update 3? Are there any future plans to fix this?

 

[EarlGrei]

Do you folks have an expected release date for U3? We are starting to migrate users to 3CX from FreePBX and I have much more interest in the mobile app than I thought I would.

 

[JohnS_3CX]

@EarlGrei Its out now

 

[gogusrl]

Any updates on the REST API ? We're turning away client after client because of this.