MARTINI WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational February 10, 2010
Expires: August 14, 2010
Requirements for multiple address of record (AOR) reachability
information in the Session Initiation Protocol (SIP)
draft-ietf-martini-reqs-00.txt
Abstract
This document states requirements for a standardized SIP registration
mechanism for multiple addresses of record, the mechanism being
suitable for deployment by SIP service providers on a large scale in
support of small to medium sized PBXs. The requirements are for a
solution that can, as a minimum, support AORs based on E.164 numbers.
This work is being discussed on the martini@ietf.org mailing list.
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 August 14, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Elwell Expires August 14, 2010 [Page 1]
Internet-Draft Multiple AOR reachability in SIP February 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Desirables . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Elwell Expires August 14, 2010 [Page 2]
Internet-Draft Multiple AOR reachability in SIP February 2010
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261], together with its
extensions, supports multiple means of obtaining 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 obtain the registered contact URI(s), together
with any associated path information [RFC3327], and build a route set
to reach each target user agent (UA). The SIP REGISTER method can be
used to register contact URIs and path information. SIP-outbound
[RFC5626] enhances this mechanism to cater for UAs behind NATs and
firewalls. When a entity needs to send a request to a target for
which it is not authoritative, the entity can follow [RFC3263]
procedures for using the Domain Name System (DNS) to obtain the next-
hop connection information.
In practice, many small and medium-sized businesses use a SIP-PBX
that is authoritative for tens or hundreds of SIP AORs. This SIP-PBX
acts as a registrar/proxy for these AORs for clients hosted by the
SIP-PBX. UAs register with the SIP-PBX on behalf of the AORs
concerned. A SIP Service Provider (SSP) provides SIP peering/
trunking capability to the SIP PBX. The SIP-PBX must be reachable
from the SSP so that the SSP can handle inbound out-of-dialog SIP
requests targeted at these AORs, routing these requests to the SIP-
PBX for onward delivery to registered UAs.
Experience has shown that existing mechanisms are not always
sufficient to support SIP-PBXs for small/medium businesses. In
particular, RFC 3263 procedures are generally inappropriate, except
for some larger SIP-PBXs, for reasons described in
[I-D.kaplan-martini-mixing-problems]. In current deployments,
mechanisms for the dynamic provision of reachability information
based on the SIP REGISTER method are commonly used. However,
implementations of this mechanism vary in detail, leading to
interoperability issues between SIP-PBXs and SSPs, and the need for
equipment to support different variants.
This document states requirements for a standardized SIP registration
mechanism for multiple AORs, the mechanism being suitable for
deployment by SSPs on a large scale in support of small to medium
sized PBXs. The requirements are for a solution that can, as a
minimum, support AORs based on E.164 numbers. The ability to handle
other forms of AOR is outside the scope of this document, although a
solution that can handle other forms of AOR is not precluded if it
does not lead to significant additional complexity or a delay in
producing the standard.
Elwell Expires August 14, 2010 [Page 3]
Internet-Draft Multiple AOR reachability in SIP February 2010
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms address of record (AOR), proxy, REGISTER, registrar,
request and user agent (UA) are to be interpreted as described in
[RFC3261].
3. Requirements
The following are requirements of the mechanism.
REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking
arrangement with an SSP whereby the two parties have agreed on a set
of telephone numbers deemed to have been assigned to the SIP-PBX.
REQ2 - The mechanism MUST allow a set of assigned telephone numbers
to comprise E.164 numbers, which can be in contiguous ranges,
discrete, or in any combination of the two.
REQ3 - The mechanism MUST allow a SIP-PBX to register reachability
information with its SSP, in order to enable the SSP to route to the
SIP-PBX inbound requests targeted at assigned telephone numbers.
REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX
registering with the SIP-PBX on behalf of AORs based on assigned
telephone numbers in order to receive requests targeted at those
telephone numbers, without needing to involve the SSP in the
registration process.
REQ5 - The mechanism MUST allow a SIP-PBX to handle internally
requests originating at its own UAs and targeted at its assigned
telephone numbers, without routing those requests to the SSP.
REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its
assigned telephone numbers originating outside the SIP-PBX and
arriving via the SSP, so that the PBX can route those requests
onwards to its UAs, as it would for internal requests to those
telephone numbers.
REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows
which of its assigned telephone numbers an inbound request from its
SSP is targeted at.
REQ8 - The mechanism MUST provide a means of avoiding problems due to
Elwell Expires August 14, 2010 [Page 4]
Internet-Draft Multiple AOR reachability in SIP February 2010
one side using the mechanism and the other side not.
In other words, the mechanism is required to avoid the situation
where one side believes it is using the mechanism and the other
side believes it is not, e.g., the SIP-PBX believes it is
performing registration of multiple telephone numbers, but the SSP
believes a single AOR is being registered.
REQ9 - The mechanism MUST observe SIP backwards compatibility
principles.
In other words, the mechanism is required to provide a graceful
means of recovery or fall-back if either side does not support the
mechanism. For example, this might involve the use of an option
tag.
REQ10 - The mechanism MUST work in the presence of intermediate SIP
entities on the SSP side of the SIP-PBX-to-SSP interface (i.e.,
between the SIP-PBX and the SSP's domain proxy), where those
intermediate SIP entities need to be on the path of inbound requests
to the PBX.
These intermediate SIP entities can be edge proxies, session
border controllers, etc..
REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address
dynamically.
REQ12 - The mechanism MUST work without requiring the SIP-PBX to have
a domain name or the ability to publish its domain name in the DNS.
REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on
other domains, which are expected to be able to use normal RFC 3263
procedures to route requests, including requests needing to be routed
via the SSP in order to reach the SIP-PBX.
REQ14 - The mechanism MUST be able to operate over a transport that
provides integrity protection and confidentiality.
REQ15 - The mechanism MUST support authentication of the SIP-PBX by
the SSP and vice versa.
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with
public or temporary Globally Routable UA URIs (GRUUs).
REQ17 - The mechanism MUST NOT preclude the ability of the SIP-PBX to
route on-PBX requests directly, without hair-pinning the signalling
through the SSP.
Elwell Expires August 14, 2010 [Page 5]
Internet-Draft Multiple AOR reachability in SIP February 2010
4. Desirables
The following are desirable properties of the mechanism.
DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms
for providing SIP service to ordinary subscribers in order to provide
a SIP trunking service to SIP-PBXs.
DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand
assigned telephone numbers.
This will probably preclude any mechanism involving a separate
REGISTER transaction per assigned telephone number.
In practice, the mechanism is more likely to be used on PBXs with
up to a few hundred telephone numbers, but it is impossible to
give a precise limit, and hence the desire to be able to support
several thousand.
DES3 - The mechanism SHOULD scale to support several thousand SIP-
PBXs on a single SSP.
DES4 - The mechanism SHOULD require relatively modest changes to a
substantial population of existing SSP and SIP-PBX implementations,
in order to encourage a fast market adoption of the standardized
mechanism.
Ease of market adoption is paramount here. Many SIP-PBXs and SSPs
have implemented mechanisms based on the REGISTER method, and the
need for substantial changes to those implementations will
discourage convergence on a single standard in the foreseeable
future.
5. Non-requirements
The means by which a third domain can route a request to the SSP for
onward delivery to the SIP-PBX is outside the scope of this work.
This is related to REQ13, which requires normal routing based on RFC
3263 to be used.
Provisioning is outside the scope of this work. In particular, a SSP
will need to assign a set of numbers to a SIP-PBX, and a SIP-PBX will
need to be aware of the set of assigned numbers and allocate those
numbers to its users. Automated means for a SIP-PBX to obtain, from
its SSP, the set of assigned telephone numbers is considered to be a
provisioning topic.
Elwell Expires August 14, 2010 [Page 6]
Internet-Draft Multiple AOR reachability in SIP February 2010
6. IANA considerations
This document requires no IANA actions.
7. Security considerations
Security of signaling between the SIP-PBX and the SSP is important.
Some of the requirements above already address this.
In particular, it is important that an entity acting as a SIP-PBX
cannot register with an SSP and receive inbound requests to which it
is not entitled. The SSP is assumed to have procedures for ensuring
that a SIP-PBX is entitled to use a set of E.164 telephone numbers
prior to entering into agreement with that SIP-PBX for using those
telephone numbers with this mechanism. Furthermore, by
authenticating the SIP-PBX when it provides reachability information,
the SSP can be sure that it delivers inbound requests only to the
correct destination.
8. Acknowledgements
The contents of the document have been compiled from extensive
discussions within the MARTINI WG, the individuals concerned being
too numerous to mention.
9. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
Elwell Expires August 14, 2010 [Page 7]
Internet-Draft Multiple AOR reachability in SIP February 2010
(SIP)", RFC 5626, October 2009.
[I-D.kaplan-martini-mixing-problems]
Kaplan, H., "SIP IP-PBX Registration Problems",
draft-kaplan-martini-mixing-problems-00 (work in
progress), December 2009.
Author's Address
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 855608
Email: john.elwell@siemens-enterprise.com
Elwell Expires August 14, 2010 [Page 8]
