| TOC |
|
This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for extensions designated by phone numbers. In order to function properly, this mechanism relies on the fact that the phone numbers are fully qualified and globally unique.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2010.
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.
1.
Introduction
2.
Constraints
3.
Terminology
4.
Mechanism Overview
5.
Registering for Multiple Phone Numbers
6.
SSP Processing of Inbound Phone Number Requests
7.
Interaction with Other Mechanisms
7.1.
Globally Routable User-Agent URIs (GRUU)
7.1.1.
Public GRUUs
7.1.2.
Temporary GRUUs
7.2.
Registration Event Package
7.2.1.
PBX Aggregate Registration State
7.2.2.
Individual Extension Registration State
7.3.
Client-Initiated (Outbound) Connections
7.4.
Non-Adjacent Contact Registration (Path)
7.5.
Service Route Discovery
8.
Examples
8.1.
Wumpus 3
8.2.
Wumpus 9
9.
Issues Solved
10.
IANA Considerations
10.1.
New SIP Option Tag
10.2.
New SIP URI Parameters
11.
References
11.1.
Normative References
11.2.
Informative References
§
Author's Address
| TOC |
One of SIP's primary functions is providing rendezvous between users. By design, this rendezvous has been provided through a combination of the server look-up procedures defined in RFC 3263 [2] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.), and the registrar procedures described in RFC 3261 [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
The intention of the original protocol design was that any user's AOR would be handled by the authority indicated by the hostport portion of the AOR. The users registered individual reachability information with the this authority, which would then route incoming requests accordingly.
In actual deployments, some SIP servers have been deployed in architectures that, for various reasons, have requirements to provide dynamic routing information for large blocks of AORs, where all of the AORs in the block were to be handled by the same server. For purposes of efficiency, many of these deployments do not wish to maintain separate registrations for each of the AORs in the block. This leads to the desire for an alternate mechanism for providing dynamic routing information for blocks of AORs.
Because this problem has certain similarities with the REGISTER operation, several non-standard, ad hoc extensions to REGISTER have been developed to address this desire. The document "SIP IP-PBX Registration Problems" [3] (Kaplan, H., “SIP IP-PBX Registration Problems,” December 2009.) describes several deployed IP PBX registration techniques, along with a number of problems that arise from the approaches that have been implemented to date.
Although the use of REGISTER to update reachability information for multiple users simultaneously is somewhat beyond the original semantics defined for REGISTER, this approach has seen significant deployment in certain environments. In particular, deployments in which small to medium SIP PBX servers are addressed using E.164 numbers have used this mechanism to avoid the need to maintain DNS entries or static IP addresses for the PBX servers.
In recognition of the momentum that a REGISTER-based approach has within that relatively narrow ecological niche, this document defines a REGISTER-based approach that is tailored to E.164-addressed extensions in a SIP PBX environment. It is not intended for general-purpose registration of SIP URIs in which the user portion is non-numeric or non-globally-unique.
| TOC |
The following paragraph is perhaps the most important in understanding the solution defined in this document.
Within the problem space that has been established for this work, several constraints shape our solution. These are being defined in the MARTINI requirements document. In terms of impact to the solution at hand, the following two constraints have the most profound effect: (1) The PBX cannot be assumed to be assigned a static IP address; and (2) No DNS entry can be relied upon to consistently resolve to the IP address of the PBX.
| TOC |
This document uses the terms defined in section 2 of "SIP IP-PBX Registration Problems" [3] (Kaplan, H., “SIP IP-PBX Registration Problems,” December 2009.).
| TOC |
The overall mechanism is achieved using a REGISTER request with a specially-formatted Contact URI. This document also defines an option tag that can be used to ensure a registrar and any intermediaries understand the mechanism described herein.
The Contact URI itself is tagged with a URI parameter to indicate that it actually represents a multitude of phone-number-associated contacts.
We also define some lightweight extensions for GRUU to allow the use of public GRUUs assigned by the SSP.
Finally, we non-normatively demonstrate that existing procedures that can be used to generate temporary GRUUs for terminals behind the PBX.
Aside from these extensions, the REGISTER message itself is processed by a registrar in the same way as normal registrations: by updating its location service with additional AOR to Contact bindings.
Note that the list of extensions associated with a PBX is a matter of local provisioning at the SSP and at the PBX. The mechanism defined in this document does not provide any means to detect or recover from provisioning mismatches (although the registration event package can be used as a standardized means for auditing such extensions; see Section 7.2.1 (PBX Aggregate Registration State)).
| TOC |
To register for multiple phone numbers, the PBX sends a REGISTER message to the SSP. This REGISTER varies from a typical register in two important ways. First, it must contain an option tag of "bulk-number-contact" in both a "Require" header field and a "Proxy-Require" header field. Second, in at least one "Contact" header field, it must include a Contact URI that contains the URI parameter "bnc", and no user portion (hence no "@" symbol). A URI with a "bnc" parameter MUST NOT contain a user portion.
Because of the constraints discussed in Section 2 (Constraints), the host portion of the Contact URI will generally contain an IP address, although nothing in this mechanism enforces or relies upon that fact. If the PBX operator chooses to maintain DNS entries that resolve to the IP address of his PBX via RFC 3263 resolution procedures, then this mechanism works just fine with domain names in the Contact header field.
The URI parameter indicates that special interpretation of the Contact URI is necessary: instead of representing a single, concrete Contact URI to be inserted into the location service, it represents a multitude of Contact URIs (one for each associated phone numbers), semantically resulting in a multitude of AOR-to-Contact rows in the location service.
The registrar, upon receipt of a REGISTER message in the foregoing form, will use the value in the "To" header field to identify the PBX for which registration is being requested. It then authenticates the PBX (using, e.g., SIP Digest authentication, mutual TLS, or some other authentication mechanism). After the PBX is authenticated, the registrar updates its location service so that each of the phone numbers associated with the PBX creates a unique AOR to Contact mapping. Semantically, each of these mappings will be treated as a unique row in the location service. The actual implementation may, of course, perform internal optimizations to reduce the amount of memory used to store such information.
For each of these unique rows, the AOR will be in the format that the SSP expects to receive from external parties (e.g. "sip:+12145550102@ssp.example.com"), and the corresponding Contact will be formed adding a user portion to the REGISTER's Contact URI containing the fully-qualified, E.164-formatted phone number (including the preceding "+" symbol) and removing the "bnc" parameter. For example, if the "Contact" header field contains the URI <sip:198.51.100.3:5060;user=phone;bnc>, then the Contact value associated with the aforementioned AOR will be <sip:+12145550102@198.51.100.3:5060;user=phone>.
Aside from the "bnc" parameter, all URI parameters present on the "Contact" URI in the REGISTER message MUST be copied to the Contact value stored in the location service.
| TOC |
In general, after processing the AOR to Contact mapping described in the preceding section, the SSP Proxy/Registrar (or equivalent entity) performs traditional Proxy/Registrar behavior, based in such mapping. For inbound SIP requests whose AOR indicates an E.164 number assigned to one of the SSP's customers, this will generally involve setting the target set to the registered contacts associated with that AOR, and performing request forwarding as described in section 16.6 of RFC 3261.
| TOC |
The following sections describe the means by which this mechanism interacts with relevant REGISTER-related extensions currently defined by the IETF.
Currently, the descriptions are somewhat informal, and omit some details for the sake of brevity. If the MARTINI working group expresses interest in furthering the mechanism described by this document, they will be fleshed out with more detail and formality.
| TOC |
To enable advanced services to work with extensions behind a SIP PBX, it is important that the GRUU mechanism defined by RFC 5627 [8] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP),” October 2009.) work correctly with the mechanism defined by this document.
| TOC |
When a PBX registers a Bulk Number Contact (a Contact with a "bnc" parameter), and also invokes GRUU procedures for that Contact during registration, then the SSP will assign a public GRUU to the PBX in the normal fashion. Because the URI being registered contains a "bnc" parameter, the GRUU will also contain a "bnc" parameter. In particular, this means that the GRUU will not contain a user portion.
When a terminal registers with the PBX using GRUU procedures for a Contact, it adds an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SSP can use to route the request to the proper user agent.
So, for example, when the PBX registers the with the following contact header field:
Contact: <sip:198.51.100.3;user=phone;bnc>; +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Then the SSP may choose to respond with a Contact header field that looks like this:
<allOneLine> Contact: <sip:198.51.100.3;user=phone;bnc>; pub-gruu="sip:ssp.example.com;gr=urn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"; +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" ;expires=7200 </allOneLine>
When its own terminals register, the PBX can then add whatever device identifier it feels appropriate in an "sg" parameter, and present this value to its own terminals. For example, assume the extension associated with the phone number "+12145550102" sent the following Contact header field in its register:
Contact: <sip:line-1@10.20.1.17>; +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
The PBX will add an "sg" parameter to the pub-gruu it received from the SSP with a token that uniquely identifies the device (possibly the URN itself; possible some other identifier); insert a user portion containing the fully-qualified E.164 number associated with the extension; and return the result to the terminal as its public GRUU. This resulting Contact header field would look something like this:
<allOneLine> Contact: <sip:line-1@10.20.1.17>; pub-gruu="sip:+12145550102@ssp.example.com;gr=urn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6"; +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" ;expires=3600 </allOneLine>
When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than a Proxy/Registrar would. When the GRUU is re-targeted to the registered bulk number contact, the SSP MUST copy the "sg" parameter from the GRUU to the new target. The PBX can then use this "sg" parameter to determine which user agent the request should be routed to.
| TOC |
PBXes have two options for creating temporary GRUUs for use by its terminals.
| TOC |
If a PBX wishes to provide temporary GRUUs for its terminals, it may do so by producing its own "Self-made GRUUs" (as defined in section 4.3 of RFC 5627). These GRUUs are produced using the PBX's own IP address (or domain, if it maintains one in DNS). The temporary GRUUs are then propagated to terminals using normal GRUU mechanism.
The ability to produce temporary GRUUs in this fashion is predicated on the conditions described in section 4.3 of RFC 5627. In particular, it requires PBX to be publicly routable, and willing to accept requests destined for its own Self-made GRUUs from sources other than the SSP. If these conditions cannot be satisfied (or the PBX operator chooses not to satisfy them for policy reasons), then the PBX users will not be able to make use of temporary GRUUs.
This mechanism is also predicated on the IP address for the PBX being relatively stable over long period of time. This is generally a safe assumption to make, as frequent PBX IP address changes will result in intermittent connectivity issues and interruptions to ongoing calls.
On a related note: when used with this extension, the SSP will not return a temporary GRUU in the registration response for any contacts that include a "bnc" parameter in their URI.
For example, using the same setup as in the "Public GRUU" section above, an extensions registering with the PBX might obtain a temp gruu by receiving a Contact header field that looks like:
| TOC |
If a PBX does not satisfy the criteria for producing its own "Self-made GRUUs," then it may create temporary GRUUs based on the public GRUUs it received from the SSP at registration time. To create Temporary GRUUs of this form, the PBX will add an opaque "sg" parameter to the public GRUU it received from the SSP, and will omit the user portion.
Note that, because these GRUUs are temporary GRUUs, a unique "sg" parameter will be generated for each successful registration attempt. The PBX tracks the various "sg" values associated with each user agent, and can re-target to the correct instance when the request arrives.
For this approach to function, the SSP must be able to resolve a GRUU based solely on the value of its "gr" parameter, as the user portion of the GRUU will not contain an E.164 number. Further, the SSP will not know which actual extension the request is destined for, only that it corresponds to an extension belonging to the PBX.
Using the same basic setup as the example for the public GRUU, a terminal might receive a temporary GRUU by getting back a Contact header field that looks like this:
<allOneLine> Contact: <sip:line-1@10.20.1.17>; temp-gruu="sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765- 00a0c91e6bf6;sg=0UYYRV046P";+sip.instance="<urn:uuid:d0e2f290-104b- 11df-8a39-0800200c9a66>";expires=3600 </allOneLine>
| TOC |
As this mechanism inherently deals with REGISTER behavior, it is imperative to consider its impact on the Registration Event Package defined by RFC 3680 [6] (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.). In practice, there will be two main use cases for subscribing to registration data: learning about the overall registration state for the PBX, and learning about the registration state for a single PBX extension.
| TOC |
If the PBX (or another interested and authorized party) wishes to monitor or audit the registration state for all of the extensions currently registered to that PBX, it can subscribe to the SIP registration event package at the PBX's main URI -- that is, the URI used in the "To" header field of the REGISTER message.
The NOTIFY messages for such a subscription will contain a body that contains one record for each phone number associated with the PBX. The AORs will be in the format expected to be received by the SSP (e.g., "sip:+12145550105@ssp.example.com"), and the Contacts will correspond to the mapped Contact created by the registration (e.g., "sip:+12145550105@98.51.100.3").
In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event notify.
| TOC |
If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then it MUST proxy that SUBSCRIBE to the PBX in the same way that is would proxy an INVITE bound for that AOR.
Defining the behavior in this way is important, since the reg-event subscriber is interested in finding out about the comprehensive list of devices associated with the phone number. Only the PBX will have authoritative access to this information. For example, if the user has registered multiple terminals with differing capabilities, the SSP will not know about the devices or their capabilities. By contrast, the PBX will.
| TOC |
RFC 5626 [7] (Jennings, C., Mahy, R., and F. Audet, “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP),” October 2009.) -- needs analysis. Some people think it might "just work."
| TOC |
RFC 3327 [4] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.) -- needs analysis. Some people think it might "just work."
| TOC |
RFC 3608 [5] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” October 2003.) -- needs analysis. Some people think it might "just work."
| TOC |
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. The current sections represents what we have been calling "Use Cases" on the MARTINI mailing list; however, it has been pointed out that the things we were calling "Use Cases" were not, actually "Use Cases" as much as they were potential modes of operation. To avoid the baggage around any pre-existing terms, we are referring to these items as "Wumpuses" for the time being.
| TOC |
This example shows a basic bulk REGISTER transaction, followed by an INVITE addressed to one of the registered terminals.
Internet SSP PBX | | | | |REGISTER | | |Contact:<sip:198.51.100.3;bnc> | | |<--------------------------------| | | | | |200 OK | | |-------------------------------->| | | | |INVITE | | |sip:+12145550105@ssp.example.com| | |------------------------------->| | | | | | |INVITE | | |sip:+12145550105@198.51.100.3 | | |-------------------------------->|
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:pbx@ssp.example.com> From: <sip:pbx@ssp.example.com>;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Require: bulk-number-contact Contact: <sip:198.51.100.3:5060;user=phone;bnc> Expires: 7200 Content-Length: 0
INVITE sip:+12145550105@ssp.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Max-Forwards: 69 To: <sip:2145550105@some-other-place.example.net> From: <sip:gsmith@example.org>;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 INVITE Contact: <sip:line-1@192.0.2.178:2081> Content-Type: application/sdp Content-Length: ... <sdp body here>
INVITE sip:+12145550105@198.51.100.3;user=phone SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 Max-Forwards: 68 To: <sip:2145550105@some-other-place.example.net> From: <sip:gsmith@example.org>;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 24762 INVITE Contact: <sip:line-1@192.0.2.178:2081> Content-Type: application/sdp Content-Length: ... <sdp body here>
| TOC |
This example shows a bulk REGISTER transaction with the SSP making use of the "Path" header field extension [4] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.). This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the PBX from when the SSP applies RFC 3263 procedures to it.
Internet SSP PBX | | | | |REGISTER | | |Path:<sip:pbx@198.51.100.3;lr> | | |Contact:<sip:pbx.example;bnc> | | |<--------------------------------| | | | | |200 OK | | |-------------------------------->| | | | |INVITE | | |sip:+12145550105@ssp.example.com| | |------------------------------->| | | | | | |INVITE | | |sip:+12145550105@pbx.example | | |Route:<sip:pbx@198.51.100.3;lr> | | |-------------------------------->|
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:pbx@ssp.example.com> From: <sip:pbx@ssp.example.com>;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Require: bulk-number-contact Path: <sip:pbx@198.51.100.3:5060;lr> Contact: <sip:pbx.example;user=phone;bnc> Expires: 7200 Content-Length: 0
INVITE sip:+12145550105@ssp.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Max-Forwards: 69 To: <sip:2145550105@some-other-place.example.net> From: <sip:gsmith@example.org>;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 INVITE Contact: <sip:line-1@192.0.2.178:2081> Content-Type: application/sdp Content-Length: ... <sdp body here>
INVITE sip:+12145550105@pbx.example;user=phone SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 Route: <sip:pbx@198.51.100.3:5060;lr> Max-Forwards: 68 To: <sip:2145550105@some-other-place.example.net> From: <sip:gsmith@example.org>;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 24762 INVITE Contact: <sip:line-1@192.0.2.178:2081> Content-Type: application/sdp Content-Length: ... <sdp body here>
| TOC |
The document "SIP IP-PBX Registration Problems" [3] (Kaplan, H., “SIP IP-PBX Registration Problems,” December 2009.) describes a number of problems that arise in the ad hoc solutions currently deployed. This section evaluates these issues against the mechanism proposed in this document.
- No Explicit Indicator:
- This mechanism includes both an explicit indicator that the mechanism must be applied (a new "bulk-number-contact" option tag) as well as a specific protocol marker that indicates exactly where the extension is to be applied (the "bnc" URI parameter).
- Undefined Behavior on PAU Mismatch:
- This mechanism does not propose the use of P-Associated-URI in the REGISTER response as an integral part of the document. PBXes that wish to learn registration information for its associated extensions may subscribe to their own registration state, as described in Section 7.2.1 (PBX Aggregate Registration State).
- REGISTER Response Growth:
- This mechanism does not propose the use of P-Associated-URI in the REGISTER response as an integral part of the document. PBXes that wish to learn registration information for its associated extensions may subscribe to their own registration state, as described in Section 7.2.1 (PBX Aggregate Registration State).
- Illegal Wildcarding Syntax:
- Rather than defining a general-purpose wild-carding syntax, this mechanism defines a very lightweight syntax for indication of where E.164 numbers are to be substituted in Contact URIs.
- Loss of Target Info:
- Because the binding from AOR to Contact URI is under control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Target information is preserved.
- Request-URI vs. Loose-Route Mismatches:
- As before: because the binding from AOR to Contact URI is under control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Loose routing and Request-URI handling are kept consistent with proxy/registrar handling described in RFC 3261, so no mismatches can arise.
- Authorization Policy Mismatches:
- Because the binding from AOR to Contact URI is under control of the publisher, it can ensure that the Contact URI associated with an AOR matches the Contact URIs it uses for outgoing calls. This eliminates the authorization policy mismatches described.
- P-Asserted-Identity Mismatches:
- Because the information published by this mechanism inherently mimics individual registration for each of the associated AORs, the expectation that each of these AORs can be used as a P-Asserted-Identity is preserved, avoiding any implementation confusion regarding valid values for this field.
- Trust Domain Mismatches for Privacy/Identity:
- The MARTINI working group appears to be reaching rough consensus that this issue is out of scope and out of charter for solutions it is responsible for considering. It is not analyzed with respect to the proposed solution.
| TOC |
This isn't even close to finished. It's here to remind me that there are IANA impacts.
| TOC |
bulk-number-contact
| TOC |
bnc, sg
| TOC |
| TOC |
| [1] | 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 (TXT). |
| [2] | Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” RFC 3263, June 2002 (TXT). |
| TOC |
| [3] | Kaplan, H., “SIP IP-PBX Registration Problems,” draft-kaplan-martini-mixing-problems-00 (work in progress), December 2009 (TXT). |
| [4] | Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” RFC 3327, December 2002 (TXT). |
| [5] | Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” RFC 3608, October 2003 (TXT). |
| [6] | Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” RFC 3680, March 2004 (TXT). |
| [7] | Jennings, C., Mahy, R., and F. Audet, “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP),” RFC 5626, October 2009 (TXT). |
| [8] | Rosenberg, J., “Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP),” RFC 5627, October 2009 (TXT). |
| TOC |
| Adam Roach | |
| Tekelec | |
| 17210 Campbell Rd. | |
| Suite 250 | |
| Dallas, TX 75252 | |
| US | |
| Email: | adam@nostrum.com |