One document matched: draft-ietf-martini-reqs-00.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3327.xml">
<!ENTITY rfc5626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml">
<!ENTITY draft-mixing-problems SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kaplan-martini-mixing-problems-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>

<rfc category="info" docName="draft-ietf-martini-reqs-00.txt" ipr="trust200811" obsoletes="" updates="">
<front>
  <title abbrev="Multiple AOR reachability in SIP">Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP)</title>
  <author fullname="John Elwell" initials="J." surname="Elwell">
    <organization>Siemens Enterprise Communications</organization>
    <address>
      <phone>+44 1908 855608</phone>
      <email>john.elwell@siemens-enterprise.com</email>
    </address>
  </author>
  <date year="2010"></date>
  <area>RAI</area>
  <workgroup>MARTINI WG</workgroup>
  <keyword>I-D</keyword>
  <keyword>Internet-Draft</keyword>
  <keyword>SIP</keyword>
  <keyword>Implicit-Registration</keyword>
  <abstract>
    <t> 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.</t>
<t>This work is being discussed on the martini@ietf.org mailing list.</t>
  </abstract>
</front>
<middle>
  <section title="Introduction">
    <t>The Session Initiation Protocol (SIP) <xref target="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 <xref target="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 <xref target="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 <xref target="RFC3263"/> procedures for using the Domain Name System (DNS) to obtain the next-hop connection information.</t>
    <t>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.</t>
    <t>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 <xref target="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.</t>
    <t>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.</t>
  </section>
  <section title="Terminology">
    <t>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 <xref target="RFC2119"/>.</t>
    <t>The terms address of record (AOR), proxy, REGISTER, registrar, request and user agent (UA) are to be interpreted as described in <xref target="RFC3261"/>.</t>
  </section>
  <section title="Requirements">
    <t>The following are requirements of the mechanism.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
    <t>REQ8 - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
    <list>
      <t>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.</t>
    </list></t>
    <t>REQ9 - The mechanism MUST observe SIP backwards compatibility principles.
    <list>
      <t>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.</t>
    </list></t>
    <t>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.
    <list>
      <t>These intermediate SIP entities can be edge proxies, session border controllers, etc..</t>
    </list></t>
    <t>REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.</t>
    <t>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.</t>
    <t>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.</t>
    <t>REQ14 - The mechanism MUST be able to operate over a transport that provides integrity protection and confidentiality.</t>
    <t>REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa.</t>
    <t>REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs).</t>
    <t>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.</t>
  </section>
  <section title="Desirables">
    <t>The following are desirable properties of the mechanism.</t>
    <t>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.</t>
    <t>DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers.
    <list>
      <t> This will probably preclude any mechanism involving a separate REGISTER transaction per assigned telephone number.</t>
      <t>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.</t>
    </list></t>
    <t>DES3 - The mechanism SHOULD scale to support several thousand SIP-PBXs on a single SSP.</t>
    <t>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.
    <list>
      <t>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.</t>
    </list></t>
  </section>
  <section title="Non-requirements">
    <t>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.</t>
    <t>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.</t>
  </section>
  <section title="IANA considerations">
    <t>This document requires no IANA actions.</t>
  </section>
  <section title="Security considerations" anchor="section-security">
    <t>Security of signaling between the SIP-PBX and the SSP is important. Some of the requirements above already address this.</t>
    <t>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.</t>
  </section>
  <section title="Acknowledgements">
    <t>The contents of the document have been compiled from extensive discussions within the MARTINI WG, the individuals concerned being too numerous to mention.</t>
  </section>
</middle>

<back>
  <references title="Informative References">
    &rfc2119;
    &rfc3261;
    &rfc3263;
    &rfc3327;
    &rfc5626;
    &draft-mixing-problems;
  </references>
</back>
</rfc>