Internet DRAFT - draft-procter-dispatch-outbound-unaptr
draft-procter-dispatch-outbound-unaptr
DISPATCH M. Procter
Internet-Draft
Intended status: Informational O. Johansson
Expires: November 19, 2015 Edvina AB
May 18, 2015
Automatic discovery of RFC 5626 Edge Proxies using U-NAPTR
draft-procter-dispatch-outbound-unaptr-01
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 based on U-NAPTR
[RFC4848] 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 November 19, 2015.
Copyright Notice
Copyright (c) 2015 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
Procter & Johansson Expires November 19, 2015 [Page 1]
Internet-Draft Discovering outbound proxies May 2015
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. User Agent Behaviour . . . . . . . . . . . . . . . . . . . . 2
2.1. Determining the outbound-proxy-set . . . . . . . . . . . 3
2.2. Maintaining the outbound-proxy-set . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.1. SIP-Outbound Application Service Tag Registration . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
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 may determine
the outbound-proxy-set from the DNS. The choice of U-NAPTR [RFC4848]
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.
2. User Agent Behaviour
Procter & Johansson Expires November 19, 2015 [Page 2]
Internet-Draft Discovering outbound proxies May 2015
2.1. Determining the outbound-proxy-set
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. [RFC5626] 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 [RFC5626] section 4 may be followed.
2.2. 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.
Procter & Johansson Expires November 19, 2015 [Page 3]
Internet-Draft Discovering outbound proxies May 2015
3. Security Considerations
TODO
4. IANA Considerations
This section contains the registration information for one U-NAPTR
application service tag (in accordance with [RFC4848]).
4.1. SIP-Outbound Application Service Tag Registration
Application Protocol Tag: SIPOUTBOUND
Intended usage: See Section 2.
Interoperability considerations: N/A
Security considerations: See Section 3.
Relevant related publications: [RFC5626].
5. Normative References
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
Authors' Addresses
Michael Procter
Email: michael.ietf@gmail.com
Olle E. Johansson
Edvina AB
Runbovaegen 10
Sollentuna SE-192 48
SE
Email: oej@edvina.net
Procter & Johansson Expires November 19, 2015 [Page 4]
