DISPATCH WG H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: April 13, 2010 October 13, 2009 Session Initiation Protocol (SIP) Domain Registration draft-kaplan-dispatch-domain-registration-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 13, 2010. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kaplan Expires April 1, 2009 [Page 1] Internet-Draft SIP Domain Registrations October 2009 Abstract This document defines a means of providing reachability information for a domain of SIP AoR's using a SIP REGISTER method transaction, and defines a SIP option-tag for indicating such. Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. Introduction................................................3 3.1. Benefits of using REGISTER.............................4 4. Domain Registration Mechanism...............................4 4.1. Overview of the Mechanism..............................4 4.2. User Agent Behavior....................................5 4.2.1 Generating the REGISTER Request 5 4.3. Registrar Behavior.....................................6 4.3.1 Processing the REGISTER Request 7 4.3.2 Routing SIP Requests 7 5. Examples....................................................9 5.1. Example-1: Registrar only..............................9 5.2. Example-2: Registrar with Proxy.......................11 6. Security Considerations....................................14 7. Alternatives...............................................15 8. IANA Considerations........................................15 9. Acknowledgments............................................15 10. Normative References.......................................15 11. Informative References.....................................16 Author's Address.................................................16 1. Introduction The SIP protocol, as defined in [RFC3261] and its extensions, supports multiple means of resolving the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP Proxy needs to send a request to a target address-of-record (AoR) within its domain, it can use a location service to resolve the Registered Contact URI, and potentially any Path information attached to it per [RFC3327], to build a route set to reach the target UA(s). When a SIP UA or Proxy needs to send a request to a target which is scoped in a domain for which it is not authoritative, the UA/Proxy can use [RFC3263] procedures for using DNS to resolve the next-hop connection information. It is not uncommon, however, to use REGISTER requests to provide the reachability information for such cases, even for AoR's and domains outside of the local SIP domain. This draft defines the behavior of such a mechanism, coined "Domain Registration". Kaplan Expires - April 2010 [Page 2] Internet-Draft SIP Domain Registrations October 2009 2. Definitions For brevity's sake, this document uses the word "request" instead of "out-of-dialog request", but in all cases means out-of-dialog requests. AoR: address-of-record, as defined by RFC 3261: a URI by which the user is canonically known (e.g., on their business cards, in the From header field of their requests, in the To header field of REGISTER requests, etc.). SIP Domain: An administrative domain for which the authority is responsible for handling SIP application service of its AoR's, such as providing voicemail and intra-Domain routing. This may not actually be a separate "Domain Name" in the DNS sense; it may just be an IP Address. Domain Name: An explicit identifier which defines a separate scope of authority, following the syntax and semantics of DNS. Domain Registration: providing SIP Domain reachability information through REGISTER transactions. Domain Resolution Table (DRT): a logical lookup table in the Registrar, which is updated by REGISTER requests based on the mechanism in this document, and used for request routing purposes to reach the Registered SIP Domain in lieu of [RFC3263] procedures. Reachability Information: a set of URI's identifying the host and path of Proxies to reach that host; like any URI, these URI's may identify the specific connection transport, IP Address, and port information, or they may only identify FQDN's. SSP: SIP Service Provider, as defined by [RFC5486]. 3. Introduction In some environments, notably the Small-to-Medium Business (SMB) market, SIP devices in the Enterprise are effectively IP-PBX's, receiving Primary Rate Interface (PRI) type SIP trunk services from a SIP Service Provider (SSP). The SIP IP-PBX device is authoritative for its local domain of AoR's. Even if the IP-PBX has its own Domain Name, not every small business owner has a DNS, or has the technical capability to provision DNS entries (e.g., SRV's) appropriately in their DNS, or has the ability to do so through any third party which hosts their domain name(s), or has the wish to make their SIP device address known publicly. Kaplan Expires - April 2010 [Page 3] Internet-Draft SIP Domain Registrations October 2009 Furthermore, the SMB may not have its own Domain Name at all, and instead merely has an IP Address. Because a single SSP may support multiple thousands of such SMB IP- PBX's, it is impractical and cost-prohibitive to manually provision their IP Addresses in every SIP node along the path which needs to reach the SMB IP-PBX customer. Instead, a dynamic reachability mechanism is needed. Such a mechanism already exists for SIP: the REGISTER transaction. A REGISTER request transaction provides dynamic reachability information for an AoR's authoritative domain. Since a REGISTER request mechanism is generally supported by most SIP Service Providers' equipment, it has become common practice for small IP-PBX's to use the mechanism as a means of providing their reachability information. In some cases interoperability problems have arisen, due to differing expectations and implementations of how such a mechanism should work in practice. 3.1. Benefits of using REGISTER Using a REGISTER request transaction for providing reachability information has several benefits: . It alleviates the Enterprise from having a SIP signaling address publicly viewable in DNS. . It enables mechanisms that make the SIP device publicly reachable even if a NAT exists between the device and the Service Provider network. . It avoids having to statically provision the path from the Service Provider core through edge proxies per Enterprise, because the Path header field can be used. . It allows the SIP Service Provider to give the SIP device a pre-loaded route set for subsequent requests, using the Service-Route header field per [RFC3608]. . It provides a periodic keep-alive mechanism, in order to detect service outages, and service restoration. . It is an existing SIP request method type, known to be supported by most SIP devices. . It is conceptually similar to the Registration behavior model in RFC 3261. 4. Domain Registration Mechanism 4.1. Overview of the Mechanism In a Domain Registration model, the SIP UA (i.e., an IP-PBX) Registers a single mutually agreed-upon Domain name; this Domain Kaplan Expires - April 2010 [Page 4] Internet-Draft SIP Domain Registrations October 2009 name might not be publicly useable or resolvable in DNS, and may only exist for the purpose of this mechanism. The SIP UA Registers the SIP Domain Name that it is authoritative for, to a Registrar of another SIP Domain for which it is not authoritative, such as that of a SIP Service Provider (SSP). The Contact URI it Registers, along with any Path header field information, represents the reachability information used to route subsequent requests from the SSP to the SIP UA, for the Registered Domain Name. Unlike typical SIP Registrations in [RFC3261], the Domain Registration does not update a location service database for a SIP AoR, but rather updates a logical Domain Resolution Table which provides external Domain routing resolution - similar to a host file. This table is queried prior to DNS lookup procedures in [RFC3263], and used in lieu of such DNS procedures if a matching entry is found. The SIP Domain Name being Registered MUST be globally unique. If there are multiple IP-PBX's of the same Enterprise Domain Name, each one MUST Register a SIP URI having the same Domain Name, but with unique user portions. The Domain Name may be a subdomain of the SSP's Domain Name, or it may be a completely separate Domain Name. The Registered Domain Name itself is technically under the Enterprise's authority. 4.2. User Agent Behavior 4.2.1 Generating the REGISTER Request The target request-uri of the REGISTER request MUST be the Domain Name of the SSP or a Registrar host name of the SSP, as allowed per [RFC3261] section 10.2.6, which allows the Registrar address to be in a separate Domain from the one being Registered. The To and From URI's of the REGISTER request MUST contain the Domain Name being Registered, in a SIP URI format. The URI MUST have a user portion, to uniquely identify the IP-PBX. A SIPS URI MUST NOT be used for the To/From URI of the REGISTER. This does not preclude using TLS for the entire path between the UA and the Registrar, nor does it preclude using SIPS URI's for AoR's of other SIP requests to or from the Registering SIP UA. For a SIPS scheme to be usable, the Domain Registration would have had to have been sent over a transport which SIPS allows (e.g., TLS), but the Domain Registration is registering reachability information for a Domain and not for a particular AoR, and thus the URI being Kaplan Expires - April 2010 [Page 5] Internet-Draft SIP Domain Registrations October 2009 Registered does not limit the scheme which can be used to route through it later. The REGISTER request MUST contain one and only one Contact URI, which MUST be the transport connection reachability address information for reaching the UA. If a UA/IP-PBX has multiple connection paths it can be reached through (e.g., multiple transports or multiple interfaces), each one MUST be Registered separately, in separate REGISTER transactions with their individual respective Contact URI's. The Contact header field of the REGISTER request MAY contain a 'q' q-value parameter to indicate a relative preference for this particular reachability information, as defined in [RFC3261] section 20.10. Note that only a single Contact URI is allowed in a single REGISTER request based on this document's mechanism, and thus the q- value is relative to all REGISTERs for the same Domain Name. The default q-value, if not explicitly indicated, is 0.5. The Contact header field MUST contain an 'expires' parameter, indicating how long the Contact URI is valid, as defined in [RFC3261]. The procedures in [SIP-Outbound] SHOULD be followed, if both the SIP UA and the SSP support Outbound. Using Outbound procedures does not change the fundamental behavior of the mechanism described in this document; it only provides additional procedures and fields for Registering multiple flows using identifiers, with specific keep- alive mechanisms and timers. The REGISTER request MUST contain the new 'dreg' option-tag in a Require header field. This option-tag indicates the mechanism identified in this document is being used to Register a SIP Domain. 4.3. Registrar Behavior This document uses a logical "Domain Resolution Table" (DRT) residing in the Registrar, for the purpose of describing the behavior of the mechanism in this document. Specific implementations need not follow this data structure, so long as they maintain the same logical external behavior. The DRT is indexed by the SIP Domain name being Registered, with one or more result entries, one for each Registered Contact URI. Each entry identifies the route set necessary to reach the Registered Domain, including the Contact URI and any Path header field information per [RFC3327]. Each entry also identifies a q-value for prioritizing among multiple entries for the same Domain name. Kaplan Expires - April 2010 [Page 6] Internet-Draft SIP Domain Registrations October 2009 4.3.1 Processing the REGISTER Request If a matching SIP Domain Name is found and the Contact URI being Registered matches one already in the DRT, the REGISTER updates the entry. Note that other information in the REGISTER request such as Path header field information, q-value, or expires value, may be different and need to replace previously stored result values in the DRT. If a matching SIP Domain Name is found and the Contact URI being Registered does not match any already in the DRT, the Registrar MUST add the Contact URI as a new result entry. Any received Path header field information MUST be added as a route set in the DRT entry. If a q-value is received, it MUST be added as well, otherwise the default q-value of 0.5 MUST be used. Example DRT: ----------------------------------------------------------------- | Domain Name | Result ----------------------------------------------------------------- |example.org | Contact-URI: sip:pbx-100@192.0.2.4:6000 | | Path-info: | | Q-Value: 0.5 | | Expires: 3600 ----------------------------------------------------------------- |corp.ssp.example.net | Contact-URI: sip:admin@192.0.2.5 | | Path-info: sip:cookie@p1.ssp.example.net;lr | | Q-Value: 1.0 | | Expires: 3600 | |------------------------------------------ | | Contact-URI: sip:admin@192.0.4.2:7000 | | Path-info: sip:p2.ssp.example.net;lr | | Q-Value: 0.3 | | Expires: 3600 ----------------------------------------------------------------- 4.3.2 Routing SIP Requests If the SSP receives a SIP request containing a Request-URI that identifies the Domain of the SIP UA/IP-PBX and not the SSP, then SSP MUST NOT replace the Request-URI with the Registered Contact URI. If the Request-URI identifies the Domain of the SSP and the request is retargeted or local policy indicates the request belongs to the Domain of the SIP UA/IP-PBX, then the request-URI's host portion MUST be changed to the Domain Name of the UA/IP-PBX. Kaplan Expires - April 2010 [Page 7] Internet-Draft SIP Domain Registrations October 2009 For example, if a UA such as "pbx.example.com" Registers itself to "ssp.example.net", then the Request-URI of SIP requests sent to the SSP with a domain portion of pbx.example.com will remain unchanged. In practice, however, it is likely that SIP request sent to the SSP will be based on phone numbers and have a domain portion of ssp.example.net. Since the SSP is authoritative for ssp.example.net, it will change the domain portion of the Request- URI to be pbx.example.com. When routing the request to the external SIP Domain, the local Proxy performs a query to the Domain Resolution Table prior to performing [RFC3263] procedures (before a NAPTR query), using the target SIP Domain name for the lookup. If a matching Domain Name with reachability information is found, the entry is used in lieu of DNS procedures. Otherwise, if no matching entries are found, then [RFC3263] procedures are followed. If multiple matching entries are found, for example due to multiple Registered Contact URI's for the same Domain Name, then the q-value of each Registered Contact URI MUST be used to select the route set. The highest q-value is selected first, and only if it fails is the next highest one attempted, and so on. If a matching entry is found, a Route header field(s) MUST be inserted with the value of the Registered reachability information, after any other Route header field values generated from local policies. Note this is any received Path URI's, and the entire Registered Contact URI, including any userinfo portion, URI parameters, and embedded headers. As per [RFC3327], the created Route header field values would be based on the Registered Path URI list in received order, with the Registered Contact URI appended as the last and final entry. A loose-route 'lr' URI parameter MUST be added to the Registered Contact URI when it is inserted in the Route header field value. Kaplan Expires - April 2010 [Page 8] Internet-Draft SIP Domain Registrations October 2009 5. Examples The following sections provide example cases of the mechanism defined in this document. Each example includes more than one concept being shown at the same time. The first example shows a single Registrar-Proxy case, with the Enterprise's SIP Domain name being unrelated to the Registered-to SSP's Domain name, an implicit q-value, and an initial INVITE request targeted to the SSP's Domain which is retargeted to the Enterprise's Domain. The second example shows a separate edge-Proxy before the Registrar, with the Path header field mechanism being used, the Registered SIP Domain name being a sub-domain of the SSP's Domain name, an explicit q-value, and an initial INVITE request targeted to Enterprise's Domain. 5.1. Example-1: Registrar only As an example, assume the following scenario: UA1----REG-----UA2 The node marked UA1 is the Registering IP-PBX of domain "corp.example.com"; REG is a registrar and a proxy, and serves as the authoritative proxy for ssp.example.net; and UA2 is another UA trying to reach a user of UA1. Note that some header fields (e.g., Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. Message sequence for REGISTER: F1 Register UA1 -> REG REGISTER sip:ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;expires=3600 Require: dreg . . . Kaplan Expires - April 2010 [Page 9] Internet-Draft SIP Domain Registrations October 2009 E2 REG executes Register REGISTRAR Stores in Domain Resolution Table: For domain "corp.example.com": Contact: sip:pbx-100@192.0.2.4:6000 Q-Value: 0.5 Expires: 3600 F3 200 Register response REG -> UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: ;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;expires=3600 Supported: path, dreg . . . Message sequence for INVITE to UA1: F1 Invite UA2 -> REGISTRAR INVITE sip:+12125551212@ssp.example.net;user=phone SIP/2.0 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: From: UA2 ;tag=224497 Call-ID: 48273181116 CSeq: 29 INVITE Contact: . . . E2 REGISTRAR processing REGISTRAR looks up name "+12125551212" and finds an entry for an external domain "corp.example.com" belonging to UA1; subsequent modified [RFC3263] location query for "corp.example.com" resolves to a Registered Domain reachability information of: Contact: REGISTRAR performs route set creation based on this document's mechanism, resulting in a route set of: Route: Kaplan Expires - April 2010 [Page 10] Internet-Draft SIP Domain Registrations October 2009 F3 Invite REGISTRAR -> UA1 INVITE sip:+12125551212@corp.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Route: To: From: UA2 ;tag=224497 Call-ID: 48273181116 CSeq: 29 INVITE Contact: . . . 5.2. Example-2: Registrar with Proxy As an example, assume the following scenario: UA1----P1-----REG-----UA2 The node marked UA1 is the Registering IP-PBX; P1 is the SSP's edge proxy; REG is a registrar and a proxy, and serves as the authoritative proxy for ssp.example.net; and UA2 is another UA trying to reach a user of UA1. In this example, the Registering Domain is "corp.ssp.example.net", a sub-domain of the SSP domain "ssp.example.net". Note that some header fields (e.g. Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. Message sequence for REGISTER with Path: F1 Register UA1 -> P1 REGISTER sip:ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Require: dreg . . . F2 Register P1 -> REG REGISTER sip:ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Kaplan Expires - April 2010 [Page 11] Internet-Draft SIP Domain Registrations October 2009 Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Require: dreg Path: . . . Note: P1 has added itself to the Path. E3 REG executes Register REGISTRAR Stores in Domain Resolution Table: For domain "corp.ssp.example.net": Contact: sip:admin@192.0.2.5 Path: Q-Value: 1.0 Expires: 3600 F4 200 Register response REG -> P1 SIP/2.0 200 OK Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: ;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Supported: path, dreg Path: . . . F5 200 Register response P1 -> UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: ;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Supported: path, dreg Path: . . . Kaplan Expires - April 2010 [Page 12] Internet-Draft SIP Domain Registrations October 2009 Message sequence for INVITE to UA1: F1 Invite UA2 -> REGISTRAR INVITE sip:+12125551212@corp.ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: From: UA2 ;tag=224497 Call-ID: 48273181116 CSeq: 29 INVITE Contact: . . . F2 REGISTRAR processing REGISTRAR is not authoritative for "corp.ssp.example.net" (the domain in the request URI), so performs DRT lookup query for "corp.ssp.example.net", which resolves to a Registered Domain reachability information of: Contact: sip:admin@192.0.2.5 Path: REGISTRAR performs route set creation based on this document's mechanism, resulting in a route set of: Route: , F3 Invite REGISTRAR -> P1 INVITE sip:+12125551212@corp.ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Route: , To: From: UA2 ;tag=224497 Call-ID: 48273181116 CSeq: 29 INVITE Contact: . . . Kaplan Expires - April 2010 [Page 13] Internet-Draft SIP Domain Registrations October 2009 F4 Invite P1 -> UA1 INVITE sip:+12125551212@corp.ssp.example.net SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R Route: To: From: UA2 ;tag=224497 Call-ID: 48273181116 CSeq: 29 INVITE Contact: . . . 6. Security Considerations Performing SIP Registration for Domains has security implications beyond those inherent in plain AoR Registrations. With AoR Registrations, the potential exists for illegitimate devices to receive SIP requests for an AoR they are unauthorized to receive; but with Domain Registration, a worst-case scenario would have an illegitimate device receiving all requests for an entire Domain, which is a far larger scope. Furthermore, a Man-in-the-Middle (MitM) need only be able to intercept and modify the REGISTER request from the SIP UA to the SSP in order to subsequently receive all SIP requests to the Domain. A Domain Registration is performed by a SIP UA sending a REGISTER request to the SSP, which then causes all SIP Requests to follow the Registered reachability information (Contact and Path), and thus MitM interception in one direction easily enables interception in the other. For example, since the Path URI information is not, and cannot be, authenticated by the SSP, all the MitM has to do is insert a Path URI of itself in the REGISTER request, in order to receive all requests in the other direction. This is weaker than previous SIP routing behavior using DNS, since the SSP would have followed the DNS information, which could have been protected, or at least required additional work for a MitM. Therefore, it is strongly recommended that TLS be used between the Registering SIP UA and its Registrar/Proxy, so that a MitM cannot insert itself in the SIP Request routing path. Kaplan Expires - April 2010 [Page 14] Internet-Draft SIP Domain Registrations October 2009 7. Alternatives [Note to RFC Editor: Please remove this "Alternatives" section prior to publication] There are no currently defined IETF-based alternatives this author is aware of to perform dynamic reachability notification for the scenarios described in this document, other than DNS Dynamic Update (RFC 2136). It is unknown if any vendors actually use DDNS Update for this purpose, but many devices are known to use SIP REGISTER transactions for a purpose very similar (but not identical) to the one in this document. There are several advantages to using SIP for providing the reachability information, but it is beyond the scope of this document to enumerate them. Clearly DNS by means of [RFC3263] is assumed to be the "normal" way of performing resolution of reachability information when a SIP request crosses Domains, assuming they are of different Domain Names. However it is not clear if the market actually aligns with that belief. Some vendors use (and some people have argued for) other SIP method transactions to perform the same thing, for example using an OPTIONS request or even an out-of-dialog NOTIFY. I believe the closest semantic would actually be a PUBLISH request, to publish reachability information. (Effectively the logical equivalent of Dynamic-DNS Updates) However, since REGISTER already has the necessary semantic, and is widely supported, this author is not sure what advantage using a different Method name really provides. 8. IANA Considerations This document requests IANA to reserve a SIP option tag named "dreg", for the purposes described in this document. 9. Acknowledgments Thanks to Cullen Jennings, John Elwell, Richard Shockey, Alan Johnston, Spencer Dawkins, Chris Gatch, Jack Burton, Brian Lindsey, Glenn Russell, Bernard Aboba, David Hancock, David Middleton, Jamie Palmer, and Shaun Bharrat for their input into this document. 10. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Kaplan Expires - April 2010 [Page 15] Internet-Draft SIP Domain Registrations October 2009 Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [sip-outbound] Jennings, C. and Mahy, R., "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-20, June 2009. 11. Informative References [RFC3608] Willis, D., and Hoeneisen, B., "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - April 2010 [Page 16]