Session Initiation Protocol (SIP): single registration for Multiple Address of Record (AoR) reachabiliTy InformatioN, with FedeRated Intra ENterprise Domain name Setup
draft-vanelburg-martini-friends-00

Abstract

The Martini Working Group is defining a mechanism for SIP IP-PBX type devices to REGISTER and obtain SIP service for E.164-based Address of Records. In doing so it has selected a solution that is not compatible with the solution that was specified in ETSI TISPAN and 3GPP for subscription based business trunking. The latter solution not only covers E.164 numbers but also handles non-E.164 numbers and alphanumeric AOR's.

This document defines a extension of the martini mechanism that allows it to be used also with ETSI TISPAN and 3GPP standard subscription based business trunking arrangements.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on October 30, 2010.

Copyright Notice

Copyright (c) 2010 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 (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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
2.  Conventions
3.  Definitions
    3.1.  AOR
    3.2.  Alphanumeric SIP URI
    3.3.  Implicit Registration
    3.4.  Reachability Information
    3.5.  SSP
    3.6.  BC
    3.7.  domain federation
4.  Overview of the FRIENDS solution
    4.1.  The issue in short
    4.2.  Registration signalling
    4.3.  SSP Processing of Inbound Requests targeted at an implicitly registered AOR assigned to a bulk contact
5.  Security considerations
6.  IANA considerations
7.  Acknowledgments
8.  References
    8.1.  Normative references
    8.2.  Informative references
Appendix A.  Revision Information
    A.1.  version 00, MARTINI
§  Authors' Addresses

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. An IETF-defined mechanism for doing so is being worked on in the Martini Working Group, in [draft-gin].

The actual end users that are served by the IP-PBX will most likely register themselves with the IP-PBX, if that IP-PBX is connecting end users using the SIP protocol. This means that end users register with the IP-PBX so the IP-PBX knows where to reach them, additionally the IP-PBX will have registered with the SSP using a bulkcontact which allows the SSP to know where to reach end users that are assigned to that IP-PBX in the SSP systems.

Taking one step back and considering the normal SIP arrangement without any IP-PBX, in this case the usual setup in which SIP is used is that any user's AOR would be handled by a proxy that is responsible for handling requests for the domain indicated by the hostport portion of the AOR. Note that this does not imply exclusivity of this proxy instance as there may be a farm of cooperating proxies all handling requests for that same domain. The users registered individual reachability information with the proxy instance assigned during registration, which would then route incoming requests accordingly.

Fast forwarding again to the case where the IP-PBX provides reachability information to the SSP's proxy using a REGISTER request. The problem that martini is tasked to resolve is that current solutions like the one standardised by ETSI/3GPP or the ones specified by the SIP Forum lack an explicit indication during registration, this is reflected in the name of the work group "Multiple AoR reachabiliTy InformatioN Indication", a description can be found in [draft-ietf-martini-reqs].

The current proposed Martini mechanism described in [draft-ietf-martini-gin] only supports E.164-based AoR's, however in actual deployments private-extension or "local" numbers are used for hosted and carrier-provided intra-Enterprise calling services, and domain-scoped alphanumeric URIs may become more popular in the near future. Neither of these forms of AoRs are supported by the current Martini mechanism.

Furthermore the current martini routing mechanism provides a solution that is not compatible with the solution that is standardised in ETSI TISPAN and 3GPP for subscription based business trunking. That solution not only supports E.164 numbers but also handles non-E.164 numbers and alphanumeric AOR's.

The current martini mechanism described in [draft-ietf-martini-gin] is said to put less requirements on the SIP IP-PBX in terms of configuration and might therefore put less requirements on simple IP-PBX regarding configuration and be more appropriate in limited deployments where there is no need for addressing users beyond traditional E.164 numbers. That might well be, but it also is only representing a small fraction of the market as it ignores the only service provider standard available today.

This document therefore proposes a way forward whereby two modes of operation can be signalled independently, in a manner consistent with (RFC3261 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)).

ETSI TISPAN defines Next Generation Networks (NGN) which uses the 3rd-Generqation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) which in turn uses SIP (RFC3261 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)) as its main signalling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [3GPP.23.228] (3GPP, “IP Multimedia Subsystem (IMS); Stage 2,” .) and 3GPP TS 24.229 [3GPP.24.229] (3GPP, “Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3,” .).)

2.  Conventions

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 BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Definitions

3.1.  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.).

3.2.  Alphanumeric SIP URI

a SIP AoR which does not identify a global E.164 number or local-number.

3.3.  Implicit Registration

implicitly providing the reachability information for something other than the AoR explicitly indicated in the Register transaction.

3.4.  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.

3.5.  SSP

SIP Service Provider, as defined by [RFC5486].

3.6.  BC

bulk contact, a contact address that is used as a reachability address for multiple AOR.

3.7.  domain federation

Domain federation constitutes an architecture whereby SSP and the enterprise owning a PBX connected to the SSP's network, together manage a specific domain.

4.  Overview of the FRIENDS solution

4.1.  The issue in short

The current martini solution based on the GIN draft solves only a subspace of the total SIP trunking problemspace. It does so by staying carefully within the boundaries of what can be made to work with simple SIP proxies, taking for granted that the solution is suboptimal when more complicated deployments need to be served involving private numberplans, alphanumeric naming schemes etc.

It chooses a solution where Request-URI is rewritten with the PBX-contact for routing as is also done normally on the last hop to the UAS, this means that such Request-URI rewriting is also imposed on the intermediary hop between the SSP and the SIP IP-PBX. It has been recognised in earlier discussions that this is in fact an error in SIP to use Request-URI rewriting for request routing. In fact RFC3261 already introduced a mechanism to overcome this on intermediary hops for which it provides the Route header field. The Route header field is part of the core routing mechanism of SIP RFC3261 compliant proxies.

Other standards have been developed (especially ETSI TISPAN TS 182 025 and related work in 3GPP 24229) to serve such more complicated scenarios, the solution is build on placing the PBX-contact in the Route header field and leaving the Request-URI unchanged. There exist on the market place already a number of IP-PBX that expect the AOR in the Request-URI and its own contact address in the Route header field.

Both mechanisms have their area of applicability and are superior in their respective application niches.

Building on these facts the conclusion must be that it would be beneficial to combine both mechanisms and allow both routing variants to be supported.

4.2.  Registration signalling

This document extends the martini mechanism by distinguishing basic and federated bulk contact routing.

A PBX can announce that it supports basic bulk contact routing, by registering with bulk contact parameter set to the value "basic" in the registered contact.

A PBX can announce that it supports federated bulk contact routing, by registering with bulk contact parameter set to the value "federated" in the registered contact.

A PBX can announce that it supports both basic and federated bulk contact routing, by including two occurrences of the bulk contact parameter in the register request.

A PBX that supports basic bulk contact routing, supports and understands Request-URI's resulting from the current GIN model. This is good for simple PBX's or undemanding non-IMS deployments and it works great with numbers.

A PBX that supports federated bulk contact routing can handle cases where the enterprise domain to which the PBX belongs is federated with the SSP. And hence it is OK to be treated as a next hop proxy and receive the PBX-contact on the Route header field and a Request-URI where the hostpart portion contains the federated domain name. The latter allows delivery of the AOR in the Request-URI to the IP-PBX.

Upon receipt of a register request the SSP determines whether bulk contact routing applies and which variant to use based on the presence of the bulk contact parameter in the registration.

4.3.  SSP Processing of Inbound Requests targeted at an implicitly registered AOR assigned to a bulk contact

When a request enters the SSP that belongs to an implicitly registered AOR assigned to a bulk contact the SSP's proxy checks whether the bulk contact registered for basic or federated bulk contact routing.

If the bulk contact parameter indicated support for basic bulk contact routing or if the bulk contact was absent but the provisioned bulk contact indicator indicated support for basic bulk contact routing the SSP proxy proceeds with behaviour as specified in [draft-ietf-martini-gin-01].

If the bulk contact parameter indicated support for federated bulk contact routing or if the bulk contact parameter was absent but the provisioned bulk contact indicator indicated support for federated bulk contact routing, then the SSP proxy will proceed by placing the registered PBX-contact at the end of the Route header field and leave the Request-URI unchanged.

The above behaviour makes sure that federated routing is only used in cases where it is certain that the SSP configured its system knowingly to perform that behaviour for a certain customer. He will make sure that both sides are configured properly. This addresses the issues that people raised with solutions based on placing the contact on the Route header field in terms of problems with domain ownership.

5.  Security considerations

tbd

6.  IANA considerations

tbd

7.  Acknowledgments

Thanks to Adam Roach and Hadriel Kaplan for (unknowingly) providing text which we used for inspiration [draft-shaken], [draft-gin], [draft-olive]. Thanks to Martien Huysmans for providing text for the definition of the federated concept.

8.  References

8.1. Normative references

8.2. Informative references

Appendix A.  Revision Information

A.1.  version 00, MARTINI

1. 2010-04-27, Initial version

Authors' Addresses