[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
MARTINI WG                                                    H. Kaplan
Internet Draft                                              Acme Packet
Intended status: Standards-Track
Expires: April 25, 2011                                October 25, 2010

                    SIP Verification with Event-package
       for Resolution of Managed Open-ended Username Target Handles

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 25, 2011.

Copyright and License 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 BSD License.

Kaplan                   Expires April, 2011                 [Page 1]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010


   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, using the GIN mechanism defined in [draft-gin].
   Two other drafts, [draft-olive] and [draft-glass], propose the same
   for non-E.164-based AoRs.  This document defines a means by which
   the IP-PBX can verify the resolution entries in the SSP for open-
   ended or full AoRs of any GIN-based mechanism, using a new Event-
   Package named "vermouth".

Table of Contents

   1. Introduction..................................................2
   2. Definitions...................................................3
   3. The Solution - an Overview....................................4
   4. Event Package Definition......................................4
      4.1. Event Package Name.......................................4
      4.2. Event Package Parameters.................................5
      4.3. SUBSCRIBE Bodies.........................................5
      4.4. Subscription Duration....................................5
      4.5. NOTIFY Bodies............................................6
      4.6. Notifier Processing of SUBSCRIBE Requests................6
      4.7. Notifier Generation of NOTIFY Requests...................6
      4.8. Subscriber Processing of NOTIFY Requests.................7
      4.9. Handling of Forked Requests..............................7
      4.10. Rate of Notifications...................................7
      4.11. State Agents............................................8
   5. Username Information..........................................8
      5.1. Structure of Username Information........................8
      5.2. The "range" Attribute...................................10
   6. Examples.....................................................11
   7. IANA Considerations..........................................11
   8. Security Considerations......................................11
   9. Normative References.........................................11
   10. Informative References......................................12
   Author's Address.................................................12
   Appendix A - Rationale for Constraining the Expansion Pattern....12

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 defined in
   [draft-gin].  Another draft, [draft-olive], uses the [draft-gin] GIN
   mechanism for Local-Number AoRs as well; and a new draft [draft-
   glass] does the same for literal alpha-numeric/email-style AoRs.

Kaplan                   Expires - April 2011                 [Page 2]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   In all cases, the IP-PBX or another SIP entity may wish to learn
   about all of the AoRs which were implicitly Registered by [draft-
   gin] or [draft-olive], or to learn about changes in their
   provisioned AoRs through asynchronous notifications.  Even in non-
   Registration scenarios, where requests for specific AoRs in a SSP
   may instead be statically routed to an IP-PBX, it may be useful for
   the IP-PBX to learn what those AoRs are in order to detect
   mismatches or changes.

   In theory, the [draft-gin] mechanism is simply a short-hand single
   REGISTER transaction for a bulk set of AoRs in lieu of multiple,
   separate REGISTER transactions for each AoR.  In practice, however,
   the E.164 user numbers may be an "open" numbering plan/range, such
   that the SSP only really knows about a certain number of digits and
   the rest are only known to the IP-PBX.  Likewise, when [draft-olive]
   is used, the Local-Number may be only partially known to the SSP.

   Therefore, it is not possible for the SSP to actually provide state
   information for each possible unique AoR instance.  Instead, it
   needs to provide an indication for the registration state of the
   prefix or digit portion it does know about.

   This document proposes to provide such information using a new

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

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

   Bulk-AoR: a SIP or SIPS address-of-record with a "range" URI user
   parameter which expands the user string based on a heuristic.

   Local-Number: an AoR which follows the form of local-number in
   [RFC3966], but may be encoded in a SIP or TEL URI.  The local-number
   contains a 'phone-context' parameter identifying the scope of its

   Email-style URI: a SIP AoR which does not identify a global E.164
   number or Local-Number.

Kaplan                   Expires - April 2011                 [Page 3]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   Implicit Registration: implicitly providing the reachability
   information for something other than the AoR explicitly 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. The Solution - an Overview

   The general concept is a SIP device, such as an IP-PBX, Subscribes
   to a new "vermouth" Event-Package by issuing a SUBSCRIBE request
   targeted at the SIP URI AoR it explicitly registered using GIN, or
   some other mutually-agreed-upon SIP-URI if GIN was not used.

   If the Subscription is successful, the returned NOTIFY contains a
   userinfo XML document that lists all of the usernames of the AoR's
   domain that the SSP will route to the IP-PBX.  The XML document does
   not contain the Contact/Path routing reachability information, since
   that information is already in the reg-event package information for
   the explicitly registered AoR of the IP-PBX, and may also be more
   sensitive in nature.

   To handle the open-numbering-plan problem, an XML "range" attribute
   is used, which is similar to a regular expression pattern but with a
   very limited, specified syntax.  The limited syntax is used to avoid
   ambiguities and reduce confusion - rationale for this is provided in
   Appendix A.

   Furthermore, this document specifies that the To-URI used for the
   [draft-gin] REGISTER request, be usable as the target for the
   SUBSCRIBE request, both for the new 'vermouth' Event-Package, and
   for Subscribing to the [RFC3680] registration event-package for that
   explicitly registered AoR.

4. Event Package Definition

   This section fills in the details needed to specify an event package
   as defined in Section 4.4 of [RFC3265].

4.1. Event Package Name

   The SIP Events specification requires package definitions to specify
   the name of their package or template-package.

Kaplan                   Expires - April 2011                 [Page 4]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   The name of this package is "vermouth".  As specified in [RFC3265],
   this value appears in the Event header present in SUBSCRIBE and
   NOTIFY requests.

4.2. Event Package Parameters

   The SIP Events specification requires package and template-package
   definitions to specify any package specific parameters of the Event
   header that are used by it.

   No package specific Event header parameters are defined for this
   event package.

4.3. SUBSCRIBE Bodies

   The SIP Events specification requires package or template-package
   definitions to define the usage, if any, of bodies in SUBSCRIBE

   A SUBSCRIBE for registration events MAY contain a body. This body
   would serve the purpose of filtering the subscription. The
   definition of such a body is outside the scope of this

   A SUBSCRIBE for the registration package MAY be sent without a body.
   This implies that the default registration filtering policy has been
   requested. The default policy is:

     o Notifications are generated every time there is any change in
     the state of any of the registered contacts for the resource being
     subscribed to. Those notifications only contain information on the
     contacts whose state has changed.

     o Notifications triggered from a SUBSCRIBE contain full state (the
     list of all contacts bound to the address-of-record).

   Of course, the server can apply any policy it likes to the

4.4. Subscription Duration

   The SIP Events specification requires package definitions to define
   a default value for subscription durations, and to discuss
   reasonable choices for durations when they are explicitly specified.

   The Event Package defined herein is not tied to registration state,
   nor to any value that has natural expiry times.  Therefore, the
   suggested subscription duration is 86400 seconds (1 day).

Kaplan                   Expires - April 2011                 [Page 5]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   Of course, clients MAY include an Expires header in the SUBSCRIBE
   request asking for a different duration.

4.5. NOTIFY Bodies

   The SIP Events specification requires package definitions to
   describe the allowed set of body types in NOTIFY requests, and to
   specify the default value to be used when there is no Accept header
   in the SUBSCRIBE request.

   The body of a notification of a change in provisioned usernames
   contains a user information document.  This document describes some
   or all of the username expansions associated with the particular
   address-of-record subscribed to.  All subscribers and notifiers MUST
   support the "application/userinfo+xml" format described in Section
   5. The subscribe request MAY contain an Accept header field. If no
   such header field is present, it has a default value of
   "application/userinfo+xml". If the header field is present, it MUST
   include "application/userinfo+xml", and MAY include any other types
   capable of representing registration information.

   Of course, the notifications generated by the server MUST be in one
   of the formats specified in the Accept header field in the SUBSCRIBE

4.6. Notifier Processing of SUBSCRIBE Requests

   The SIP Events framework specifies that packages should define any
   package-specific processing of SUBSCRIBE requests at a notifier,
   specifically with regards to authentication and authorization.

   Provisioned usernames can be sensitive information.  Therefore, all
   subscriptions to it SHOULD be authenticated and authorized before
   approval.  Authentication MAY be performed using any of the
   techniques available through SIP, including digest, S/MIME, TLS or
   other transport specific mechanisms [1].  Authorization policy is at
   the discretion of the administrator, as always.  However, a few
   recommendations can be made.

   It is RECOMMENDED that an IP-PBX be allowed to subscribe to its own
   provisioned usernames.  Such subscriptions are useful for detecting
   errors and changes.

4.7. Notifier Generation of NOTIFY Requests

   The SIP Event framework requests that packages specify the
   conditions under which notifications are sent for that package, and
   how such notifications are constructed.

Kaplan                   Expires - April 2011                 [Page 6]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   Instead of delivering the full list every time a notification is
   sent, it is RECOMMENDED that notifications only list the username
   entries that have changed state (i.e., been added or removed).

   Notifications triggered as a result of a fetch operation (a
   SUBSCRIBE with Expires of 0) or a new Subscription SHOULD result in
   the full list of all usernames to be present in the NOTIFY.

4.8. Subscriber Processing of NOTIFY Requests

   The SIP Events framework expects packages to specify how a
   subscriber processes NOTIFY requests in any package specific ways,
   and in particular, how it uses the NOTIFY requests to construct a
   coherent view of the state of the subscribed resource.

   Typically, the NOTIFY will only contain information for usernames
   whose state has changed.  To construct a coherent view of the total
   state of all usernames, the subscriber will need to combine NOTIFYs
   received over time.  The details of this process depend on the
   document format used to convey registration state.  Section 5
   outlines the process for the application/userinfo+xml format.

4.9. Handling of Forked Requests

   The SIP Events framework mandates that packages indicate whether or
   not forked SUBSCRIBE requests can install multiple subscriptions.

   Provisioned usernames are normally stored in some repository
   (whether it be co-located with a proxy/registrar or in a separate
   database).  As such, there is usually a single place where the
   username information for a particular address-of-record is resident.
   This implies that a subscription for this information is readily
   handled by a single element with access to this repository. There
   is, therefore, no compelling need for a subscription to username
   information to fork. As a result, a subscriber MUST NOT create
   multiple dialogs as a result of a single subscription request. The
   required processing to guarantee that only a Section 4.4.9 of the
   SIP single dialog is established is described in Events framework

4.10.     Rate of Notifications

   The SIP Events framework mandates that packages define a maximum
   rate of notifications for their package.

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive.  As a result, it is RECOMMENDED

Kaplan                   Expires - April 2011                 [Page 7]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   that the server not generate notifications for a single subscriber
   at a rate faster than once every 5 seconds.

4.11.     State Agents

   The SIP Events framework asks packages to consider the role of state
   agents in their design.

   State agents have no role in the handling of this package.

5. Username Information

5.1. Structure of Username Information

   Username information is an XML document [4] that MUST be well-formed
   and SHOULD be valid.  Username information documents MUST be based
   on XML 1.0 and MUST be encoded using UTF-8.  This specification
   makes use of XML namespaces for identifying registration information
   documents and document fragments.  The namespace URI for elements
   defined by this specification is a URN [5], using the namespace
   identifier ietf defined by [6] and extended by [7]. This URN is:


   A username information document begins with the root element tag
   "userinfo".  It consists of any number of "userlist" sub-elements,
   each of which contains the provisioning state for a particular list
   of usernames, associated with the address-of-record subscribed to.
   The username information for a particular address-of-record MUST be
   contained within a single "userlist" element; it cannot be spread
   across multiple "userlist" elements within a document.  Other
   elements from different namespaces MAY be present for the purposes
   of extensibility; elements or attributes from unknown namespaces
   MUST be ignored.

   There are two attributes associated with the "userinfo" element,
   both of which MUST be present:

    version: This attribute allows the recipient of username
    information documents to properly order them.  Versions start at 0,
    and increment by one for each new document sent to a subscriber.
    Versions are scoped within a subscription. Versions MUST be
    representable using a 32 bit integer.

    state: This attribute indicates whether the document contains the
    full list of provisioned usernames, or whether it contains only
    information on those registrations which have changed since the
    previous document (partial).

Kaplan                   Expires - April 2011                 [Page 8]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   Note that the document format explicitly allows for conveying
   information on multiple addresses-of-record.  This enables
   subscriptions to groups of usernames, where such a group is
   identified by some kind of URI.  For example, a domain might define
   sip:allusers@example.com as a subscribe-able resource that generates
   notifications when the provisioning state of any address-of-record
   in the domain changes.

   The "userlist" element has a list of any number of "user" sub-
   elements, each of which contains information on a single username
   entry, which may itself be a range-patterned name.  Other elements
   from different namespaces MAY be present for the purposes of
   extensibility; elements or attributes from unknown namespaces MUST
   be ignored.

   There are three attributes associated with the "userlist" element,
   all of which MUST be present:

     aor:   The aor attribute contains a URI which is the address-of-
     record this list is associated with.

     id: The id attribute identifies this list. It MUST be unique
     amongst all other id attributes present in other userlist elements
     conveyed to the subscriber within the scope of their subscription.
     Furthermore, the id attribute for a "userlist" element for a
     particular address-of-record MUST be the same across all
     notifications sent within the subscription.

     state: The state attribute indicates the state of the username
     list. The valid values are "active" and "removed".

   The "user" element contains the username.  There are several
   attributes associated with the "contact" element which MUST be

     id: The id attribute identifies this user name. It MUST be unique
     amongst all other id attributes present in other user elements
     conveyed to the subscriber within the scope of their subscription.

     state: The state attribute indicates the state of the user name.
     The valid values are "active" and "removed".

     type: The type attribute identifies the user name type.  Valid
     values are "e614", "private", and "alpha".

     range: the range attribute is defined in the next section.

Kaplan                   Expires - April 2011                 [Page 9]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

     context: the context attribute is only meaningful when the type
     attribute is "private", and in such a case the context identifies
     the context of the private name space.

5.2. The "range" Attribute

   The range attribute's value defines the expansion of the username,
   using a syntax similar to regular expressions.  The range pattern
   applies after the last character of the user element's value.

   range-value    = exp-char-set exp-char-count

   exp-char-set   = digit-char-set / any-char-set
   digit-char-set = "[" dsc-begin "-" dsc-end "]"
   dsc-begin      = DIGIT
   dsc-end        = DIGIT
   any-char-set   = "."

   exp-char-count = "{" exp-min "," exp-max "}"
   exp-min        = DIGIT
   exp-max        = DIGIT

   The "digit-char-set" defines a range of digit characters, for
   example 0-9 or 3-5, inclusive.  The "dsc-begin" digit value must be
   less than or equal to the "dsc-end" digit value.

   The "any-char-set" defines any single character allowed in the
   'user' token field of [RFC3261].

   The "exp-char-count" defines a minimum and maximum number of times a
   character within the exp-char-set may be repeated, inclusive.  The
   "exp-min" digit value must be less than or equal to the "exp-max"
   digit value.

Kaplan                   Expires - April 2011                [Page 10]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

6. Examples

   Detailed scenario examples will be provided once the WG decides
   which way to go with this mechanism.

   The following is an example username information document:

     <?xml version="1.0"?>

         <userinfo xmlns="urn:ietf:params:xml:ns:userinfo"
            version="23" state="full">

            <userlist aor="sip:ip-pbx1@ssp.example.com" state="active">

              <user id="76" state="active"

              <user id="77" state="removed" type="alpha">bob</user>

              <user id="78" state="active" type="e614"

              <user id="79" state="active" type="private"



7.   IANA Considerations

   This document makes no request of IANA yet, but will if it goes

8. Security Considerations

   This section is still TBD.

9.   Normative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.

Kaplan                   Expires - April 2011                [Page 11]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3680]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
              Package for Registrations", RFC 3680, March 2004.

   [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers
              in the Session Initiation Protocol (SIP)", draft-ietf-
              martini-gin-10, October 2010.

10.  Informative References

   [RFC3327]  Willis, D., and Hoeneisen, B., "Session Initiation
              Protocol (SIP) Extension Header Field for Registering
              Non-Adjacent Contacts", RFC 3327, December 2002.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
              3966, December 2004.

   [RFC4244]  Barnes, M. (ed.), "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC
              4244, November 2005.

   [RFC5486]  Malas, D., and Meyer, D., "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486, March

Author's Address

   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA 01803, USA
   Email: hkaplan@acmepacket.com

Appendix A - Rationale for Constraining the Expansion Pattern

   This document's mechanism defines a limited set of patterns which
   may be used in the "<expansion>" portion of the Bulk-AoR.  This is
   in contrast to the "Wildcarded AoR" mechanism used in some
   deployments, which use any regular expressions (regex) for the

Kaplan                   Expires - April 2011                [Page 12]

Internet-Draft           SIP MARTINI VERMOUTH             October 2010

   pattern.  One of the reasons this document restricts the regex
   syntax is to maintain [RFC3261] compliance, which does not allow
   common regex characters such as '^', '[', ']','{', and '}' to appear
   in SIP URIs.

   The other reason this document does not use any arbitrary regex is
   that one of the goals of this document is to be useful for an IP-PBX
   to determine provisioning mismatches.  An arbitrary regex is
   typically useful for verifying a given input string matches the
   pattern, and not for actually determining the complete set of
   strings the regex pattern implies.  In other words, a regex is
   useful for authenticating a given number matches the pattern, but
   not for determining what all of the provisioned numbers are.

   For example, a regex syntax model for "sip:1234![5-9][0-
   9]*!@example.com" is useful for checking if "sip:123456@example.com"
   is a matching number, but is extremely difficult for an IP-PBX to
   verify that the SSP does not include numbers the PBX does not have
   provisioned.  The IP-PBX could check each of its locally provisioned
   numbers against the regex pattern, but has no clean way to determine
   if the set allowed by the regex is not *greater* than its locally
   provisioned set.

   Furthermore, numerous regex patterns can be used to mean the exact
   same set.  For example "sip:1234!(5|6|7|8|9)[0-9]*!@example.com",
   "sip:1234![5-9][0-9]{0,}!@example.com", "sip:1234![5-
   9][[:digits:]]*!@example.com", and "sip:123!4[5-9][0-
   9]*!@example.com" all represent the same set of user strings as the
   first regex example.

   Therefore, to avoid such issues, this document uses a very narrow
   set of possible "patterns", which can be used for both matching and
   provisioning verification.

Kaplan                   Expires - April 2011                [Page 13]