Internet DRAFT - draft-koivusalo-sip-outbound-discovery
draft-koivusalo-sip-outbound-discovery
SIP E. Koivusalo
Internet-Draft Nokia
Expires: December 18, 2006 June 16, 2006
Discovering Proxies Supporting SIP Outbound
draft-koivusalo-sip-outbound-discovery-02.xml
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes modifications to DNS procedures used to
resolve a SIP Uniform Resource Identifier (URI) into the IP address,
port, and transport protocol of the next hop to contact. These
modifications enable the SIP User Agent (UA) to discover those
proxies, within the domain of the SIP URI, that support SIP
extensions described in draft-ietf-sip-outbound document. The
introduced mechanisms update behavior defined in RFC 3263.
Koivusalo Expires December 18, 2006 [Page 1]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Problems, Requirements and Solutions . . . . . . . 4
2.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Solutions Proposed . . . . . . . . . . . . . . . . . . . . 7
2.4. Evaluation of Solution Alternatives . . . . . . . . . . . 7
2.4.1. New NAPTR Service Types . . . . . . . . . . . . . . . 8
2.4.2. New prefixes for DNS SRV records . . . . . . . . . . . 9
2.4.3. New string for DNS TXT records . . . . . . . . . . . . 10
2.4.4. No standardized autodiscovery . . . . . . . . . . . . 10
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 12
4. New NAPTR Service types . . . . . . . . . . . . . . . . . . . 13
5. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 14
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Koivusalo Expires December 18, 2006 [Page 2]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
1. Introduction
Document draft-ietf-sip-outbound [8] describes extensions to Session
Initiation Protocol (SIP), which enable the User Agent (UA) to create
and maintain a persistent flow towards a Proxy, so that the Proxy is
able to use the existing flow for routing messages towards the UA
located behind a Network Address Translator (NAT). In this document
those extensions are referred as 'SIP Outbound'. These extensions
are not backwards compatible for proxies compliant to RFC3261 [3] as
they, for instance, require the proxy to support Simple Traversal of
UDP through NATs (STUN) protocol for flow keepalive messages in the
same port that the proxy uses for SIP.
RFC 3263 [2] describes DNS procedures used to locate SIP servers.
This document describes the specific problems that a UA meets with
when locating SIP proxies supporting SIP Outbound. It also records a
set of requirements for the autodiscovery solution. Finally the
document outlines a solution, based on DNS NAPTR (Naming Authority
Pointer) and SRV (Location of Service) records, along with a
discussion about the benefits and drawbacks of this solution in
comparison to known alternatives. The outlined solution updates the
procedures described in RFC 3263 [2] and RFC 2782 (DNS SRV). [5].
Koivusalo Expires December 18, 2006 [Page 3]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
2. Overview of Problems, Requirements and Solutions
2.1. Problem statement
For a UA located behind a NAT or firewall it is important to be able
to use those proxies within the domain, that support the SIP Outbound
extensions. The UA needs the proxy to support SIP Outbound to be
able to form a flow through the middlebox and keep the flow alive by
sending STUN Binding Requests to the Proxy.
Document draft-ietf-sip-outbound [8] suggests that a SIP UA should
support of outbound-proxy-set of at least two proxies. Furthermore
the UA should create a registration binding and keep a flow alive
towards each of those proxies, in order to protect the connection
against the failure of a single flow or proxy. However no specific
method was defined for the UA to discover such a proxy set, apart
from configuring the UA explicitely with multiple proxy URIs.
On the other hand, the ability for the UA to automatically discover
the outbound-proxy-set would help the service provider to deploy SIP
Outbound. It would also enable a mobile UA to discover proxies
supporting SIP Outbound when accessing the service via a visited SIP
domain.
Service providers have indicated a need to be able to divide their
proxies to multiple farms, in relation to SIP Outbound usage:
o Farm of proxies supporting the extensions defined in
draft-ietf-sip-outbound [8] so that the clients of the service
provider can use those servers for their primary flows. Service
provider may also divide the set of primary proxies to one single
or multiple pools in various ways, in order to control how the
total load for UAs would be shared between the proxies in this
farm and how the UAs would create their secondary flows towards
proxies in this farm or another farm.
o An optional farm of idle backup proxies supporting SIP Outbound
extensions so that the clients of the service provider could use
those servers as their backup outbound proxies in case the used
primary proxy fails. While all the primary proxies work
correctly, the UAs would use such a backup proxy only for setting
up a flow during registration and keeping the flow alive
thereafter. Other kind of requests would be routed via the backup
proxy only when the flow towards the primary proxy fails. This
would allow the service provider to maintain a pool of backup
proxies with a smaller number of servers than in the pool of
primary proxies e.g. to protect N primary proxy servers with one
single idle backup server (1:N protection).
Koivusalo Expires December 18, 2006 [Page 4]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
o Proxies not supporting SIP Outbound extensions, to be used by
clients of other service providers when trying to reach the SIP
users registered into the domain of the service provider.
This kind of setup poses the UA with two problems when it tries to
locate an outbound proxy to use:
Which proxies in the domain support SIP Outbound ?
Which proxies in the domain should be used for the primary flow
and which ones for the secondary flow ?
2.2. Requirements
This section provides the requirements summary for the autodiscovery
solution.
The following requirements apply to how a UA would be able to
discover its outbound-proxy set:
REQ-OUTB-DISC-01: The UA must be able to find out which proxies
within a domain support SIP Outbound, to avoid the UA
unnecessarily try connecting proxies that do not support those
extensions.
REQ-OUTB-DISC-02: The proxy autodiscovery procedures should not
introduce many extra round-trips between the UA and the network.
REQ-OUTB-DISC-03: It must be possible for the UA to discover an
outbound-proxy-set which consists of a single or multiple proxies,
regardless of whether the proxies are colocated with registrar(s)
or separate edge proxies.
REQ-OUTB-DISC-04: The size of the outbound-proxy-set discovered
automatically must reach at least the minimum size specified in
draft-ietf-sip-outbound [8].
REQ-OUTB-DISC-05: The UA must be able to discover different
proxies for the primary and secondary flow, based on a single
SIP(S) URI that is either derived from the domain of the AOR of
the user, configured separately to the UA as the URI of the
outbound proxy or which the UA has retrieved from DHCP.
REQ-OUTB-DISC-06: It must be possible for a mobile UA to set up
and keep only one single flow alive so that the UA would not
exhaust its battery too quickly when sending keepalive messages
for multiple flows.
Koivusalo Expires December 18, 2006 [Page 5]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
REQ-OUTB-DISC-07: The maximum size of the outbound-proxy-set
automatically discovered must not limit the maximum size of the
outbound-proxy-set that the UA may support by configuring multiple
proxy URIs into the UA.
Note: There is no requirement that the UA must be able to
automatically discover the SIP Outbound support of the registrar.
This means that using the proxy autodiscovery features, the UA may
use SIP Outbound towards a proxy in visited network even if its
backup registration would override the primary registration in the
registrar.
The following requirements apply to how a service provider would be
able to set up the proxy farms for its domain:
REQ-PROXY-FARM-01: When a UA or proxy which belongs to a domain
uses RFC 3263 [2] procedures to resolve an AOR of a user belonging
to another domain, the result should consist of IP addresses of
those servers that the service provider has set up for receiving
requests from other domains.
REQ-PROXY-FARM-02: It must be possible for the service provider to
pool all proxies supporting SIP Outbound into a single logical
pool of servers. The clients of that domain would use the servers
within that pool for both their primary and secondary flows and
the load for the UA population would be shared between all of
those servers.
REQ-PROXY-FARM-03: It must be possible for the service provider to
divide the proxies supporting SIP Outbound into two logical pools
so that one of the pools would be used for primary flows while the
other pool would be used for the backup flows. In normal
operation the load for the UA population would be shared between
the servers in the primary pool. A UA would use the backup flow
only as long as its primary flow would stay failed so that the
number of servers in the backup pool could be much lower than the
number of servers in the primary pool.
REQ-PROXY-FARM-04: It must be possible for the service provider to
split the above mentioned two logical pools of servers into
multiple physical pools, e.g. for georaphical separation of the
pools to minimize the effect of a single point (or area) of
failure.
REQ-PROXY-FARM-05: It must be possible for the service provider to
have only a single proxy so that the UA would not create multiple
flows.
Koivusalo Expires December 18, 2006 [Page 6]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
2.3. Solutions Proposed
The solution to the problem of "discovering proxies that support SIP
Outbound" is to introduce new values for service field of DNS NAPTR
record for this purpose. When performing a NAPTR query for the
domain name, the UA looking for SIP Outbound support would pick those
NAPTR records indicating the corresponding service type.
The solution to the problem of "discovering proxies for primary and
secondary flows" is to introduce a small change to DNS SRV record
processing as described in RFC 2782 [5]:
o To allow the UA to contact multiple target hosts instead of a
single one
o To specify how the UA would determine the target hosts for its
primary and secondary flow, based on the SRV priority and weight
fields
RFC 3263 [2] together with RFC 2782 [5] describe how the UA should to
use SRV records for resolving a SIP(S) URI to an IP address of a
single target host to contact. The idea for SIP Outbound is that
additionally to contacting the target host with the lowest-numbered
priority the UA can reach (for the primary flow), the UA could select
and contact another host (for the secondary flow) by processing the
remaining SRV records with a logic described within this document.
Specifying the logic explicitely has two aims:
o Enable the UA vendors to implement this logic so that the UA is
able to automatically discover a host towards which the secondary
flow should be set up.
o Enable the service providers to provision the SRV records for
their domains so that they achieve the desired effects both for
their preferred load balancing and redundancy schemes.
2.4. Evaluation of Solution Alternatives
While usage of SRV records is an evident choice for identifying
target hosts for the primary and secondary flows, there were multiple
options evaluated for discovering which proxies of the domain support
SIP Outbound. This section provides a summary of the evaluation done
and reasons behind choosing the NAPTR records as the proposed
solution. The following alternatives were evaluated:
1. Introduce new service types for DNS NAPTR records for SIP
Outbound.
Koivusalo Expires December 18, 2006 [Page 7]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
2. Introduce standard prefixes for DNS SRV records for SIP Outbound.
3. Introduce a standard string for DNS TXT records for SIP Outbound.
Associate such DNS TXT records with the DNS SRV records used for
SIP proxies of a domain.
4. Instead of autodiscovery, rely on SIP signaling so that the UA
would require the proxy to support SIP Outbound extensions within
the REGISTER request and let the proxy to reject or redirect the
request if it does not support SIP Outbound.
2.4.1. New NAPTR Service Types
Solution of introducing new NAPTR service types for SIP Outbound will
satisfy all the requirements listed in this document. Additionally
to that there are a few other properties to be mentioned.
Additional NAPTR records do not introduce backwards compatibility
problems for UAs not supporting SIP Outbound, since those UAs would
discard those new NAPTR service types according to RFC 3263 rules.
Further on when procedures of RFC 3263 would be used for routing a
SIP request to another domain having separate proxy farms for
outbound and inbound traffic, the result is a list of servers without
SIP Outbound support, aimed for inbound traffic. This is the desired
outcome according to requirement REQ-PROXY-FARM-01.
On the other hand, if the same proxies can be used both outbound and
inbound traffic so that all the servers of a domain would support SIP
Outbound, then no new SRV records would be needed. In this case the
new NAPTR records would be mapped to the very same SRV RRs that would
be used for existing "SIPS+D2T", "SIP+D2T", "SIP+D2U", "SIPS+D2S" and
"SIP+D2S" services. So the impacts to the DNS configuration would be
minimal.
The biggest drawback of introducing new NAPTR records for SIP
Outbound is that the service type would indicate a combination of
three properties - support for SIP Outbound, SIP security and
transport protocol - instead of currently used two properties.
Adding new orthogonal properties to a single service type field would
cause a combinatorial explosion of service type values needed. New
service types for SIP Outbound will actually double the number of
NAPTR records needed for SIP service. Currently five NAPTR service
types have been defined for SIP. There is one service type for each
transport protocol: UDP, TCP with and without TLS (Transport Layer
Security) and SCTP (Stream Control Transmission Protocol) also with
and without TLS [1]. Defining new NAPTR service types for SIP
Outbound on top of all those five transport protocols results five
new NAPTR services. Using DNS in this way is not scalable further as
Koivusalo Expires December 18, 2006 [Page 8]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
discussed in RFC 3486 [10]. However using DNS NAPTR exceptionally in
that way for the context of SIP Outbound is deemed justified due to
the following reasons:
o SIP Outbound will practically become a precondition for a UA to
use SIP at all in the environments where UA is behind a NAT. In
those cases the UA could not just opt using any proxy discovered
and just restrain itself not to use SIP Outbound features if the
proxy does not have support for it. If it would do this the UA
would have to use a not recommended NAT keepalive method, like
sending SIP OPTIONS requests frequently.
o SIP Outbound is the only known SIP extension that suggests the UA
to send REGISTER request to multiple proxies, to set up multiple
redundant flows. This exceptional requirement makes the discovery
problem rather complex and powerful tools are needed for solving
it.
o SIP Outbound relies on multiplexing SIP and STUN protocols to the
same port of the proxy and as such introduces a new type of
service, rather than an extension to an existing protocol.
2.4.2. New prefixes for DNS SRV records
A proposal was done to introduce a standard prefix like "_sipo" or
"_ob._sip" to be used for DNS SRV records to indicate that the
corresponding servers would support SIP Outbound. The main driver
behind this solution was that idea that the UA would not need to
implement support to either NAPTR or TXT records.
The following drawbacks were identified for this solution:
o For the UAs resolving the SIP(S) URI as specified in RFC 3263 it
is not clear which SRV records should the NAPTR query "SIP+D2x"
return. A specific server might appear in both _sip and _sipo SRV
records for the domain or only in one of them. If the NAPTR query
returns both records the server might appear twice in the response
and further on any UA looking for SIP Outbound should discard the
unwanted SRV records before proceeding with address records. But
if the NAPTR query does not return both types of SRV records then
it could cause problems for UAs wanting to use the specific
service that is not returned. Thus the result is that
additionally to introducing naming conventions for SRV records,
also new NAPTR service types would be needed, to complete the
solution for UAs using NAPTR queries.
o The naming conventions for SRV records can be considered as name
hacks, like mentioned in RFC 3958 [9].
Koivusalo Expires December 18, 2006 [Page 9]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
2.4.3. New string for DNS TXT records
A proposal was done to introduce a string like "sip-outbound" to be
used within DNS TXT records and associate such records with the SRV
records used for SIP servers of a domain, if they support SIP
Outbound. Further on it was proposed to specify a new "t" flag for
SRV records as a hint for the DNS server to return all the associated
TXT records as additional information when responding to a SRV query.
The main benefit of this solution, in comparison to using NAPTR
records, is that it avoids the combinatorial explosion problem. Any
new property indicated via DNS TXT records is just a discrete string
that can be added, regardless of whether the same record contains or
does not contain any other strings.
However the following drawbacks were identified for this solution:
o DNS TXT records were found as a very generic means of passing any
kind of information to clients. As such, no standardized
solutions exist relying on TXT records, which was the biggest
reason not to promote a solution based on TXT records for SIP
Outbound. In a few cases TXT records have been specified as a
fallback solution, when the DNS server would not yet support
certain new types of DNS RRs (DKIM, SPF). On the other hand
introducing new types of DNS RRs for SIP Outbound is not feasible
as the nature of information is a single boolean flag.
o If the server does not understand or obey the new "t" flag of SRV
RR, then the UA has to separately query the TXT records for every
SRV record it tries to use. This might lead to multiple TXT RR
queries before the target hosts supporting SIP Outbound have
finally been located.
o When indicating the support for SIP Outbound with TXT records,
there is no built-in way for the service provider to prevent the
clients of other service providers to resolve SIP URIs to proxies
supporting SIP Outbound, even if those should be used only as
outbound proxies for the clients of the service provider. It was
however proposed that the priority field of SRV records could be
used for this purpose, so that the servers for inbound traffic
would have the lowest priority value.
2.4.4. No standardized autodiscovery
If no autodiscovery mechanism is used, the UA can locate the proxy
with the conventional SIP proxy discovery procedure as described in
RFC3263 [2]. After locating a proxy the UA can compose a REGISTER
request and send it towards the discovered proxy. If the proxy does
Koivusalo Expires December 18, 2006 [Page 10]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
not support the required extensions it can reject the request or
redirect the UA to try another proxy.
Drawbacks of this solution are as follows:
o There is at least one extra round-trip for redirection if the
discovered proxy did not support SIP Outbound. If the proxy does
not redirect but instead rejects the REGISTER, then the UA can
only blindly try the next proxy returned by DNS.
o There is no way for the UA to automatically find another proxy
towards which a secondary flow could be formed. UA could be
configured with different domain names for the primary and
secondary flow, but this solution would not apply in the case
where UA finds the proxy by DHCP SIP Server option.
o If the UA would try to find a proxy for the secondary flow amongst
the servers located with SRV queries but without knowing which of
those would support SIP Outbound, then any such server trying to
redirect the request would only complicate the matter more. The
reason to this is that the server is likely to redirect the UA to
use the same proxy towards which the primary flow is already set
up.
Further on, if no DNS services are standardized for SIP Outbound,
service providers might use various methods to differentiate their
proxy farms. These techniques could use proprietary prefixes for DNS
SRV records or different domain names for different farms. In all
cases the UA would need some extra configuration information to find
out how DNS has been set up and how it should be used when locating
outbound proxies.
Koivusalo Expires December 18, 2006 [Page 11]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
3. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7].
Koivusalo Expires December 18, 2006 [Page 12]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
4. New NAPTR Service types
The values for NAPTR service field indicating a proxy supporting SIP
Outbound are "SIP-O+D2U", "SIP-O+D2T", "SIPS-O+D2T", "SIP-O+D2S" and
"SIPS-O+D2S". The value "SIP-O" or "SIPS-O" in the service_field of
NAPTR record will indicate proxies supporting SIP Outbound, while the
rs field indicates supported transport protocols using values as
defined in RFC 3263 [2]. This document establishes a new IANA
registry for those NATPR service names. NAPTR records using those
new service types MUST provide a mapping from a domain to the SRV
record. The corresponding SRV records MUST indicate SIP servers
supporting SIP Outbound and the specific transport protocol in the
NAPTR services field.
Koivusalo Expires December 18, 2006 [Page 13]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
5. User Agent Mechanisms
The procedures here are invoked when a UA needs to send a REGISTER
request via a proxy supporting SIP Outbound and set up a persistent
flow towards that proxy. The starting point is that the UA has a SIP
or SIPS (secure SIP) URI of the proxy without port, transport or
maddr parameters as the next hop. According to RFC 3263 [2] the UA
"SHOULD perform a NAPTR query for the domain in the URI." This
specification assumes the UA would proceed to perform the NAPTR query
and related SRV queries as specified in RFC 3263, but with the
exceptions defined below.
As per RFC 2915 [4], the client discards any NAPTR records whose
services fields are not applicable. A client resolving a SIPS URI
MUST discard any services that do not contain "SIPS-O" as the
protocol in the service field. A client resolving a SIP URI MUST
retain records with "SIP-O" and the transport protocols the client
supports and SHOULD retain records with "SIPS-O", if the client
supports TLS.
The UA MUST be able to create and maintain two redundant flows.
Whether the UA actually sets up one single flow or two redundant
flows, is determined in the following ways:
o When the network responds to the primary REGISTER with 200 OK, the
response may contain an indication telling the maximum number of
flows the network expects the UA to use. The UA SHOULD create two
flows if the indicated value is at least two or if the network
does not give the indication at all. [[OPEN: the details of this
indication are still to be defined but are not in scope of this
spec]]
o The UA MAY have a configuration setting to force the UA to use
only one single flow or to enable it to use multiple flows. By
default multiple flows SHOULD be enabled so that the UA would
create multiple flows if the network does not deny it.
Section "Usage rules" of RFC 2782 [5] describe how to sort the
retrieved SRV records and select the most preferred one amongst
those. The UA MUST use those rules of RFC 2782 for determining the
target host towards which it will create the primary flow when
sending the REGISTER request.
If the UA aims to create an additional secondary flow and determine
the corresponding target host automatically for the same domain, but
the UA has only one single SIP(S) URI available for the proxy, the UA
MUST use the following logic:
Koivusalo Expires December 18, 2006 [Page 14]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
o If the domain has only one SRV record with SIP Outbound support
(for the protocol the UA aims to use) it means only a single proxy
server is available, possibly with multiple IP addresses. In this
case the UA MUST not try creating another flow.
o If the domain has multiple SRV records for SIP Outbound support
(for the protocol the UA aims to use) and all of those RRs have
the same Priority value it means the service provider is doing
load balancing between those servers, using the Weight field of
the SRV records to split the total load of multiple UAs amongst
those servers. In this case the the same set of servers is used
both for load balancing and reduncancy. The UA MUST create the
secondary flow towards a target host, which is found by applying
the "Usage rules" of RFC 2782 [5] for a subset of those SRV
records. The subset is created from the set of SRV records with
SIP Outbound support, but excluding the RR of the target towards
which the UA created its primary flow and all the RRs which the UA
tried to contact for the primary flow, but without success.
o If the domain has multiple SRV records for SIP Outbound support
(for the protocol the UA aims to use) with different Priority
values it means the service provider has reserved a separate proxy
farm as idle backup servers, just for redundancy. There might be
multiple servers having the lowest Priority value for load
balancing, but dedicted servers with higher Priority value are
allocated for backup flows. The UA MUST create the backup flow
towards a target host, which is found by applying the "Usage
rules" of RFC 2782 [5] for a subset of those SRV records. The
subset is created from the set of SRV records with SIP Outbound
support, but excluding all the RR which have the Priority value
lower or equal of that RR towards which the UA created the primary
flow.
The UA should use its two flows for requests outside of dialogs as
follows:
o If the Priority values of the SRV records used for the two flows
were same, the UA MAY either use only one of the flows for all the
non-REGISTER requests it sends or distribute those requests
equally to both the flows. The UA MUST be prepared to receive
incoming requests from both the flows. In this case the flows do
not have any specific primary and backup status but the UA uses
them equally.
o If the Priority values of the SRV records for the primary and
backup flow were different, the UA MUST only use one flow at a
time for non-REGISTER requests. As long as the primary flow is
alive, the UA SHOULD send only REGISTER refresh and flow keepalive
Koivusalo Expires December 18, 2006 [Page 15]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
requests over the backup flow. If the primary flow fails, the UA
MUST use the backup flow for all request types it sends via the
outbound proxy, until the UA is able to reconnect the primary flow
again.
Note that the UA MUST route the mid-dialog requests as specified in
draft-ietf-sip-outbound [8].
When performing NAPTR queries as specified in this document, if the
UA is not able to resolve the URI of the proxy successfully to any IP
address or if connecting to each of the resolved addresses fails,
then the UA MAY try resolving the URI using the procedures defined in
RFC 3263 [2]. When doing this fallback UA MUST NOT assume the
resolved target host to support SIP Outbound.
Koivusalo Expires December 18, 2006 [Page 16]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
6. Examples
As an example, consider a UA that wishes to resolve sip:example.com.
The client performs a NAPTR query for that domain, and the following
NAPTR records are returned:
; order pref flags service regexp replacement
IN NAPTR 90 50 "s" "SIP-O+D2T" "" _sip._tcp.ob.example.com
IN NAPTR 100 50 "s" "SIP-O+D2U" "" _sip._udp.ob.example.com
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
The UA will discard NAPTR records with "SIP+D2T" and "SIP+D2U"
services. For the two NAPTR records indicating SIP Outbound support
the one with TCP protocol is the preferred one. Consequently the UA
will perform an SRV lookup of _sip._tcp.ob.example.com. This spec
gives two examples for what that SRV query would return.
Case 1: Domain _sip._tcp.ob.example.com has SRV records with
different Priority values as follows:
;; Priority Weight Port Target
IN SRV 0 3 5060 server1.example.com
IN SRV 0 1 5060 server2.example.com
IN SRV 1 1 5060 server3.example.com
There are two priority levels amongst the returned SRV records. In
this example both server1.example.com and server2.example.com have
the lowest priority values and the UA will select one of them for the
primary flow as described in the "Usage rules" of RFC 2782 [5].
Server1.example.com becomes selected and the UA connects to it while
sending the REGISTER request. When selecting the target host for
backup flow the UA will apply the "Usage rules" of RFC 2782 [5] to a
subset of SRV records, having higher Priority value than
Server1.example.com. Only server3.example.com is available for the
backup flow. The UA will keep alive the flows towards both of those
two proxies, however only the primary flow towards
server1.example.com will be used for any non-REGISTER requests as
long as the primary flow is alive. If the primary flow fails the UA
starts sending requests towards server3.example.com.
Case 2: Domain _sip._tcp.ob.example.com has SRV records with same
Priority values as follows:
;; Priority Weight Port Target
IN SRV 0 3 5060 server1.example.com
IN SRV 0 2 5060 server2.example.com
IN SRV 0 2 5060 server3.example.com
Koivusalo Expires December 18, 2006 [Page 17]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
IN SRV 0 2 5060 server4.example.com
All the returned SRV records have same Priority value. At first the
UA will select the server for the primary flow according to "Usage
rules" of RFC 2782 [5]. In this example the UA selects
server1.example.com for this purpose and sends a REGISTER for it.
However server1.example.com is down and does not respond.
Consequently UA tries another server, this time e.g.
server3.example.com and creates the primary flow towards it. While
selecting the target host for the secondary flow the UA will apply
the "Usage rules" of RFC 2782 [5] to a subset of SRV records,
consisting of server2.example.com and server4.example.com.
Server1.example.com was excluded as not responding and
server3.example.com due to already being used for the primary flow.
Finally the UA will create the secondary flow towards e.g.
server4.example.com. The UA will maintain flows towards both of
those two proxies and may use either of the flows for sending and
receiving SIP requests.
Koivusalo Expires December 18, 2006 [Page 18]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
7. IANA Considerations
This document instructs IANA to register the following values in the
"Registry for the NAPTR Resource Record Services Field":
Services Field Protocol Reference
SIP-O+D2U UDP RFCXXX
SIP-O+D2T TCP RFCXXX
SIPS-O+D2T TCP RFCXXX
SIP-O+D2S SCTP RFCXXX
SIPS-O+D2S SCTP RFCXXX
[[Note to IANA and the RFC Editor: Replace RFCXXX with the RFC number
assigned to this specification]].
Koivusalo Expires December 18, 2006 [Page 19]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
8. Security Considerations
DNS NAPTR records are used to allow a client to discover that the
server supports SIP Outbound. An attacker could potentially modify
these records, resulting the client to send STUN request to a proxy
that does not support STUN requests in its SIP port. This kind of
attack could cause the proxy to behave in an unpredictable way and
might cause it to crash.
This kind of attack is prevented by a mechansim introduced within
draft-ietf-sip-outbound [8]. When sending REGISTER request, the UA
has to add an option tag to it, requiring the proxy to reject the
request if it does not support SIP Outbound.
[[Author's note: the mechanism to be used within REGISTER request is
still to be decided. After the decision is made the text above must
be rewritten.]]
Other relevant security considerations have already been covered
within RFC 3263 [2].
Koivusalo Expires December 18, 2006 [Page 20]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
9. Acknowledgments
The author would like to thank Jeroen van Bemmel, Miguel Garcia,
Michael Hammer, Juha Heinanen, Hadriel Kaplan and Fredrik Thulin for
their useful comments.
Koivusalo Expires December 18, 2006 [Page 21]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
10. References
10.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream
Control Transmission Protocol (SCTP) as a Transport for the
Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[4] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-03 (work in progress), March 2006.
10.2. Informative References
[9] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[10] Camarillo, G., "Compressing the Session Initiation Protocol
(SIP)", RFC 3486, February 2003.
Koivusalo Expires December 18, 2006 [Page 22]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
Author's Address
Erkki Koivusalo
Nokia
Valimotie 9
Helsinki, 00380
Finland
Phone: +358 40 757 1197
Email: erkki.koivusalo@nokia.com
Koivusalo Expires December 18, 2006 [Page 23]
Internet-Draft Proxy Discovery for SIP Outbound June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
