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.