michael.ietf@gmail.com

Edvina AB

Runbovägen 10 Sollentuna SE-192 48 SE oej@edvina.net

DISPATCH (commonly known as 'SIP outbound') defines mechanisms that permit SIP (Session Initiation Protocol) UAs (User Agents) to maintain multiple connections to a registrar or proxy via multiple Edge Proxies, known as the outbound-proxy-set. Discovering the URIs that make up the outbound-proxy-set is left to configuration or future discovery mechanisms. This draft defines a simple discovery mechanism based on U-NAPTR that enables UAs to discover the URIs of all the Edge Proxies in the outbound-proxy-set without requiring additional configuration on the UA.

Reliably maintaining connectivity between a SIP UA and a registrar across the Internet, in the presence of NATs, routing changes, and maintenance of intervening equipment is made more straightforward by . The mechanisms in that specification allow multiple connections over diverse routes, equipment, and data centres, which permit a more robust SIP service to be created. However, one of the hurdles that is preventing wide-spread use of these mechanisms is discovering the outbound-proxy-set, the list of suitable edge proxies that a UA may use for multiple connections. Some UAs permit this set to be configured, but the large number of options available on many UAs means that configuration for robustness is often overlooked once basic operation is possible. This draft describes a simple mechanism by which a UA may determine the outbound-proxy-set from the DNS. The choice of U-NAPTR is driven by the desire to directly discover URIs to use as outbound proxies, yet also minimise the complexity of the solution by not requiring the regular expression processing associated with a full NAPTR implementation.

When a UA wishes to determine the outbound-proxy-set for a particular domain (the domain against which it wishes to register), it submits a DNS NAPTR query for that domain.

For example, when registering against 'sip:example.net', the UA would submit a DNS NAPTR query for "example.net", and might receive a response contains answers such as: NAPTR 100 10 "u" "SIPOUTBOUND" "!^.*$!sips:lon.example.net!" "" NAPTR 100 10 "u" "SIPOUTBOUND" "!^.*$!sips:nyc.example.net!" "" NAPTR 100 20 "u" "SIPOUTBOUND" "!^.*$!sips:cph.example.net!" "" NAPTR 100 30 "u" "SIPOUTBOUND" "!^.*$!sips:sfo.example.net!" "" NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.net. NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.net.

In this example, four SIP URIs with an application service tag of "SIPOUTBOUND" are provided with the same order and varying preference values. A UA may use as many of these as it supports in preference order as the outbound-proxy-set. requires UAs to support at least two and preferably up to four outbound-proxies. TODO: should we use both application service and protocol tags, e.g. "OUTBOUND:sip" & "OUTBOUND:sips", or just a service tag as shown? TODO: Is it worth noting we can only use answers with the same order value? rfc3403 is very clear that you can't consider answers with different orders. Following the construction of the outbound-proxy-set, the procedures in section 4 may be followed.

Since the outbound-proxy-set is now determined dynamically, rather than through static configuration, care should be taken to respect the relevant DNS TTL values and ensure that when the DNS records change, the configuration of the outbound-proxy-set and the number and destinations of registrations are updated accordingly. If the outbound-proxy-set is refreshed and no changes are found, then the UA continues to use the flows it has already established. If it has a flow to a proxy that is no longer present in the outbound-proxy-set, it should take steps to remove that flow. Similarly, if additional proxies are now available, the UA may choose to establish flows to these proxies.

TODO

This section contains the registration information for one U-NAPTR application service tag (in accordance with ).

Application Protocol Tag: SIPOUTBOUND Intended usage: See . Interoperability considerations: N/A Security considerations: See . Relevant related publications: .