DISPATCH WG H. Kaplan Internet Draft Acme Packet Intended status: Informative Expires: June 19, 2010 December 19, 2009 SIP IP-PBX Registration Problems draft-kaplan-martini-mixing-problems-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 18, 2010 [Page 1] Internet-Draft SIP IP-PBX Registration Problems December 2009 Abstract This document identifies several known issues with current IP-PBX Registration mechanisms. Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. Background on Current Mechanisms............................3 4. Issues with the REGISTER Transaction........................4 4.1. No Explicit Indicator..................................4 4.2. Undefined Behavior on PAU Mismatch.....................4 4.3. REGISTER Response Growth...............................5 4.4. Illegal Wildcarding Syntax.............................5 5. Issues with Routing Requests................................5 5.1. Loss of Target Info....................................5 5.2. Request-URI vs. Loose-Route Mismatches.................5 5.3. Request-URI Mis-routing................................5 6. Other Related Issues........................................6 6.1. Authorization Policy Mismatches........................6 6.2. P-Asserted-Identity URI Mismatches.....................6 6.3. Trust Domain Mismatches for Privacy/Identity...........6 7. IANA Considerations.........................................6 8. Informative References......................................7 Author's Address..................................................7 1. Introduction In many deployed SIP Service Provider (SSP) architectures, it is common to use REGISTER requests to provide the reachability information for IP-PBXs, instead of DNS-based resolution and routing. There are many SIP IP-PBXs which support SIP Registration model into the SSP, however the behavior and syntactic details of the REGISTER transaction and subsequent routing of requests to/from the IP-PBX differ among vendors, which has led to interoperability and operational problems. Furthermore, two separate Standards Development Organizations, 3GPP and ETSI, have defined mechanisms for doing so, but few IP-PBXs support their exact mechanisms in practice; and the 3GPP/ETSI defined mechanisms have their own issues. The SIP-Forum SIP-Connect 1.0 profile also introduced the concept of Registering IP-PBXs, but without sufficient detail for interoperability. This draft attempts to enumerate the issues found in the field, and the issues with the proposed mechanisms in 3GPP and ETSI. The goal Kaplan Expires - June 18, 2010 [Page 2] Internet-Draft SIP IP-PBX Registration Problems December 2009 of this draft is to make the issues known, in order to work on an IETF defined solution. 2. Definitions For brevity's sake, this document uses the word "request" instead of "out-of-dialog request", but in all case 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, etc.). Implicit Registration: implicitly providing the reachability information for something other than the AoR indicated in 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 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 on Current Mechanisms It is not the intention of this document to reproduce the work of other standards bodies, and the reader is encouraged to review the documents produced by those bodies. A short summary of the general concept is as follows: In virtually all models, the IP-PBX generates a SIP Registration request using a mutually agreed-upon SIP AoR - typically its main attendant/reception-desk number. The AoR is almost always in the Domain of the SSP, and both the To and From URIs used for the REGISTER request identify that AoR. In all respects, it appears on the wire as a "normal" first-party SIP UA REGISTER request, as if from a typical UA subscriber. For both 3GPP and ETSI mechanisms, the 200 OK response to the REGISTER, sent after successful authentication challenge, contains a P-Associated-URI listing the other SIP or TEL URI Identities (i.e., phone numbers) of the IP-PBX, which are implicitly Registered AoRs. Each of these AoRs will use the same Registered Reachability Information from the REGISTER request of the explicitly Registered AoR. In order to reduce the number of P-Associated-URI entries, a "wildcard" syntax model is defined, which uses a Regular Expression syntax in the user field of the URI to express multiple AoRs. Kaplan Expires - June 18, 2010 [Page 3] Internet-Draft SIP IP-PBX Registration Problems December 2009 For routing requests for any of the explicit or implicitly Registered AoRs from the SSP to the IP-PBX, the Request-URI is typically replaced with the Registered Contact-URI. In the case of 3GPP and ETSI, the SSP has the option of using loose-routing instead, and inserting the Registered Contact-URI as a loose-route Route header field value while leaving the Request-URI alone. This decision is made based upon manually provisioned information in the Registrar Database (i.e., the HSS). 4. Issues with the REGISTER Transaction 4.1. No Explicit Indicator None of the currently available mechanisms indicate the REGISTER request or response is any different from a "normal" REGISTER. This has caused issues when middleboxes between the IP-PBX and Registrar employ different policies for IP-PBXs vs. subscriber UAs, if the same middlebox SIP interfaces (IPs/FQDNs) are used for the different services. Furthermore, some middleboxes expect the Registrar to follow normal [RFC3261] procedures of Request-URI replacement with the Registered Contact-URI for routing subsequent requests to the IP-PBX, and will fail to route the requests correctly, because there is no indication the Registration was any different. Lastly, lack of Implicit Registration indication makes troubleshooting more difficult because the on-the-wire messages are indistinguishable from "normal" Registrations. Note that even the existence of a P-Associated-URI in the response does not indicate Implicit Registration for an IP-PBX has occurred, since the PAU header is used for subscriber UAs with multiple Identities. 4.2. Undefined Behavior on PAU Mismatch There is no defined behavior for the IP-PBX if the P-Associated-URI list of URIs does not match what the IP-PBX expects it to be. It is not clear if the IP-PBX should de-Register, re-Register, or ignore the difference; nor is there a way for the IP-PBX to indicate the error in signaling. Kaplan Expires - June 18, 2010 [Page 4] Internet-Draft SIP IP-PBX Registration Problems December 2009 4.3. REGISTER Response Growth If an IP-PBX represents many AoRs, the P-Associated-URI list in the response can grow the SIP message size beyond the limits for UDP. 4.4. Illegal Wildcarding Syntax The current syntax for "wildcarded" P-Associated-URIs is illegal for TEL URIs, based on the ABNF rules for TEL URIs. 5. Issues with Routing Requests 5.1. Loss of Target Info If the Proxy-Registrar follows [RFC3261] for Registration resolution of requests targeted to one of the IP-PBX's AoRs, and thus replaces the Request-URI with the Registered Contact-URI, it is not clear which AoR the intended target of the request is. The To-URI, for example, may not contain the intended target AoR if the request was forwarded/retargeted prior to reaching the Registrar. Some middleboxes between the Registrar and IP-PBX will overwrite the request-URI specifically to try to fix this issue. In some cases, a P-Called-Party-ID will contain the intended target AoR, if it's used; and in some cases the History-Info will contain it, if both the SSP and IP-PBX support it and the IP-PBX can determine which History-Info value to use. 5.2. Request-URI vs. Loose-Route Mismatches Some IP-PBXs expect that inbound SIP requests from the SSP will have the Registered Contact-URI in the Request-URI, and thus not interoperate with the loose-route scheme of 3GPP and ETSI. Other IP-PBXs are fine with the Request-URI being the intended target, but cannot handle receiving a Route header identifying their Registered Contact-URI as a loose-route entry. 5.3. Request-URI Mis-routing Although many IP-PBXs support a Registration mechanism to an SSP, they do not consider themselves authoritative for the explicitly or implicitly Registered AoRs if the domain portion still identifies the SSP's domain. They expect the domain portion to be their own IP Address, FQDN, or Domain. Currently middleboxes have to fix that issue. Kaplan Expires - June 18, 2010 [Page 5] Internet-Draft SIP IP-PBX Registration Problems December 2009 6. Other Related Issues 6.1. Authorization Policy Mismatches Many SSPs perform a first-order level of authorization for requests from the IP-PBX by checking the URI in the From, P-Asserted- Identity, or P-Preferred-Identity header fields for one matching either an explicitly or implicitly Registered AoR for the same Contact-URI and/or Layer-3 IP Address. If no match is found, the request is rejected. However, some IP-PBXs change the Contact-URI they use for Requests to be different from the one they explicitly Registered. For example they change the user portion of the Contact-URI, or even the host portion. 6.2. P-Asserted-Identity URI Mismatches Some SSPs expect the P-Asserted-Identity or P-Preferred-Identity URI in SIP requests received from the IP-PBX to match one of the explicitly or implicitly Registered AoRs, whereas some IP-PBXs generate the URIs using their local IP Address, Hostname, or Domain Name. This triggers request rejection or P-Asserted-Identity overwriting. Some SSPs expect the P-Asserted-Identity or P-Preferred-Identity URI in SIP requests received from the IP-PBX to be the explicitly Registered AoR only, as it is the main billing number, instead of the implicitly Registered AoR of the calling party. 6.3. Trust Domain Mismatches for Privacy/Identity In many cases, the Trust Domain model for Privacy is asymmetric in SSP-to-IP-PBX relationships: the SSP expects to be trusted by the IP-PBX, but does not trust the IP-PBX; whereas some IP-PBXs expect the SSP equipment to trust their domain as peers. For example, some IP-PBXs expect to send a P-Asserted-Identity in requests to the SSP, whereas some SSP equipment expects to receive P-Preferred-Identity instead. Another example is many SSPs allow the IP-PBX to anonymize Privacy-requested SIP Requests, expecting to receive the private originating AoR in the P-Asserted-Identity or P- Preferred-Identity header field, but do not themselves pass on the PAI to the IP-PBX for SIP requests to the IP-PBX. 7. IANA Considerations This document makes no request of IANA. Kaplan Expires - June 18, 2010 [Page 6] Internet-Draft SIP IP-PBX Registration Problems December 2009 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. [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. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - June 18, 2010 [Page 7]