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.