logo

Openplatform.xyz

Placeholder for our stuff related to Telecom, IT, Internet of things (IOT), ESP8266, Raspberry Pi

Home IOT Telecom IT stuff About Us Contact Us Site Map
To open call flow image in new window click here.

NAPTR and SRV query to locate sip serversrs

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.

Determine Transport protocol:

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

*Use TCP if request exceeds the path MTU

Note: Some proxies can have static configuration to look at target and route calls to pre-configured next hope, so that dns lookup is not needed.

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.

Related Pages

Related Links

https://www.ietf.org/rfc/rfc3263.txt
https://www.zytrax.com/books/dns/ch8/naptr.html