There is a lack of clarity on when and how 3CX pulls DNS SRV records. I was reading a blog( http://www.3cx.com/blog/voip-howto/nat-stun-network-configuration/ ) that said it would pull them by default and if unsucessful it would pull the A records. I have noticed the only way it attempts to look for SRV records is if you specify port 0 for the SIP server. The V11 admin manual does not discuss this.
My current voip provider (Callcentric) is encouraging users to switch to SRV records. The current method for callcentric.com port 0 is to only send a subset of all the SIP servers to the user agent when a DNS SRV query is made. They do this to help randomize the selection. I know that is not how it should be done but it is working for now. They send the answers all with the same priority and weight = 0. There is no requirement that I know of for the user agent to randomize the selection order for weight = 0. When the entire list of servers was sent in an earlier implementationt, 3CX would not randomize them and always select alpha1.callcentric.om to REGISTER with. And this worked it just was not random. 3CX correctly responds to the 407 authentication challenge in this situation.
Callcentric has also implemented a second method for registering with an SRV port. By specifying srv.callentric.com port 0 you get the entire list of 40 answers to your DNS query. 3CX seems to correctly complete the query by switching to TCP because the packet size is too large for UDP. This list of servers all have the same priority and non zero weights. The RFC standard specifies the user agent to randomize the same priority servers by utilizing the non zero weights. 3CX seems to correctly randomly select a server to REGISTER with. The first server returns a 407 authentication challenge with a nonce. Instead of responding correctly to that first server, pulls the DNS A record for the second random server and sends the REGISTER response with the first nonce to the second server instead of the first server that issued the 407. Needless to say the registration never completes.
Any comments? Is 3CX aware of a problem? Should I report this to engineering? How? Thank you.
My current voip provider (Callcentric) is encouraging users to switch to SRV records. The current method for callcentric.com port 0 is to only send a subset of all the SIP servers to the user agent when a DNS SRV query is made. They do this to help randomize the selection. I know that is not how it should be done but it is working for now. They send the answers all with the same priority and weight = 0. There is no requirement that I know of for the user agent to randomize the selection order for weight = 0. When the entire list of servers was sent in an earlier implementationt, 3CX would not randomize them and always select alpha1.callcentric.om to REGISTER with. And this worked it just was not random. 3CX correctly responds to the 407 authentication challenge in this situation.
Callcentric has also implemented a second method for registering with an SRV port. By specifying srv.callentric.com port 0 you get the entire list of 40 answers to your DNS query. 3CX seems to correctly complete the query by switching to TCP because the packet size is too large for UDP. This list of servers all have the same priority and non zero weights. The RFC standard specifies the user agent to randomize the same priority servers by utilizing the non zero weights. 3CX seems to correctly randomly select a server to REGISTER with. The first server returns a 407 authentication challenge with a nonce. Instead of responding correctly to that first server, pulls the DNS A record for the second random server and sends the REGISTER response with the first nonce to the second server instead of the first server that issued the 407. Needless to say the registration never completes.
Any comments? Is 3CX aware of a problem? Should I report this to engineering? How? Thank you.
