DISPATCH WG H. Kaplan Internet Draft Acme Packet Intended status: Standards Track D. Hancock Expires: June 19, 2010 CableLabs J. Elwell Siemens Enterprise December 19, 2009 Session Initiation Protocol (SIP) Implicit Registrations draft-kaplan-martini-shaken-implicit-registrations-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 19, 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 19, 2010 [Page 1] Internet-Draft SIP Implicit Registrations December 2009 Abstract This document defines a mechanism for providing reachability information for multiple AoRs using a single SIP REGISTER method transaction. Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. Background Discussion.......................................3 3.1. The Need for Implicit Registration......................4 3.2. Benefits of using REGISTER..............................5 4. Implicit Registration Mechanism.............................5 4.1. Overview of the Mechanism...............................5 4.2. Administrative Responsibility of AoRs...................6 4.3. User Agent Behavior.....................................6 4.3.1 Generating the REGISTER Request.......................6 4.4. Registrar Behavior......................................7 4.4.1 Processing the REGISTER Request.......................7 4.4.2 Routing SIP Requests..................................8 5. Examples....................................................9 5.1. Example-1: Registrar only...............................9 5.2. Example-2: Registrar with Proxy........................11 6. IANA Considerations........................................14 7. Acknowledgments............................................14 8. Informative References.....................................14 Authors' Addresses...............................................15 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 UA or Proxy needs to send a request to a target which is scoped in a domain for which it is not authoritative/responsible, the UA/Proxy can use [RFC3263] procedures for using DNS to resolve the next-hop connection information. When a UA/Proxy needs to send a request to a target address-of-record (AoR) within its domain, it can use its 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). It is not uncommon, however, to use REGISTER requests to provide the reachability information for such cases, even for AoRs and domains the REGISTER request does not explicitly identify it is registering Kaplan Expires - June 2009 [Page 2] Internet-Draft SIP Implicit Registrations December 2009 for. This draft defines the behavior of such a mechanism, coined "Implicit Registration". This authors know of at least four organizations using this type of model: the SIP Forum, ETSI, 3GPP, and CableLabs. 2. Definitions For brevity's sake, this document uses the word "request" instead of "out-of-dialog request", but in all cases this term means out-of- dialog request. 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). Domain Name: An explicit identifier which defines a separate scope of authority, following the syntax and semantics of DNS. Explicitly Registered AoR: A mutually agreed-upon AoR used for the REGISTER transaction, identified in the To-URI of the REGISTER request. Implicit Registration: implicitly providing the reachability information for something other than the AoR indicated in the Register transaction. 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 FQDN's. SSP: SIP Service Provider, as defined by [RFC5486]. 3. Background Discussion In some environments, notably the Small-to-Medium Business (SMB) market, SIP devices in the Enterprise are effectively IP-PBX's, behind which are other devices (including SIP devices) supporting individual users within the Enterprise. The SIP IP-PBX receives Primary Rate Interface (PRI) type SIP trunk services from a SIP Service Provider (SSP). The SIP IP-PBX device is authoritative for its local AoRs and uses Implicit Registration to provide reachability information to the SSP for those AoRs. In SIP, there is an assumption that AoRs of a given SIP Domain are under the authority of that Domain, and it alone has the right and responsibility to provide SIP services for those AoRs, such as call- Kaplan Expires - June 2009 [Page 3] Internet-Draft SIP Implicit Registrations December 2009 forwarding, forking, fallback to voicemail, etc. When a SIP UA registers an AoR, it is actually claiming authority/responsibility for that AoR. Likewise, when a SIP UA (e.g., a SIP IP-PBX) performs an Implicit Registration, it is actually claiming authority/responsibility for the set of AoRs it is implicitly Registering for. 3.1. The Need for Implicit Registration Even if the SMB 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. In many cases, DNS resolution would not be sufficient to route requests to the SMB, because specific SIP Proxies need to be traversed to reach the SMB. 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 method. A REGISTER request 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 SIP 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. Kaplan Expires - June 2009 [Page 4] Internet-Draft SIP Implicit Registrations December 2009 3.2. Benefits of using REGISTER Using a REGISTER request for providing reachability information has several benefits: . It alleviates the Enterprise from having a SIP signaling address publicly viewable in DNS. . It provides 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 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. Implicit Registration Mechanism 4.1. Overview of the Mechanism In an Implicit Registration model, the SIP UA (i.e., an IP-PBX) Registers using a single, mutually agreed-upon, Address-of-Record (AoR). The Contact URI it Registers for that AoR, 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 AoR and any implicitly registered AoRs. The REGISTER transaction creates a real SIP Registration per [RFC3261], and updates a location service database for the SIP AoR being Registered as well as other mutually agreed-upon AoRs. The mechanics of routing out-of-dialog requests to the AoRs, however, is different from "normal" Registration-based location service resolution routing. In particular, in order for the UA to determine which AoR is being targeted by a request, the request-URI is not replaced by the Registered Contact-URI; instead the Contact- URI is inserted as a loose-route Route header field value, along with any stored Path information. Kaplan Expires - June 2009 [Page 5] Internet-Draft SIP Implicit Registrations December 2009 4.2. Administrative Responsibility of AoRs In an Implicit Registration model, the SIP UA (i.e., an IP-PBX) is technically authoritative for its explicitly and implicitly Registered AoRs. What this means is that a request from one AoR of the IP-PBX targeted for another AoR of the same IP-PBX would be routed locally within the IP-PBX, directly to the other AoR. This implies that UAs behind the IP-PBX need to Register reachability information for their AoRs with the SIP IP-PBX, so that they can be reached from the SIP-PBX. If they were to Register their reachability information with the SSP instead, they would not be reachable from within the IP-PBX, only from the SSP. By registering with the IP-PBX, which in turn uses implicit registration to register their AoRs with the SSP, those UAs can be reached either from within the IP-PBX or from the SSP (via the IP-PBX). 4.3. User Agent Behavior 4.3.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. The To and From URIs of the REGISTER request MUST contain the mutually agreed-upon explicit AoR to be Registered, in a SIP or SIPS URI format. The URI MUST have a user portion, to uniquely identify the IP-PBX. Note that using a SIP URI instead of a SIPS URI for the AoR does not preclude using TLS for the entire path between the UA and the Registrar, nor does it preclude using SIPS URIs for the explicit or implicit AoRs in other SIP requests to or from the Registering SIP UA. For a SIPS scheme to be usable, the Implicit Registration would have to be done over a transport which SIPS allows (e.g., TLS). The To header field MUST contain a new "multi" header parameter, with the value "true". This indicates the AoR being Registered may not be the only AoR being registered, and that instead the mechanism defined in this document is being used. A new option-tag defined later in this document will require the Registrar to support this new parameter. The REGISTER request MUST contain one and only one Contact URI, which MUST be the transport connection reachability address information for reaching the UA/IP-PBX. If a UA/IP-PBX has multiple Kaplan Expires - June 2009 [Page 6] Internet-Draft SIP Implicit Registrations December 2009 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 REGISTER requests for the same UA/IP-PBX. 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 Contact URI MUST contain an "lr" URI parameter, indicating the URI is used as a loose-route. The option-tag defined for this mechanism later is used to require the Registrar to support this parameter in the Contact URI. 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 'implicit' option-tag in a Require header field. This option-tag indicates the Registrar must support the mechanism identified in this document to process the Register request successfully. In particular, it will require the Registrar to detect the "lr" URI parameter in the Contact URI which indicates the Contact URI is a loose-route for the AoR being Registered, and detect the "multi=true" To header field parameter. 4.4. Registrar Behavior This document uses the same logical location service database concept of [RFC3261] 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. 4.4.1 Processing the REGISTER Request All REGISTER processing rules for Registrars defined in section 10.3 of [RFC3261] apply, except as noted herein. Kaplan Expires - June 2009 [Page 7] Internet-Draft SIP Implicit Registrations December 2009 When receiving a REGISTER request with a Require header field containing "implicit", and the Registrar supports this extension, and assuming valid authentication, the Registrar MUST check the To header field for the new "multi" parameter. The procedures below apply only if this parameter is present and has the value "true". The "multi=true" parameter indicates the AoR being Registered may not be the only AoR being Registered, and that one or more mutually pre-agreed-upon AoRs will also be Registered with the reachability information of this REGISTER request. In such a case, each location service database entry for the set of mutual agreed-upon AoRs is updated with the reachability information (Contact and Path) and q- value of the received REGISTER request. If a matching entry is found in the database and the Contact URI being Registered does not match any already in the database for the entry, the Registrar MUST add the entry as a serial-forking entry only. Parallel forking to multiple contacts of the same AoR does not make sense in an SSP-to-IP-PBX model. If a q-value is received, it MUST be added as well, otherwise the default q-value of 0.5 MUST be used. The q-value affects the serial forking decision for multiply registered Contacts. The Registrar MUST indicate support for this mechanism by inserting the new "implicit" option-tag in a Supported header field, and by keeping the "multi=true" To-header parameter, in the REGISTER response. The Registrar SHOULD indicate all of the implicitly Registered AoRs in a P-Associated-URI header field(s) in the 200 response to the REGISTER, if it supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? Should we document a legal/compliant means of indicating AoR username "wildcards"?] 4.4.2 Routing SIP Requests If the SSP receives a SIP request containing a Request-URI that identifies an AoR registered either explicitly or implicitly using a REGISTER request with "multi=true" in the To header field, then the SSP MUST NOT replace the Request-URI with the Registered Contact URI. Instead, 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 the Registered reachability information comprises 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 Kaplan Expires - June 2009 [Page 8] Internet-Draft SIP Implicit Registrations December 2009 Registered Path URI list in received order, with the Registered Contact URI appended as the last and final entry. If multiple matching entries are found, for example due to multiple Registered Contact URIs for the same explicit AoR, then the q-value of each Registered Contact URI MUST be used to select the route set for serial forking. The highest q-value is selected first, and only if it fails is the next highest one attempted, and so on. 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, where there are no implicit AoRs. The second example shows a separate edge- Proxy before the Registrar, with the Path header field mechanism being used and an explicit q-value, with one implicit AoR. Both examples show a REGISTER transaction and an initial INVITE request. 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; 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: ;multi=true From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;expires=3600 Require: implicit . . . Kaplan Expires - June 2009 [Page 9] Internet-Draft SIP Implicit Registrations December 2009 E2 REG executes Register REGISTRAR Stores in location service database: For AoR "pbx1234@ssp.example.net": Contact: sip:pbx-100@192.0.2.4:6000;lr Q-Value: 0.5 Expires: 3600 No other AoRs are implicitly Registered. F3 200 Register response REG -> UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7 To: ;multi=true;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;expires=3600 Supported: path, implicit . . . Message sequence for INVITE to UA1: F1 Invite UA2 -> REGISTRAR INVITE sip:pbx1234@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: . . . E2 REGISTRAR processing REGISTRAR looks up name "pbx1234" for its domain, and finds an entry belonging to UA1: Contact: REGISTRAR performs route set creation based on this document's mechanism, resulting in a route set of: Route: Kaplan Expires - June 2009 [Page 10] Internet-Draft SIP Implicit Registrations December 2009 F3 Invite REGISTRAR -> UA1 INVITE sip:pbx1234@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: . . . 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, there are implicitly registered AoRs. 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: ;multi=true From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Require: implicit . . . 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 Kaplan Expires - June 2009 [Page 11] Internet-Draft SIP Implicit Registrations December 2009 To: ;multi=true From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Require: implicit Path: . . . Note: P1 has added itself to the Path. E3 REG executes Register REGISTRAR Stores in location service database: For AoR "pbx1234@ssp.example.net": Contact: sip:pbx-100@192.0.2.4:6000;lr Path: Q-Value: 1.0 Expires: 3600 For (implicit) AoR "+12125551212@ssp.example.net": Contact: sip:pbx-100@192.0.2.4:6000;lr 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: ;multi=true;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Supported: path, implicit Path: P-Associated-URI: . . . Kaplan Expires - June 2009 [Page 12] Internet-Draft SIP Implicit 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: ;multi=true;tag=12345 From: ;tag=456248 Call-ID: 843817637684230 CSeq: 1826 REGISTER Contact: ;q=1.0;expires=3600 Supported: path, implicit Path: P-Associated-URI: . . . 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: . . . F2 REGISTRAR processing REGISTRAR looks up name "+12125551212" for its domain, and finds an entry belonging to UA1: Contact: sip:admin@192.0.2.5;lr Path: Q-Value: 1.0 REGISTRAR performs route set creation based on this document's mechanism, resulting in a route set of: Route: , Kaplan Expires - June 2009 [Page 13] Internet-Draft SIP Implicit Registrations December 2009 F3 Invite REGISTRAR -> P1 INVITE sip:+12125551212@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: . . . F4 Invite P1 -> UA1 INVITE sip:+12125551212@ssp.example.net;user=phone 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. IANA Considerations This document will request IANA for a new SIP option-tag named "implicit", for the purpose defined herein; a new header field parameter named "multi" with a single value of "true", as defined previously; and to update the applicability of the "lr" URI parameter to apply to the Contact URI. 7. Acknowledgments Thanks to a whole bunch of people to be named later. 8. Informative 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. Kaplan Expires - June 2009 [Page 14] Internet-Draft SIP Implicit Registrations December 2009 [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. [RFC3455] Garcia-Martin, M., Henrikson, E., and Mills, D., "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. [RFC3608] Willis, D., and Hoeneisen, B., "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. Authors' Addresses Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: d.hancock@cablelabs.com John Elwell Siemens Enterprise Communications Email: john.elwell@siemens-enterprise.com Kaplan Expires - June 2009 [Page 15]