RFC 3263 - Locating SIP Servers contains a lot of cool features that SIP entities can take advantage of, to be located. It is much more advanced that just a simple name to IP address mapping. While the RFC itself provides all the nitty gritty details it is good to understand the process at a high level.
Any SIP entity that would like to send a message to a particular domain is required to perform the following DNS lookups:
Step 1 - Selecting a Transport
This is performed by doing a DNS NATPR record lookup on the domain part of the SIP URI or AOR trying to be routed to. The NAPTR record results tell clients which SIP protocol is preferred and in which order, ie: UDP, TCP or TLS. They also provide the next name element to be looked up. Clients should select the highest priority NAPTR record / protocol that they support, then perform step 2 on resulting name.
Step 2 - Discovering Servers
Using the name discovered from Step 1 a DNS SRV record lookup is performed. This can result in a number of records returned. Each record has a priority and weight and a mapped server/hostname. The priority and weight allow the owners of domain to implement a wide range of redundancy and load balancing options. For example: entries with equal priorities are load balanced to using a distribution described by their weight.
Step 3 - Resolving servers to IP Addresses
Using the priority and weight rules from Step 2 a single server/hostname is selected by the client and it's IP address is looked up via A and AAAA (IPv6) DNS queries. The request is then sent to that particular address.
If the request fails to send, then the next server from Step 2 is used to route the request to.
A potential gotcha:
DNS records have an expiration, and often this duration is much shorter than the duration of a SIP call or other long standing SIP communications. Some SIP servers are created such that they are stateless (or have shared state), but others are not. As a result it can detrimental if the SIP server receiving the REGISTRATION is not the same SIP server that receives a re-REGISTER or an INVITE at a later time. Some SIP servers expect that you do NOT always follow the DNS rules for every request that you send to them, and that you instead pick a "good" DNS server following the above rules, then stick with that server until you have errors communicating with it.
The reSIProcate stack offers the ability to configure its DNS resolution logic with the logic to stick to a known good server once it is found. This reSIProcate feature is called DNS VIP, and it can be enabled at the time you create the SipStack object via it's constructor.
Scott
Any SIP entity that would like to send a message to a particular domain is required to perform the following DNS lookups:
Step 1 - Selecting a Transport
This is performed by doing a DNS NATPR record lookup on the domain part of the SIP URI or AOR trying to be routed to. The NAPTR record results tell clients which SIP protocol is preferred and in which order, ie: UDP, TCP or TLS. They also provide the next name element to be looked up. Clients should select the highest priority NAPTR record / protocol that they support, then perform step 2 on resulting name.
Step 2 - Discovering Servers
Using the name discovered from Step 1 a DNS SRV record lookup is performed. This can result in a number of records returned. Each record has a priority and weight and a mapped server/hostname. The priority and weight allow the owners of domain to implement a wide range of redundancy and load balancing options. For example: entries with equal priorities are load balanced to using a distribution described by their weight.
Step 3 - Resolving servers to IP Addresses
Using the priority and weight rules from Step 2 a single server/hostname is selected by the client and it's IP address is looked up via A and AAAA (IPv6) DNS queries. The request is then sent to that particular address.
If the request fails to send, then the next server from Step 2 is used to route the request to.
A potential gotcha:
DNS records have an expiration, and often this duration is much shorter than the duration of a SIP call or other long standing SIP communications. Some SIP servers are created such that they are stateless (or have shared state), but others are not. As a result it can detrimental if the SIP server receiving the REGISTRATION is not the same SIP server that receives a re-REGISTER or an INVITE at a later time. Some SIP servers expect that you do NOT always follow the DNS rules for every request that you send to them, and that you instead pick a "good" DNS server following the above rules, then stick with that server until you have errors communicating with it.
The reSIProcate stack offers the ability to configure its DNS resolution logic with the logic to stick to a known good server once it is found. This reSIProcate feature is called DNS VIP, and it can be enabled at the time you create the SipStack object via it's constructor.
Scott
RSS Feed
