DISPATCH WG H. Kaplan Internet Draft Acme Packet Intended status: Informational Expires: January 5, 2010 July 5, 2009 Session Initiation Protocol (SIP) Implicit Registrations draft-kaplan-dispatch-sip-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 January 5, 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. Abstract This document identifies several approaches to provide reachability information for a domain or multiple AoR's using a single SIP REGISTER method transaction, in ways not originally envisioned or documented by RFC 3261. Kaplan Expires January 1, 2009 [Page 1] Internet-Draft SIP Implicit Registrations July 2009 Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. Applicability...............................................4 4. Background Discussion.......................................4 5. Problems being solved by Implicit Registrations.............4 5.1. The Need for Associated-AoR Registration................5 5.2. The Need for Domain Registration........................5 5.3. Additional Benefits of using REGISTER...................6 6. How Registration and Request-Routing Works..................6 6.1. Associated-AoR Registration Mechanism...................6 6.2. Domain Registration Mechanism...........................7 7. Compliance with RFC 3261....................................8 8. Potential Problems with the Mechanisms......................8 9. Alternatives................................................9 10. IANA Considerations........................................10 11. Acknowledgments............................................10 12. Informative References.....................................10 Appendix A: Background of SIP URI Authority Model................11 Author's Address.................................................12 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 AoR's and domains the REGISTER request does not explicitly identify it is registering for. The way this is being performed is arguably in compliance with RFC 3261, though perhaps not in spirit. This draft attempts to provide the rationale for and behavior of such mechanisms, to raise awareness and avoid issues with future SIP extensions. Kaplan Expires - January 2009 [Page 2] SIP Implicit Registrations July 2009 This author knows of at least three organizations using this type of model: the SIP Forum, ETSI, and 3GPP. They do not use the mechanism the same way, but in all cases it is not necessarily obvious to the IETF community that it is being done, why, or how. 2. Definitions For clarity's sake, this document defines two different forms of Implicit Registrations: "Domain Registration", which Registers the reachability information for a separate Domain of SIP authority, and "Associated-AoR Registration", which Registers multiple AoR's through one Register transaction. For brevity's sake, this document uses the word "request" instead of "out-of-dialog request", but in all case 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). Domain: A SIP administrative domain for which the authority of the Domain 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 a collection of AoR's of another Domain Name, that the local device is fully responsible for. 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. Associated-AoR Registration: providing alternate AoR reachability information through REGISTER transactions. Implicit Registration: performing either Domain or Associated-AoR Registration; in other words, implicitly providing the reachability information for something other than the AoR of the Register transaction. 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 Kaplan Expires - January 2009 [Page 3] SIP Implicit Registrations July 2009 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. Applicability This draft is related to RFC 3261, RFC 3263, and RFC 3327. 4. Background Discussion Although the two forms of Implicit Registration (Associated-AoR Registration and Domain Registration) appear to solve the same problems, they are different from a SIP service logic perspective. In SIP, there is an assumption that AoR's 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 AoR's, such as call-forwarding, forking, fallback to voicemail, etc. When a SIP UA performs an "Associated-AoR Registration", it is only providing reachability information for reaching the set of AoR's it is implicitly Registering for, but service responsibility remains with the AoR's Domain; whereas with a "Domain Registration", it is actually claiming authority/responsibility for the set of AoR's it is implicitly Registering for, using a different AoR it is not responsible for in the explicit REGISTER request. For a more lengthy background discussion on this topic, see Appendix A. From a traditional PSTN perspective, one can think of the *Associated-AoR Registration* model as registering UNI/line-numbers, but the service application logic continues to be handled by the SSP. This follows a traditional SOHO/residential subscriber or Centrex service model. Whereas a *Domain Registration* model is actually registering a NNI/PRI-type trunk, and the service applications are performed by the registering entity. This follows a traditional PBX trunk service model. 5. Problems being solved by Implicit Registrations The two different types of Implicit Registrations are driven by different needs, and by different organizations. The Associated-AoR Registration model was originally defined by 3GPP/ETSI, for use in their SIP deployments of mobile handsets and wireline subscribers. It has seen adoption in the general industry beyond purely IMS deployments. The Domain Registration model is done in two different ways: one way by 3GPP/ETSI which follows the mechanics of Associated-AoR Kaplan Expires - January 2009 [Page 4] SIP Implicit Registrations July 2009 Registration very closely; and in a different way by the SIP Forum for SIP-Connect v1.1, which arguably follows the mechanics of RFC 3261 more closely. This author makes no judgment as to which is better. SIP-Connect v1.1 is only now in Last-Call, but SIP-Connect v1.0 was fairly popular with an Implicit Registration model, and the 3GPP/ETSI model has seen adoption in the general industry beyond purely IMS deployments. 5.1. The Need for Associated-AoR Registration In some environments, SIP UA's (endpoints, mobile phones, etc.) are pre-provisioned with a single AoR. This AoR may not be publicly known, even by the owner of the UA, and indeed may not even be a publicly reachable AoR useful for any purpose other than communicating between the UA and its Registrar, and any Proxies along that path. In such a case, the UA only knows to Register its single/private AoR, and is given other AoR's it can use for other requests, during the Registration process; for example they may be sent in P-Associated-URI header field(s) in the successful response to its REGISTER request, as defined in [RFC3455]. Furthermore, a single SIP device may represent multiple AoR's as distinct UA instances. For example a multi-line IAD, multi-line phone, IP-Centrex system, trading-floor console, etc. In such environments, it is more efficient and scalable to Register a single AoR even if the UA knows of the other AoR's it represents. 5.2. The Need for Domain Registration In some environments, notably the Small-to-Medium Business (SMB) market, SIP devices in the Enterprise are effectively IP-PBX's, receiving PRI-type SIP trunk services from a SIP Service Provider (SSP). The SMB SIP device is authoritative for its local domain. 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 may not wish to make their SIP device address known publicly. Furthermore, the SMB may not have its own Domain Name at all, and the AoR's it is authoritative/responsible for may well share the same Domain Name as the SIP Service Provider it is receiving SIP Trunk service from. Because a single SSP may support multiple thousands of such SMB 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 customer. Instead, a dynamic reachability mechanism is needed. Kaplan Expires - January 2009 [Page 5] SIP Implicit Registrations July 2009 5.3. Additional 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 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. 6. How Registration and Request-Routing Works 6.1. Associated-AoR Registration Mechanism In an Associated-AoR Registration model, the SIP UA Registers a specific AoR it knows about, for example a private one pre- provisioned into the UA, or the lowest ordered one it knows about. It does not really matter which one it Registers, although the scheme for choosing it is usually known by both the UA and the SSP. The REGISTER request passes through zero or more Proxies, or Proxy- type intermediaries, which insert themselves in a Path header per [RFC3327]. The Registrar receives the REGISTER request, and after possibly challenging it and verifying the challenge-response, it adds the Contact URI and Path information to the location service database per RFC 3261 and 3327. It also adds the same registered Contact URI for other, implicitly associated AoR's. These implicitly linked AoR's are added to the successful response of the REGISTER request in one or more P-Associated-URI fields, per RFC 3455, to notify the UA of what other AoR's it may represent itself as in subsequent requests. The SIP UA does not explicitly Register these other AoR's - it continues to re-Register the original one based on normal RFC 3261 re-Registration procedures. Kaplan Expires - January 2009 [Page 6] SIP Implicit Registrations July 2009 For subsequent outbound requests from the Registered UA (other than REGISTER), the UA may use any one of the alternate AoR's in its From header field URI, but in common practice for ETSI and 3GPP it inserts the one it is making the request as in a P-Preferred- Identity header field URI. This URI is checked by one or more of the intermediaries, and replaced with a P-Asserted-Identity field of the same, if the UA is authorized to use the AoR. For subsequent inbound requests to the Registered UA, the request's Request-URI is replaced with the single (common) registered Contact- URI, regardless of which AoR the request is intended for. Since this would create an ambiguity as to the intended target, a P- Called-Party-ID header field is inserted with the URI identifying the actual intended target AoR for the request, per RFC 3455. A multi-line UA, therefore, receives a SIP request with the request- URI identifying its registered Contact, a P-Called-Party-ID identifying which local line to ring/alert, and a P-Asserted- Identity header field identifying the calling user (unless Privacy was invoked). 6.2. Domain Registration Mechanism The Domain Registration model works very similarly to the Associated-AoR Registration model. The details differ between SIP Forum's SIP-Connect v1.1 and ETSI/3GPP, but in both cases the basic goal is to provide reachability information, typically for IP-PBX's to an SSP. In ETSI/3GPP, a common or "default" AoR in the SSP's domain is used by the IP-PBX to Register, which is typically a real, publicly reachable AoR for the lowest numbered username (since the username is likely an E.164 number). Currently, the Registration and Routing mechanism for ETSI/3GPP follows exactly that of Associated-AoR Registration, including replacing the request-URI with the Registered Contact for inbound requests. The only substantive addition is the notion of a "wildcarded" P-Associated-URI (PAU) header value, which is a means of encoding a regular expression pattern into a URI, so that potentially hundreds of PAU header field values do not need to be included in the response to the REGISTER. (since a PBX can support a large number of AoR's) Note that technically, the syntax used for this wildcarded URI does not comply with the ABNF rules for Tel-URI, and may not comply with those for SIP-URI. [Question: is that possibly a good thing, because receivers of the wildcarded PAU need to understand the syntax for the concept to work?] In SIP-Connect v1.1, the IP-PBX also Registers a single, default AoR in the SSP's domain; but this AoR is likely not publicly useable, Kaplan Expires - January 2009 [Page 7] SIP Implicit Registrations July 2009 and may only exist for the purpose of the mechanism. The Registered AoR itself is technically under the SSP's authority. For inbound requests to the IP-PBX, the SSP does NOT replace the Request-URI with the Registered Contact; instead, a Route header field is inserted with the value of the Registered Contact URI, after any other Route header field values from local policies or Registered Path(s). There is no explicit support for the P-Associated-URI header field mechanism in SIP-Connect, nor the P-Called-Party-ID. As a side note, although not documented in SIP-Connect v1.1: in practice, if the IP-PBX actually is its own separate Domain Name, then the SSP will most likely change the Request-URI's host portion to match the Domain Name of the IP-PBX, because in practice the Domain Name of the original Request-URI would have been the SSP's Domain Name, and thus needs to be re-targeted. Such is also the case if the IP-PBX uses an IP Address instead of a Domain Name for its AoR(s), which is not rare. 7. Compliance with RFC 3261 The mechanisms described in this document arguably comply with RFC 3261 in the following ways: 1) RFC 3261 allows local policies to override DNS-based resolution of next-hops, and routing in general. Section 16.6 of RFC 3261 step 7 states: "The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI." It recommends this local policy route be inserted as a Route header, instead of replacing the request-URI. The SIP-Connect profile uses such a local policy mechanism to route requests to IP-PBX's when they perform a Domain Registration. The Registration is for a specific AoR of the SP, which just happens (by no coincidence) to cause an update to the local policies for Proxy routing purposes. 2) RFC 3261 uses Registrations to provide a means of determining AoR reachability, including from third parties. It specifically allows a third party to add a binding for another device's AoR and Contact-URI. In this vein, one could claim that Associated- AoR Registrations are simply a form of third party Registration, whereby a single AoR is used as an alias for many others. 8. Potential Problems with the Mechanisms The mechanisms are implicit - there is no explicit indication in the REGISTER request that the Registration and subsequent routing behavior are any different from "normal" Registrations. This is typically not an issue, since the Registrar, Proxy, and UA's are aware of the mechanisms. It does pose some operational management Kaplan Expires - January 2009 [Page 8] SIP Implicit Registrations July 2009 challenges when multiple mechanisms are being used simultaneously by the same SSP Registrar and Proxy. Another potential issue is that after a wide-area power or service outage, if all SIP devices power back up in a relatively short time window, a large volume of Registrations can occur. This is known as an "Avalanche re-start" in industry parlance. Note that any keep- alive mechanism, such as OPTIONS request transactions, would have the same Avalanche re-start issue. Although the REGISTER transaction is ostensibly for the purpose of providing reachability information alone, it is common practice for SSP's to reject any other out-of-dialog requests until a device has successfully Registered. Such is already known to be the case for Implicit Registrations, and is expected to be true for Domain Registrations. Since Registrations are used as both a reachability and authorization policy mechanism, during an Avalanche re-start event some SIP UA's will not be able to successfully send outbound SIP requests for a longer period of time, simply because of the SSP's Registration processing rates. This may actually be a desirable property, however, to avoid asymmetric/partial service behavior. 9. Alternatives 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. Clearly DNS 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 concurs 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. Kaplan Expires - January 2009 [Page 9] SIP Implicit Registrations July 2009 10. IANA Considerations This document makes no request of IANA. 11. Acknowledgments Thanks to Cullen Jennings for asking me to write this up. 12. 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. [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. Kaplan Expires - January 2009 [Page 10] SIP Implicit Registrations July 2009 Appendix A. Background of SIP URI Authority Model In SIP, there is an assumption that there is a single logical authority for a given SIP Domain and Domain Name. It may be implemented in multiple physical nodes in a distributed fashion, but ultimately they represent a single logical function under the control of a single administrative policy. When SIP requests are processed by this logical function, it decides whether to invoke specific SIP actions, such as forking, re-targeting, fallback to voicemail, etc. In the most common case, SIP UA's such as softclients, phones, IAD's, IM clients, etc., do not have the authority to perform these functions themselves for any target URI other than the one identifying only themselves *and* which they received a request for. The second conjunctive is important: even if a SIP UA represents two AoR's in the SSP's Domain, it must treat requests for them separately, as if it were logically two separate SIP UA's. Any internal routing between the two AoR's must actually be passed back to the SSP to perform, as the SSP is authoritative for its Domain, and the Domain Name is part of the AoR. For example, imagine a SIP UA identified as "agent.com" Registers itself in SSP Domain "ci.vt.com" for the AoR's "Bob@ci.vt.com" and "Bing@ci.vt.com", using the Contact URI's "hope@agent.com" and "crosby@agent.com". If the UA receives a request for "Bob@ci.vt.com", it should not alert Bing, even if the UA has an internal forwarding policy from Bob to "Bing@ci.vt.com". The reason for this is the SIP UA is not actually authoritative for "Bing@ci.vt.com", because it's not authoritative for "ci.vt.com" to begin with. Furthermore, it is not clear that such a SIP UA should even locally process a request targeted for "Bob@ci.vt.com" to begin with. It should actually reject such a request, or route it to ci.vt.com, depending on local policy. The UA should only locally process requests for agent.com. Per RFC 3261 registered AoR resolution rules, the UA will not actually be receiving a request targeted to "Bob@ci.vt.com" - the request would instead have the Registered Contact-URI ("hope@agent.com") in the Request-URI of the message; and since the UA *is* authoritative for that URI, it all works out. To understand why this is important, imagine "Bing@ci.vt.com" was actually reachable at multiple locations, of which "crosby@agent.com" is only one. If the UA internally forwarded requests for Bob to Bing, without sending the request back to ci.vt.com, Bing's other reachable hosts would never find out. Kaplan Expires - January 2009 [Page 11] SIP Implicit Registrations July 2009 One can think of this in an Email model: if you send an email to user@domain, it will go to the mail server of domain, even if the user resides locally on the same host sending the email; whereas if you send it to user@host, it would remain on the host (depending on the email application environment). With all of the above in mind, in an Associated-AoR Registration model, the AoR's being implicitly Registered are handled in this same vain: the UA is registering one or more additional AoR's which it itself is not authoritative for, giving them all a Contact-URI of itself which it is authoritative for. In a Domain Registration model, the UA performing the Registration is implicitly providing reachability information for a Domain Name or set of AoR's it *is* authoritative for - but doing so with a REGISTER request for an explicit AoR it is *not* authoritative for. For example, it could send a REGISTER for an AoR of "agent@ci.vt.com", which implicitly creates a local policy to route all requests for "agent.com" through the Registered Contact URI. Note that although the example uses Domain Names to make it easier to understand, in practice the Domain Name may be the same as the SSP's - it is a logical collection of AoR's for which the Registering UA is claiming authority/responsibility for, and that are actually being Registered in a Domain Registration model. In other words, "agent.com" may be claiming actual authority for "Bob@ci.vt.com" and "Bing@ci.vt.com". Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - January 2009 [Page 12]