[ S N O M 4 S N A T F I L T E R ]
The distribution of user agents to a server is performed using DNS SRV (RFC 2782). This means that you need to list the available serv- ers on DNS level; the user agents must perform DNS SRV look ups and pick one of the servers (possible using the detection algorithms described below).
The following table shows an example configuration for Linux named(8):
_sip._udp | IN SRV | 3 5 5082 | frankfurt1 |
_sip._udp | IN SRV | 3 5 5082 | newyork1 |
_sip._udp | IN SRV | 3 5 5082 | newyork2 |
_sip._udp | IN SRV | 3 5 5082 | newyork3 |
_sip._udp | IN SRV | 3 5 5082 | tokyo2 |
_sip._udp | IN SRV | 3 5 5082 | tokyo1 |
If one of the servers should become unavailable, the SRV algo- rithm will make sure that the other servers will be contacted. The user agents that are refreshed by that particular server will become unreach- able until the user agents initiate a new REGISTER request. Therefore, you should make sure that your servers have a high uptime probability and that the registration period is not too long. We think that registration periods of thirty minutes up to one hour are a good balance between ser- vice failure time and performance.
2.5 Detecting the right NAT Filter
User agents must detect which server in the server farm is near- est to the user agent. This is an important feature for a company or operator that has user agents scattered around the globe. Example: A company has offices in Berlin, Tokyo and Dallas and locally operates NAT Filter servers. When a user agent is located in Tokyo, it should use the Tokyo server. This could be set up manually; howeve, it is also possible to automatically pick the best server.
To detect the nearest server, the user agent sends STUN packets to all possible servers (the servers with the lowest priority in the SRV list). The user agent picks the server that responds first. Alternatively, the user agent could send more test packets and take the mean response time for making the decision.
2.
