Internet Draft H. Kaplan Intended status: Standards Track Acme Packet Expires: June 18, 2010 December 18, 2009 Session Initiation Protocol (SIP) Domain Registration draft-kaplan-martini-stirred-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 June 18, 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 June 18, 2010 [Page 1] Internet-Draft SIP Domain Registrations December 2009 Abstract This document defines a means of providing reachability information for a domain of SIP AoRs using a SIP REGISTER method transaction. Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. Introduction................................................3 3.1. Benefits of using REGISTER..............................4 4. Domain Registration Mechanism...............................5 4.1. Overview of the Mechanism...............................5 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..................................8 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 7.1. DDNS Update............................................15 7.2. Other SIP Methods......................................15 8. IANA Considerations........................................16 9. Acknowledgments............................................16 10. Normative References.......................................16 11. Informative References.....................................17 Author's Address.................................................17 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 AoRs and domains Kaplan Expires - June 2010 [Page 2] Internet-Draft SIP Domain Registrations December 2009 outside of the local SIP domain. This draft defines the behavior of such a mechanism, coined "Domain Registration". 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 AoRs, 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 URIs identifying the host and path of Proxies to reach that host; like any URI, these URIs may identify the specific connection transport, IP Address, and port information, or they may only identify FQDNs. 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 AoRs. 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 Kaplan Expires - June 2010 [Page 3] Internet-Draft SIP Domain Registrations December 2009 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. 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 AoRs 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. Kaplan Expires - June 2010 [Page 4] Internet-Draft SIP Domain Registrations December 2009 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 Address-of-Record (AoR) which has a Domain Name of the Enterprise; this Domain name might not reside in DNS, but MUST be a sub-domain belonging to the SSP which authorizes its use for 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 Registered Domain Name itself is technically under the Enterprise's authority for the purposes of processing SIP requests. 4.2. User Agent Behavior 4.2.1 Generating the REGISTER Request All procedures for constructing the REGISTER request defined in section 10.2 of [RFC3261] apply, with the additional constraints defined in this section. 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 URIs 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. Kaplan Expires - June 2010 [Page 5] Internet-Draft SIP Domain Registrations December 2009 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 URIs for AoRs 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 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 URIs. 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 Kaplan Expires - June 2010 [Page 6] Internet-Draft SIP Domain Registrations December 2009 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. 4.3.1 Processing the REGISTER Request All REGISTER processing rules for Registrars defined in section 10.3 of [RFC3261] apply, except it is not applied to a binding for an "address-of-record" but rather that of a Domain Name. 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. Kaplan Expires - June 2010 [Page 7] Internet-Draft SIP Domain Registrations December 2009 Example DRT: ----------------------------------------------------------------- | Domain Name | Result ----------------------------------------------------------------- |corp1.ssp.example.net| Contact-URI: sip:pbx-100@192.0.2.4:6000 | | Path-info: | | Q-Value: 0.5 | | Expires: 3600 ----------------------------------------------------------------- |corp2.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-URIs host portion MUST be changed to the Domain Name of the UA/IP-PBX. 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. Kaplan Expires - June 2010 [Page 8] Internet-Draft SIP Domain Registrations December 2009 If multiple matching entries are found, for example due to multiple Registered Contact URIs 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 URIs, 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. 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, using 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, 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.ssp.example.net"; 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 Kaplan Expires - June 2010 [Page 9] Internet-Draft SIP Domain Registrations December 2009 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 . . . E2 REG executes Register REGISTRAR Stores in Domain Resolution Table: For domain "corp.ssp.example.net": 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 Kaplan Expires - June 2010 [Page 10] Internet-Draft SIP Domain Registrations December 2009 REGISTRAR looks up name "+12125551212" and finds an entry for an external domain "corp.ssp.example.net" 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: F3 Invite REGISTRAR -> UA1 INVITE sip:+12125551212@corp.ssp.example.net;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 Kaplan Expires - June 2010 [Page 11] Internet-Draft SIP Domain Registrations December 2009 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 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: . . . Kaplan Expires - June 2010 [Page 12] Internet-Draft SIP Domain Registrations December 2009 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: . . . 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: , Kaplan Expires - June 2010 [Page 13] Internet-Draft SIP Domain Registrations December 2009 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: . . . 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 Kaplan Expires - June 2010 [Page 14] Internet-Draft SIP Domain Registrations December 2009 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. 7. Alternatives [Note to RFC Editor: Please remove this "Alternatives" section prior to publication] 7.1. DDNS Update 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 to the one in this document. 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. One of the reasons SIP REGISTER is used for providing reachability information is that DNS is actually not sufficient for current common usage of SIP. It is not the case that merely resolving a DNS domain name to an IP Address is sufficient to reach a device such as an IP-PBX across a SIP Trunk. In common usage of SIP, there are frequently one or more SIP middleboxes, such as SIP Proxies, which must be traversed from an SSP routing Registrar-proxy to the IP-PBX. This is one of the reasons the SIP Path mechanism in [RFC3327] was created. Furthermore, Small Business IP-PBX's are frequently deployed behind a NAT's, which requires not only discovering the public IP:port but also keeping the NAT pinhole open and binding active, for requests to reach the IP-PBX. SIP REGISTER requests have been used for that purpose for years, even before the explicit mechanism in [sip- outbound] was created to provide that, which still relies on a REGISTER request. 7.2. Other SIP Methods Some vendors use (and some people have argued for) other SIP method transactions to perform the same thing, for example using an OPTIONS Kaplan Expires - June 2010 [Page 15] Internet-Draft SIP Domain Registrations December 2009 request or even an out-of-dialog NOTIFY. The closest semantic would probably be a PUBLISH request, to publish reachability information. However, since REGISTER already has the necessary semantic, and is widely supported, it is not clear what advantage using a different Method name really provides. In particular, using any other SIP method than REGISTER will require re-creating the Path and NAT traversal capabilities provided by [RFC3327] and [sip-outbound] for the new method. And the additional capabilities provided from the Service-Route [RFC3608] and Registration Event Package [RFC3680] are useful as well, and are again tied to the REGISTER mechanism. Lastly, creating a new SIP method name, and new rules for such, is a significant barrier for market adoption. SIP REGISTER is already widely used by IP-PBX's to provide their reachability information to an SSP - it's just been through either proprietary means, or standardized by other SDO's. 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, Shaun Bharrat, Eric Turcotte, Dean Willis, Paul Kyzivat, and Jon Peterson for their comments and input into this document. 10. Normative References [RFC3261] 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. [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. Kaplan Expires - June 2010 [Page 16] Internet-Draft SIP Domain Registrations December 2009 [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. [RFC3680] Rosenberg, J. "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [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 - June 2010 [Page 17]