| DISPATCH | M. Procter |
| Internet-Draft | VoIP.co.uk |
| Intended status: Informational | July 04, 2014 |
| Expires: January 5, 2015 |
Automatic discovery of RFC 5626 Edge Proxies
draft-procter-dispatch-outbound-discovery-00
[RFC5626] (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 that enables UAs to discover the URIs of all the Edge Proxies in the outbound-proxy-set without requiring additional configuration on the UA.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC5626]. 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 advertise willingness to use the capabilities of [RFC5626] by determining the outbound-proxy-set from the DNS. Should the registrar know that the outbound-proxy-set may be determined from the DNS, it can indicate such support in a successful response to a REGISTER request. The UA, upon receiving that indication, may then determine the outbound-proxy-set and continue to register multiple flows as described in [RFC5626].
A UA may register as normal, following the rules in section 4.2 of [RFC5626], but with an additional Supported option: obfromsrv.
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Supported: path, outbound, obfromsrv
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1;
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>"
Content-Length: 0
The presence of this option indicates that the UA is willing to determine the outbound-proxy-set from the DNS as described later. The response from the registrar will indicate whether this action is to be taken or not.
If the successful response from the registrar includes the same option (obfromsrv), then the UA may gather all edge proxies named in the SRV records and use them to populate the outbound-proxy-set.
The DNS SRV lookup will result in a set of targets and ports, along with weights and priorities. For the purpose of determining the outbound-proxy-set, the weights and priorities are discarded. The targets and ports are transformed into URIs by combining them with the scheme and protocol used in the the SRV query.
TODO: We could use the SRV weights and priorities to map to q-values on the registered contacts, but I'm not convinced mapping inbound and outbound preferences together like this is necessarily helpful.
For example, a DNS SRV query for '_sip._tcp.example.net' might result in the responses:
SRV 0 5 5060 edge-01.example.net.
SRV 0 5 5060 edge-02.example.net.
SRV 5 0 5060 edge-fallback.example.net.
These should be mapped to the following URIs, which will now form the outbound-proxy-set:
sip:edge-01.example.net:5060;transport=tcp
sip:edge-02.example.net:5060;transport=tcp
sip:edge-fallback.example.net:5060;transport=tcp
TODO: omit port if it is default for transport? Need to specify at least one of port and transport to prevent another round of NAPTR lookups when the o-p-s is used for loose routing to the Edge Proxy.
Following the construction of the outbound-proxy-set, the procedures in [RFC5626] section 4.2 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.
For a registrar that already supports [RFC5626], there is only one change. If the registrar is aware that the DNS records relating to it are suitably configured to be used in the way this document describes, and a UA attempting to register indicates support for these procedures, then it may signal acceptance by including the token 'obfromsrv' in the Supported header of the successful REGISTER response.
The registrar is typically made aware of support for this feature through adminstrative means, such as a configuration change. It might also be configured to only indicate support to a subset of UAs.
There are no changes needed for the correct operation of Edge Proxies.
This section gives a brief overview of other possible approaches. It can/will be deleted before publishing.
Add a new SIP header (e.g. Outbound-URIs:) containing a list of SIP URIs to use as the outbound-proxy-set to the 200 response from the registrar to the UA.
This will require changes to the registrar and UA only, assuming the edge proxies are transparent to the new header. It is a very flexible arrangement, as the list can be dynamically generated on a per-UA basis if required, and not generated at all to permit a controlled rollout of the new functionality.
Add a DNS record either containing the outbound-proxy-set or indicating that it may safely be derived from the existing SRV records.
This requires no changes to the registrar or edge proxies, and only a presumably straightforward DNS update, but the UA will potentially need new DNS lookups to change behaviour. This approach also prevents a staged rollout of the functionality since all UAs supporting the feature will discover it at the same time.
TODO
TODO
| [RFC5626] | Jennings, C., Mahy, R. and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. |