Internet DRAFT - draft-procter-dispatch-outbound-discovery
draft-procter-dispatch-outbound-discovery
DISPATCH M. Procter
Internet-Draft VoIP.co.uk
Intended status: Informational November 14, 2014
Expires: May 18, 2015
Automatic discovery of RFC 5626 Edge Proxies
draft-procter-dispatch-outbound-discovery-02
Abstract
[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.
Status of This Memo
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 May 18, 2015.
Copyright Notice
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
Procter Expires May 18, 2015 [Page 1]
Internet-Draft Discovering outbound proxies November 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. User Agent Behaviour . . . . . . . . . . . . . . . . . . . . 2
2.1. Obtaining candidates for the outbound-proxy-set . . . . . 2
2.2. Creating the outbound-proxy-set from SRV RRs . . . . . . 3
2.3. Maintaining the outbound-proxy-set . . . . . . . . . . . 4
3. Registrar considerations . . . . . . . . . . . . . . . . . . 4
4. Edge Proxy considerations . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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 supporting
[RFC5626] may determine the outbound-proxy-set from the DNS.
2. User Agent Behaviour
2.1. Obtaining candidates for the outbound-proxy-set
The UA, preparing to register with a domain, gathers all the edge
proxies identified in SRV records associated with that domain. For
registrations to SIP URIs, the UA uses the service identifer "_sip-
outbound", but for registrations to SIPS URIs, the UA uses the
service identifier "_sips-outbound". This is combined with the
Procter Expires May 18, 2015 [Page 2]
Internet-Draft Discovering outbound proxies November 2014
relevant protocol identifier and domain to form the complete SRV
query.
For example, when registering against 'sip:example.com', the UA might
issue an SRV query for '_sip-outbound._udp.example.com'. 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.
If no results are obtained from this SRV query, then as a fallback,
the UA may perform a similar query using the service identifier
"_sip" or "_sips" when attempting to register against SIP and SIPS
URIs respectively.
2.2. Creating the outbound-proxy-set from SRV RRs
Once a set of SRV resource records have been retrieved, the UA
translates them into SIP URIs so that they can be used as as 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-outbound._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
Procter Expires May 18, 2015 [Page 3]
Internet-Draft Discovering outbound proxies November 2014
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 to generate the initial
registration via one of the proxies in the outbound-proxy-set.
Provided the initial registration is successful, and the registrar
supports [RFC5626] (as indicated by the presence of the outbound
option-tag in the Require header field of a successful registration
response), the UA can then create additional registrations to as many
of the remaining proxies in the outbound-proxy-set as are supported.
If the initial registration is successful, but the registrar does not
support [RFC5626], then the UA cannot establish subsequent
registrations.
If the initial registration is unsuccessful for reasons of edge proxy
failure or transaction timeout, then the UA may repeat the initial
registration but with a different outbound proxy selected from the
outbound-proxy-set.
2.3. Maintaining the outbound-proxy-set
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.
3. Registrar considerations
There are no changes needed for the correct operation of Registrars.
If the system uses SRV-based load-balancing, and has a low-priority
SRV record pointing to an edge proxy that is normally only used under
fault conditions (sometimes known as a 'canary' proxy), then a UA
using the approach described in this document might maintain
registrations via this canary proxy which might be considered
Procter Expires May 18, 2015 [Page 4]
Internet-Draft Discovering outbound proxies November 2014
unexpected. Such a system should not treat registration traffic via
the canary proxy as indicative of a fault condition.
4. Edge Proxy considerations
There are no changes needed for the correct operation of Edge
Proxies.
5. Security Considerations
TODO
6. IANA Considerations
TODO
7. Acknowledgements
The author thanks Dale Worley, Paul Kyzivat, Jon Peterson, Simon
Perreault, Cullen Jennings, and Olle Johansson for their thoughtful
comments and feedback.
8. Normative References
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
Author's Address
Michael Procter
VoIP.co.uk
St Edburg's Hall
Priory Road
Bicester, Oxfordshire OX26 6BL
UK
Email: michael@voip.co.uk
URI: http://www.voip.co.uk
Procter Expires May 18, 2015 [Page 5]
