SIP uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact (RFC 3263). Refer to call flow diagram which illustrate a call where:
UA-A is registered in Domain-A (openplatform.xyz). Proxy-1 supports sip over TCP and UDP.
UA-B is registered in Domain-B (example.com)
INVITE: UA-A to Proxy-1
The URI of UA-B received in INVITE is "sip:[email protected]".
In order to send the INVITE for UA-B, Proxy 1 is required to discover the SIP server in domain B. Proxy-1 requires IP address, port, and transport protocol of Proxy-2 in Domain-B.
Let's see how Proxy-1 can discover transport protocol, next hope IP address and port to send INVITE.
If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used. If it's not specified in URI then there are certain rules to determine it.
We define TARGET as the value of the maddr parameter of the URI, if present, otherwise, the host value of the hostport component of the URI. TARGET identifies the domain to be contacted.
In our sample call flow TARGET is "example.com", called uri is sip and port is not specified, this matches third condition in below table. So Proxy-1
should do a NAPTR query to find out transport protocols supported in example.com.
"sip:[email protected]"
Target / Port | Called URI | Transport Protocol to be used by Proxy-1 |
Target is IP and/or Port is present | SIP | UDP* |
Target is IP and/or Port is present | SIPS | TCP |
Target is not IP and Port Not Specified | ANY | NAPTR Query to DNS |
NAPTR Query:Proxy-1 to DNS
Proxy-1 does a NAPTR lookup for example.com and receives NAPTR records in reply.
# host -t NAPTR example.com order pref flags service regexp replacement IN NAPTR 50 40 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com. IN NAPTR 100 40 "s" "SIP+D2U" "" _sip._udp.example.com.
This indicates that the proxy-2 supports TLS over TCP, TCP, and UDP, in
that order of preference.
Proxy-1 intersects its ist of supported
transport protocols with those of proxy-2 and then chooses the protocol
preferred by proxy 2.
in our example proxy-1 doesn't support TLS so it
chooses SIP over TCP to send INVITE to proxy-2.
Now Proxy-1 has discoverd transport protocol as TCP, next it has to do SRV query.
Lets have a look on fields in NAPTR reply:
order: Lowest number is of highest order. example.com has first priority for TLS, 2nd for TCP and 3rd for UDP.
perf: Perference is used only when two or more records have same order. Lower number has more preference.
flag: Currently defined values are:
S - a terminal
condition - the replace field contains the FQDN of an SRV RR.
U - a
terminal condition - the result of the regexp is a valid URI
A - a
terminal condition - the replace field contains the FQDN of an A RR (or
AAAA RR).
P - a non-terminal condition - the protocol/services part
of the params field determines the application specific behavior.
"" (empty string) - a non-terminal condition - regexp is empty and the
replace field contains the FQDN of another NAPTR RR.
service: Application specific service parameters to
reach example.com
"SIP+D2U" is SIP over UDP
"SIP+D2T" is SIP
over TCP
"SIPS+D2T" is SIP TLS over TCP
"E2U+email" is email
regexp: Enclosed in quotes (""). Since this is a discovery method, it does not use the regexp field.
replace: If present the replace field is assumed to be a valid FQDN which may be used as SRV RR lookup (flag = "S") or an A/AAAA RR lookup (flag="A")
In case you are intersted in more details on NAPTR, head on to https://www.zytrax.com/books/dns/ch8/naptr.html
SRV Query:Proxy-1 to DNS
Next proxy-1 performs SRV lookup over _sip._tcp.example.com
# host -t SRV _sip._tcp.example.com ;; Priority Weight Port Target IN SRV 0 1 5060 proxy2.example.com IN SRV 0 2 5060 proxy22.example.com
We got 02records, first proxy-1 will try proxy2.example.com as it has lower weight (Priority is same that's why we are looking and weight)
From srv lookup now we have port (5060) and host (proxy2.example.com). To determine the IP address proxy-1 will do an "A" or "AAAA" record lookup.
Note: If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport.
A or AAA Query:Proxy-1 to DNS
Proxy-1 performs an "A" lookup to find IP address of proxy-2.
# host proxy2.example.com proxy2.example.com has address 1.2.3.4
At this stage, proxy-1 has all required information IP Address, Port and Transport Protocol to send INVITE to proxy-2.
Failing that, proxy-1 will try next SRV record (proxy22.example.com). If this too fails, proxy-1 would go back to the next record in original NAPTR lookup and do an SRV lookup.
Now proxy-1 sends INVITE to proxy-2 and call completes succesfully.