[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
MARTINI WG                                                    H. Kaplan
Internet Draft                                              Acme Packet
Intended status: Standards-Track
Expires: November 3, 2011                                   May 3, 2010


         SIP MARTINI Variant of 'Event-package for Registrations'
        for Managed Open-ended Username Target Handling (VERMOUTH)
                     draft-kaplan-martini-vermouth-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 November 3, 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 November 18, 2010              [Page 1]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


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 [draft-gin].  Another draft [draft-olive]
   proposes the same for non-E.164-based AoRs.  This document defines a
   variant of the Registration Event-package [reg-event] for open-ended
   AoRs for either mechanisms, using a wildcard syntax and specific
   target handling rules.

Table of Contents

   1.    Introduction................................................2
   2.    Definitions.................................................3
   3.    The Solution - an Overview..................................4
   4.    The Bulk-AoR................................................5
      4.1.   Bulk-AoR ABNF Rules.....................................5
      4.2.   Restrictions of Use.....................................6
   5.    Subscribing for Registration State Resources................6
      5.1.   Subscribing to AoRs.....................................7
      5.2.   Subscribing to state in the IP-PBX......................8
      5.3.   Subscribing for all implicitly registered AoRs..........8
      5.4.   Subscribing to a Bulk-AoR...............................9
   6.    Event Package registration information......................9
      6.1.   Constructing Bulk-AoR registration elements.............9
      6.2.   Processing Bulk-AoR registration elements..............10
   7.    Examples...................................................10
      7.1.   Example XML document...................................10
      7.2.   Usage Scenario: Subscribing to an AoR..................11
      7.3.   Usage Scenario: Subscribing to the AoRs off the IP-PBX.13
      7.4.   Usage Scenario: Subscribing to all AoRs................16
   8.    IANA Considerations........................................17
   9.    Security Considerations....................................17
   10.   Normative References.......................................18
   11.   Informative References.....................................18
   Author's Address.................................................18
   Appendix A - Rationale for Constraining the Expansion Pattern....19


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].  Another draft,
   [draft-olive] uses the [draft-gin] Martini mechanism for non-E.164
   AoRs as well.



Kaplan                 Expires - November 2009               [Page 2]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   In both cases, the IP-PBX or other entity may wish to Subscribe to
   the Registration Event Package based on [RFC3680] for the
   Registration state information of the AoRs Registered by the [draft-
   gin] REGISTER transactions.  For example, the IP-PBX 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
   provisioning.

   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 an agreed
   upon URI format: a "Bulk-AoR", which follows a specific AoR syntax
   indicating the number range, and is formatted such that it can be
   reasonably reserved for such use.

   This document also defines the rules for targeting SUBSCRIBE
   requests to reach specific resources for registration state
   information.

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

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



Kaplan                 Expires - November 2009               [Page 3]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


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

   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

   To handle the open-numbering-plan problem, the concept proposed in
   this document is to specify a specific URI syntax which is legal in
   SIP ABNF grammar, but highly unlikely to exist for anything but this
   document's purpose, by defining a new URI user parameter.  This
   creates a "Bulk-AoR" URI, which is treated as any other AoR URI from
   the perspective of [RFC3680].

   The specific Bulk-AoR format is similar but not identical to the
   "Wildcarded" AoR syntax already in use in certain deployments.  The
   Bulk-AoR format is "sip:<user>;range=<expansion>@<domain>", where
   "<expansion>" is similar to a regular expression pattern but has a
   very limited, specified syntax.  The limited syntax is used to avoid
   ambiguities, make it compliant with [RFC3261] ABNF rules, and reduce
   confusion - rationale for this is provided in Appendix A. [Open
   issue: should a new URI parameter similar to "user=phone" be defined
   for such an AoR type?]

   Furthermore, this document assumes that the SSP's Registrar
   processes Subscriptions for the "reg" event package following
   [RFC3680], and thus that a SUBSCRIBE targeted to any of the
   implicitly Registered AoRs be processed by the SSP (not the IP-PBX).
   This document also provides a means, however, to Subscribe for the
   registration state for those same AoRs in the IP-PBX itself, by
   using the "bnc" parameter in the SUBSCRIBE target URI.

   Lastly, this document specifies that the To-URI used for the [draft-
   gin] REGISTER request, be usable as the target for the SUBSCRIBE
   request, for Subscribing to the registration event information for
   all implicitly registered AoRs of the [draft-gin] mechanism, any or
   all of which may be encoded using the Bulk-AoR syntax proposed in
   this document.




Kaplan                 Expires - November 2009               [Page 4]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   The Registration Event Packet behavior for this document's mechanism
   works exactly the same way as defined in [RFC3680].  This document
   does not update [RFC3680] or change its semantics.  The only
   "changes" discussed in this document are (1) details of how to
   target a SUBSCRIBE for specific Registration state information
   resources in section 5, and (2) explanations about reginfo XML
   documents with Bulk-AoRs in section 6.  Neither of these
   substantively changes [RFC3680] behavior.

4. The Bulk-AoR

   A "Bulk-AoR" is a SIP or SIPS URI Address-of-record containing a new
   URI user parameter named "range".  The range parameter expands the
   user portion based on a specific heuristic, when the Bulk-AoR is
   processed by a SIP node which follows this document.  When processed
   by any other node, it is just another SIP or SIPS URI.

   The primary use-case for a Bulk-AoR is for the "aor" attribute value
   of a "registration" element of a [RFC3680] reginfo XML document, as
   described in section 6.  Using the Bulk-AoR as a target for generic
   SIP requests is outside the scope of this document.  Using it as the
   target for a SUBSCRIBE request is discussed in section 5.4.

4.1. Bulk-AoR ABNF Rules

   A Bulk-AoR follows [RFC3261] ABNF rules as a specific form of the
   'user' token field of a SIP or SIP URI userinfo portion in
   [RFC3261]:
   bulk-aor-user  = user ";range=" expansion
   expansion      = 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 character allowed in the 'user' token
   field of [RFC3261].




Kaplan                 Expires - November 2009               [Page 5]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   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.

   An example SIP Bulk-AoR is "sip:1234;range=0-9(1,8)@ssp.example.com"
   Note that the ABNF rules are written such that the digit-char-set
   could be wrapped in a '[' and ']' characters, and the parenthesis in
   exp-char-count could be converted to '{' and '}', and the resultant
   would then be a regex pattern with the same semantics.  Furthermore,
   although the syntax does not support '*' and '+' regex command
   characters, they are logically equivalent to a {0,} and {1,} albeit
   with some specified maximum bound.

4.2. Restrictions of Use

   The mechanism proposed in this document is based on [RFC3680], but
   creates a specific URI syntax for indicating Registration event
   information for bulk groups of AoRs.  In other words, it is
   semantically equivalent to multiple, individual AoR state
   information.  Since the URI used represents multiple AoRs, certain
   implementation details are constricted beyond what [RFC3680] would
   have required.

   In particular, with separate AoR Registration state it is possible
   to distribute the Subscription processing across multiple servers,
   for different AoRs.  Such is not possible for the AoRs covered by a
   Bulk-AoR range - the Registration state information, and the state
   machine described in [RFC3680] MUST be the same and available to the
   same SIP entity which processes the Subscription.

   Furthermore, the Bulk-AoR syntax does not have an "exclude" semantic
   - it is wholly inclusive, meaning that any specific AoR within its
   range is included.  For example, if an AoR within the range has
   multiple Contacts, but not all AoRs of the range have the same
   multiple Contact values, then the Bulk-AoR state is in addition to
   any separate AoR entries.  Once again, this requires the same SIP
   entity which processes the Subscription to have such information
   available to it for all of the AoRs included within the Bulk-AoR
   range.


5.   Subscribing for Registration State Resources

   As per [RFC3680], when a UAC Subscribes to a SIP URI for the "reg"
   Event Package, the entity responsible for the Registration state of
   the SIP URI processes the SUBSCRIBE and returns a Registration
   information document with the details of the URI's registration
   state, including Registered Contacts and such.  The target of the


Kaplan                 Expires - November 2009               [Page 6]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   Registration event package Subscription (the Request URI used for
   the SUBSCRIBE request) identifies the AoR for which the
   "registration state" is requested.  In other words, although the
   target of the SUSBCRIBE identifies a Registered AoR, it is not
   routed to the Registered contacts of that AoR, but rather to the
   entity responsible for the AoR's Registration state: the SSP.

   In a [draft-gin] or [draft-olive] context, the bulk Registration
   implicitly Registers multiple AoRs of the SSP.  As such, this
   document proposes that [RFC3680] continue to be followed, and that a
   SUBSCRIBE targeted to one of the implicitly Registered AoRs be
   processed by the SSP and return the registration state information
   *of that AoR* - namely, the expanded Contact, Path information, etc.
   of the IP-PBX as the "User Agent".

   In a [draft-gin] or [draft-olive] context, however, there is a need
   to handle Subscriptions for other resources as well.  There is a
   need to be able to Subscribe to the registration information of AoRs
   within the IP-PBX (the IP-PBX's internal registration state); and to
   be able to Subscribe for registration information of all implicitly
   registered AoRs of the IP-PBX without knowing what they are in
   advance.  This section defines how one Subscribes to such target
   resources.

5.1. Subscribing to AoRs

   A SUBSCRIBE for any specific AoR URI, including any implicitly
   Registered by [draft-gin], MUST be processed and handled as if there
   had been an explicit REGISTER transaction and associated state for
   that specific AoR.  In other words, assuming local policies allow
   it, a SUBSCRIBE for "sip:+123456@ssp.example.com" would get the
   Registration state for that AoR, with the *expanded* [draft-gin]
   Contact URI, the remaining expires value from the 'bnc' REGISTER,
   etc.  From a logical perspective, the [draft-gin] REGISTER was
   simply a short-hand for multiple, separate REGISTERs.

   Any internal optimization performed by the SSP location-service
   database for handling Bulk-AoRs MUST NOT change this external
   behavior.  In particular, although local policy MAY simply not
   provide Registration status for the specific AoR, it MUST NOT
   respond to such with the Bulk-AoR form of the Registration
   information.  Doing so would lead to backwards-compatibility
   problems, and is also not consistent with the resource targeted for
   the SUBSCRIBE.  If a UAC is Subscribing for a specific AoR's event
   information, that is what it should get, or nothing at all.






Kaplan                 Expires - November 2009               [Page 7]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


5.2. Subscribing to state in the IP-PBX

   To Subscribe to the registration state *within* the IP-PBX (i.e.,
   for the IP-PBX's User Agents), one could send a subsequent SUBSCRIBE
   to the IP-PBX based on the information learned from the Subscription
   to the SSP's AoRs.  For example, subscribing to
   "sip:+1234567890@ssp.example.com" could return the expanded
   Registered Contact "sip:+1234567890@192.1.2.3" and Path information
   for that AoR; and sending another SUBSCRIBE with the target
   "sip:+1234567890@192.1.2.3" and a Route set of the registered Path
   information could reach the IP-PBX and retrieve registration
   information for that resource.

   To avoid such complexity, however, this document proposes that a
   SUBSCRIBE targeted to a URI with a "bnc" URI parameter appended, be
   usable to target the resource of the IP-PBX to begin with, and not
   be processed for the event package by the SSP.  In other words,
   given the example above, if the SUBSCRIBE were targeted to
   "sip:+1234567890@ssp.example.com;bnc" then the SSP would route the
   request to the registered Contact of that AoR, using the normal
   request routing rules in [draft-gin].  This would result in the
   SUBSCRIBE being routed to the IP-PBX with a Request URI of
   "sip:+1234567890@192.1.2.3" for the "reg" event package, instead of
   being locally processed by the SSP.

5.3. Subscribing for all implicitly registered AoRs

   In order to be useful for provisioning checks, it needs to be
   possible for an IP-PBX which Registered in bulk using [draft-gin] to
   learn all of its implicitly Registered AoRs, without knowing them in
   advance.  To do so, this document defines that the Registered AoR of
   the IP-PBX (the To URI used in the bulk [draft-gin] REGISTER),
   return all of the Registered AoRs of the IP-PBX.  In other words,
   that the explicitly Registered AoR be used in the target URI of a
   SUBSCRIBE for the "reg" Event Package, to Subscribe to the
   Registration Event status of all implicitly Registered AoRs of the
   IP-PBX.

   For example, if the IP-PBX had Registered with a To-URI of
   "sip:pbx1@ssp.example.com" in its REGISTER request, then it (or any
   authorized UA) can send a SUBSCRIBE with a Request-URI of
   "sip:pbx1@ssp.example.com" for the "reg" Event-package and receive
   Notifications of all of the implicitly Registered AoRs.  One or more
   of those Registered AoRs MAY be expressed in the NOTIFY using the
   Bulk-AoR format defined in this document.






Kaplan                 Expires - November 2009               [Page 8]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


5.4. Subscribing to a Bulk-AoR

   Generally it is not expected that a Bulk-AoR URI itself be
   Subscribed to directly, simply because it is unlikely to be known in
   advance by other entities and because it provides limited value to
   do so.  For example, an IP-PBX wishing to verify its provisioned
   AoRs match what the SSP believes SHOULD NOT subscribe to a Bulk-AoR
   directly, since it will only learn about that one AoR group and not
   others which the SSP may incorrectly think the IP-PBX implicitly
   Registered.

   From a logical perspective, however, a Bulk-AoR is a real URI.  If a
   SUBSCRIBE is targeted at a Bulk-AoR URI in its Request-URI, then the
   Registration state information returned MUST be for all of the AoRs
   matching the range's format.  For example, if a UA SUBSCRIBEs to
   "sip:+1234;range=0-9(1,8)@@ssp.com", and the authoritative server
   for "ssp.com" has both Registered AoR information for
   "sip:+1234;range=0-9(1,8)@ssp.com" as well as for
   "sip:+123456@ssp.com", both AoRs are returned in the resulting
   NOTIFY reginfo document.

   [OPEN ISSUE: perhaps we should leave this section out, and only
   define "Bulk-AoRs" for Notification results but not as legitimate
   targets of Subscriptions themselves]

6. Event Package registration information

   The Registration Information provided by the Subscription as an XML
   document is as per [RFC3680], with the additional rules defined in
   this section.  Note that the structure and schema of the XML
   document does not change, nor the information contained therein -
   the document contains Registration information for URIs, as before.
   The "changes" are simply the rules for when to provide a Bulk-AoR
   URI entry in particular, and how to process it.

   A Bulk-AoR entry MUST NOT be used for a reginfo XML document unless
   the Registration state, including Contacts and such, are identical
   for all AoRs within the indicated range.  Generally, this is only
   possible when the range of AoRs was implicitly registered through a
   [draft-gin] type REGISTER mechanism.  This does not mean that a
   specific AoR within the range cannot have additional Registered
   Contacts that the other AoRs of the range do not - it can, but those
   other Contacts are not included in the specific Bulk-AoR XML entry.

6.1. Constructing Bulk-AoR registration elements

   As per [RFC3680], each "registration" element within a reginfo
   document has three attributes: an "aor", an "id", and a "state"
   attribute.  For a Bulk-AoR registration element, the "aor" attribute


Kaplan                 Expires - November 2009               [Page 9]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   value MUST be of the Bulk-AoR form, including the "range" URI user
   parameter as previously defined.  The "id" MUST be unique, as
   defined for any registration element in [RFC3680].

   A "contact" element's "uri" attribute value within a Bulk-AoR
   registration element MUST be the *unexpanded* Contact URI learned
   from the REGISTER transaction.  In other words, it is without a user
   portion and with a "bnc" URI parameter, as defined in [draft-gin].
   An important property of the [RFC3680] reginfo document is the "id"
   attribute of elements, which provides a unique index for the URIs,
   usable in logical tables.  The "id" attribute of the "registration"
   element is unique per AoR URI, and the "id" of the "contact" element
   is unique per unique Contact URI.  A Bulk-AoR is just another URI,
   and as such gets its own registration "id" value.

   A Bulk-AoR with the same user name but a different "range" URI user
   parameter value is a different Bulk-AoR URI, and thus gets a
   different ID.  For example, if the range of AoRs is changed, a
   Notification reginfo document would use a new "id" value for the new
   Bulk-AoR registration element, and the previous one would be
   replaced (assuming the reginfo document "state" attribute value was
   "full").

6.2. Processing Bulk-AoR registration elements

   A SIP subscriber following [RFC3680] receives notifications, with
   partial or full state information, for registration state of AoRs
   and their Contacts.  This document follows that same model for a
   Bulk-AoR, as if it were any other registration AoR URI.

   Note that the registration tables and rows described in [RFC3680]
   are purely logical, and do not describe a specific internal
   implementation.


7. Examples

   These will be fleshed out more in later versions of the draft, with
   explanations of the processing performed at each step.  For the time
   being, they just show the basic syntax described above.

7.1. Example XML document

   The following is an example registration information document with a
   Bulk-AoR entry:

   <?xml version="1.0"?>
      <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


Kaplan                 Expires - November 2009              [Page 10]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


                   version="0" state="full">
        <registration aor="sip:+12345678;range=0-9(1,4)@example.com"
                      id="as9" state="active">
          <contact id="76" state="active" event="registered"
                   duration-registered="7322"
                   q="0.8">
                   <uri>sip:192.1.2.3;bnc</uri>
          </contact>
          <contact id="77" state="terminated" event="expired"
                   duration-registered="3600"
                   q="0.5">
                   <uri>sip:192.4.5.6;bnc</uri>
          </contact>
        </registration>
      </reginfo>

7.2. Usage Scenario: Subscribing to an AoR

   This example shows a basic bulk REGISTER transaction, followed by a
   SUBSCRIBE addressed to one of the implicitly registered AoRs.


   Internet                        SSP                              PBX
   |                                |                                 |
   |                                |                         REGISTER|
   |                                |   Contact:<sip:198.51.100.3;bnc>|
   |                                |<--------------------------------|
   |                                |200 OK                           |
   |                                |-------------------------------->|
   |SUBSCRIBE                       |                                 |
   |sip:+1234567@ssp.example.com    |                                 |
   |------------------------------->|                                 |
   |                          200 OK|                                 |
   |<-------------------------------|                                 |
   |                                |                                 |
   |                          NOTIFY|                                 |
   |<-------------------------------|                                 |
   |200 OK                          |                                 |
   |------------------------------->|                                 |












Kaplan                 Expires - November 2009              [Page 11]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx123@ssp.example.com>
   From: <sip:pbx123@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.100.3:5060;bnc>
   Expires: 7200
   Content-Length: 0


   SUBSCRIBE sip:+1234567@ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 70
   To: <sip:+1234567@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 SUBSCRIBE
   Contact: <sip:line-1@192.0.2.178:2081>
   Event: reg
   Content-Length: 0


   NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Max-Forwards: 70
   From: <sip:2145550105@some-other-place.example.net>;tag=991411
   To: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 36123 NOTIFY
   Contact: <sip:proxy.ssp.example.com>
   Event: reg
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
            version="1" state="full">
    <registration aor="sip:+1234567@ssp.example.com"
                  id="a7" state="active">
      <contact id="76" state="active" event="registered"
            duration-registered="0">
         <uri>sip:+1234567@198.51.100.3</uri>




Kaplan                 Expires - November 2009              [Page 12]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


      </contact>
    </registration>
   </reginfo>

7.3. Usage Scenario: Subscribing to the AoRs off the IP-PBX

   This example shows a basic bulk REGISTER transaction, followed by a
   SUBSCRIBE addressed to one of the implicitly registered AoRs' state
   in the IP-PBX.


   Internet                        SSP                              PBX
   |                                |                                 |
   |                                |                         REGISTER|
   |                                |   Contact:<sip:198.51.100.3;bnc>|
   |                                |<--------------------------------|
   |                                |200 OK                           |
   |                                |-------------------------------->|
   |SUBSCRIBE                       |                                 |
   |sip:+1234567@ssp.example.com;bnc|                                 |
   |------------------------------->|                                 |
   |                                |SUBSCRIBE                        |
   |                                |sip:+1234567@198.51.100.3        |
   |                                |-------------------------------->|
   |                                |                           200 OK|
   |                                |<--------------------------------|
   |                          200 OK|                                 |
   |<-------------------------------|                                 |
   |                                |                           NOTIFY|
   |                                |<--------------------------------|
   |                          NOTIFY|                                 |
   |<-------------------------------|                                 |
   |200 OK                          |                                 |
   |------------------------------->|                                 |
   |                                |200 OK                           |
   |                                |-------------------------------->|















Kaplan                 Expires - November 2009              [Page 13]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx123@ssp.example.com>
   From: <sip:pbx123@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.100.3;bnc>
   Expires: 7200
   Content-Length: 0


   SUBSCRIBE sip:+1234567@ssp.example.com;bnc SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 70
   To: <sip:+1234567@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 SUBSCRIBE
   Contact: <sip:line-1@192.0.2.178:2081>
   Event: reg
   Content-Length: 0


   SUBSCRIBE sip:+1234567@198.51.100.3 SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Max-Forwards: 69
   To: <sip:+1234567@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 SUBSCRIBE
   Contact: <sip:line-1@192.0.2.178:2081>
   Event: reg
   Content-Length: 0













Kaplan                 Expires - November 2009              [Page 14]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3;branch=z9hG4bKaplan123
   Max-Forwards: 70
   From: <sip:2145550105@some-other-place.example.net>;tag=991411
   To: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 36123 NOTIFY
   Contact: <sip:+1234567@198.51.100.3>
   Event: reg
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
            version="1" state="full">
    <registration aor="sip:+1234567@198.51.100.3"
                  id="b9" state="active">
      <contact id="99" state="active" event="registered"
            duration-registered="0">
         <uri>sip:priv-user@198.51.2.33</uri>
      </contact>
    </registration>
   </reginfo>




























Kaplan                 Expires - November 2009              [Page 15]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


7.4. Usage Scenario: Subscribing to all AoRs

   This example shows a basic bulk REGISTER transaction, followed by a
   SUBSCRIBE addressed to all of the implicitly registered AoRs,
   returned as a Bulk-AoR.


   Internet                        SSP                              PBX
   |                                |                                 |
   |                                |                         REGISTER|
   |                                |   Contact:<sip:198.51.100.3;bnc>|
   |                                |<--------------------------------|
   |                                |200 OK                           |
   |                                |-------------------------------->|
   |SUBSCRIBE                       |                                 |
   |sip:pbx123@ssp.example.com      |                                 |
   |------------------------------->|                                 |
   |                          200 OK|                                 |
   |<-------------------------------|                                 |
   |                                |                                 |
   |                          NOTIFY|                                 |
   |<-------------------------------|                                 |
   |200 OK                          |                                 |
   |------------------------------->|                                 |



   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx123@ssp.example.com>
   From: <sip:pbx123@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.100.3:5060;bnc>
   Expires: 7200
   Content-Length: 0











Kaplan                 Expires - November 2009              [Page 16]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


   SUBSCRIBE sip:pbx123@ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 70
   To: <sip:pbx123@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 SUBSCRIBE
   Contact: <sip:line-1@192.0.2.178:2081>
   Event: reg
   Content-Length: 0


   NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Max-Forwards: 70
   From: <sip:2145550105@some-other-place.example.net>;tag=991411
   To: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 36123 NOTIFY
   Contact: <sip:proxy.ssp.example.com>
   Event: reg
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
            version="1" state="full">
    <registration aor="sip:+12345;range=0-9(1,2)@ssp.example.com"
                  id="a7" state="active">
      <contact id="76" state="active" event="registered"
            duration-registered="0">
         <uri>sip:198.51.100.3;bnc</uri>
      </contact>
    </registration>
   </reginfo>

8.   IANA Considerations

   This document makes no request of IANA.


9. Security Considerations

   This section is still TBD, but it should follow/have the same issues
   as [draft-gin].






Kaplan                 Expires - November 2009              [Page 17]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


10.  Normative 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.

   [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-01, April 2010.


11.  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
              2009.




Author's Address

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









Kaplan                 Expires - November 2009              [Page 18]


Internet-Draft           SIP MARTINI VERMOUTH                 May 2010


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
   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 - November 2009              [Page 19]