- Joined
- Feb 17, 2016
- Messages
- 114
- Reaction score
- 91
Hello,
I know that 3CX supports NAPTR in SIP Trunk configurations (in Auto Discovery).
Will the applications (3CXPhone for Windows , 3CX Desktop App) ever support this same protocol or "Auto Discovery" mode ... (for those who manage their own FQDN?)
And, for the phone provisioning models that support it (Aka Yealink, Snom). ?
We are looking for an alternative solution to split DNS, according to our tests with Yealink phones, NAPTR records with SRV records, this seems to be a very goood solution without having to support the configuration of DNS Zones in the client DNS servers.
That said, we are at the beginning of our tests, have other people tried and have comments to share on the NAPTR solution?
Bugs ? Problems ? Drop calls ?
We intend to use it simply as an alternative to Split DNS.
When a user is "local" with the PBX, it would resolve local NAPTR/SRV.
In case it is remote, as it is not able to reach the PBX with the local iP address resolved by the NAPTR/SRV priority, it would contact via the public iP, the PBX.
No Load Balancer. No FailOver, Only one PBX.
thx all
@3CX if you "tagg" this post .. `` unsupported `` , can you leave the post "open" for comments to allow discussion on the subject. This may open an interest in posting an idea under the "idea" category depending on the level of interest. Under no circumstances would we advise changing anything in the "3CX custom settings"
.
I know that 3CX supports NAPTR in SIP Trunk configurations (in Auto Discovery).
Will the applications (3CXPhone for Windows , 3CX Desktop App) ever support this same protocol or "Auto Discovery" mode ... (for those who manage their own FQDN?)
And, for the phone provisioning models that support it (Aka Yealink, Snom). ?
We are looking for an alternative solution to split DNS, according to our tests with Yealink phones, NAPTR records with SRV records, this seems to be a very goood solution without having to support the configuration of DNS Zones in the client DNS servers.
That said, we are at the beginning of our tests, have other people tried and have comments to share on the NAPTR solution?
Bugs ? Problems ? Drop calls ?
We intend to use it simply as an alternative to Split DNS.
When a user is "local" with the PBX, it would resolve local NAPTR/SRV.
In case it is remote, as it is not able to reach the PBX with the local iP address resolved by the NAPTR/SRV priority, it would contact via the public iP, the PBX.
No Load Balancer. No FailOver, Only one PBX.
thx all
@3CX if you "tagg" this post .. `` unsupported `` , can you leave the post "open" for comments to allow discussion on the subject. This may open an interest in posting an idea under the "idea" category depending on the level of interest. Under no circumstances would we advise changing anything in the "3CX custom settings"
.
Last edited:
