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]