RFC 6140

Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)

📅 published March 2011, from ietf

📞 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) 💖

RFC 6140 🎀 is a Standards Track doc from March 2011 (ISSN 2070-1721). The author is A.B. Roach from Tekelec ✨. It updates RFC 3680 🦋, so it's basically adding to that one.

Abstract ✨

okay so this doc defines a way for a SIP server acting as a traditional PBX (Private Branch Exchange) to register with a SIP Service Provider (SSP) so it can get phone calls meant for SIP User Agents (UAs) 📞🎀. the bestie requirement here is that every AOR (Address of Record) registered in bulk has to map to its own unique set of contacts 💅. AORs that are phone numbers pass that test no matter the domain, bc phone numbers are fully qualified and globally unique 🌸. so the doc focuses on that use case 🫶.

Status of This Memo 📋

This is an Internet Standards Track document.

The IETF produced this doc 🌈. it has IETF community consensus 💜, got public review, and the IESG approved it for publication 👑. for more on Internet Standards, check Section 2 of RFC 5741 ✨.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6140 🦋.

Copyright Notice ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date 📜. read those carefully, bc they spell out your rights and restrictions for this doc 🙈. any Code Components pulled from this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🫶.

Table of Contents 🗂️

   1. Introduction ....................................................3
   2. Constraints .....................................................3
   3. Terminology and Conventions .....................................4
   4. Mechanism Overview ..............................................5
   5. Registering for Multiple Phone Numbers ..........................5
      5.1. SIP-PBX Behavior ...........................................5
      5.2. Registrar Behavior .........................................6
      5.3. SIP URI "user" Parameter Handling ..........................8
   6. SSP Processing of Inbound Requests ..............................8
   7. Interaction with Other Mechanisms ...............................9
      7.1. Globally Routable User Agent URIs (GRUU) ...................9
           7.1.1. Public GRUUs ........................................9
           7.1.2. Temporary GRUUs ....................................11
      7.2. Registration Event Package ................................16
           7.2.1. SIP-PBX Aggregate Registration State ...............16
           7.2.2. Individual AOR Registration State ..................16
      7.3. Client-Initiated (Outbound) Connections ...................18
      7.4. Non-Adjacent Contact Registration (Path) and
           Service-Route Discovery ...................................19
   8. Examples .......................................................20
      8.1. Usage Scenario: Basic Registration ........................20
      8.2. Usage Scenario: Using Path to Control Request URI .........22
   9. IANA Considerations ............................................24
      9.1. New SIP Option Tag ........................................24
      9.2. New SIP URI Parameters ....................................25
           9.2.1. 'bnc' SIP URI Parameter ............................25
           9.2.2. 'sg' SIP URI Parameter .............................25
      9.3. New SIP Header Field Parameter ............................25
   10. Security Considerations .......................................25
   11. Acknowledgements ..............................................28
   12. References ....................................................28
      12.1. Normative References .....................................28
      12.2. Informative References ...................................29
   Appendix A. Requirements Analysis .................................31

1. Introduction ✨

SIP (the Session Initiation Protocol) is an application-layer control (signaling) protocol 🎀. it's how you create, modify, and terminate sessions with one or more participants 📞. one of its biggest jobs is rendezvous, which means helping users find each other 🫶. traditionally, that's done by combining the server look-up procedures in RFC 3263 [4] with the registrar procedures in RFC 3261 [3] 💅.

the original plan was that any user's AOR would be handled by whatever authority the hostport part of the AOR points to 🌸. users would register their own reachability info with that authority, and the authority would route incoming requests to them 🦋.

in the real world 🌍, some SIP servers have architectures where they need dynamic routing info for big blocks of AORs, and every AOR in a block is handled by the same server 🍓. for efficiency, lots of these deployments don't want a separate registration for each AOR in the block 💜. so there's a real need for another way to give dynamic routing info for blocks of AORs 🙌.

Using a single REGISTER request to update reachability for multiple users at once is kinda beyond what RFC 3261 [3] originally had in mind for REGISTER requests 🙈. but this approach has taken off in certain environments 🔥. the big one is small-to-medium SIP-PBX servers addressed with E.164 numbers 📱. they use it to avoid needing DNS entries or static IP addresses for the SIP-PBX servers 💖.

because REGISTER-based approaches have this much momentum in deployments, this doc defines one too 🌈. E.164-addressed UAs are super common in SIP-PBX environments today 💅. and SIP URIs where the user portion is an E.164 number are always globally unique, whatever the domain is ✨. so this doc focuses on registering SIP URIs whose user portion is an E.164 number 🫶.

2. Constraints 🚧

the problem space for this work comes with several constraints that shape the solution 🧩. they're defined in the MARTINI requirements document [22] and analyzed in Appendix A 📚. the two that matter most for the solution are: (1) the SIP-PBX can't be assumed to have a static IP address 🙈; and (2) no DNS entry can be relied on to consistently resolve to the SIP-PBX's IP address 💀.

3. Terminology and Conventions 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] 💜.

also, "SSP" is short for "SIP Service Provider," and "SIP-PBX" means a SIP Private Branch Exchange 🎀.

Indented portions of the document, like this one, are non-normative, explanatory sections 🦋.

some of the examples here can't be rendered unambiguously without extra markup, bc RFCs have strict formatting rules 🌸. SIP is text-based, so this doc uses the <allOneLine/> markup convention from RFC 4475 [17] to avoid ambiguity and meet the RFC layout requirements ✨. for completeness, the text defining that markup (Section 2.1 of RFC 4475 [17]) gets repeated below 📜.

Several of these examples have unfolded lines longer than 72 characters 📏. those get wrapped in <allOneLine/> tags. to rebuild the single unfolded line, you directly concatenate all the lines between the tags, throwing away any line feeds or carriage returns 🧹. there's never whitespace at the end of a line 💅. any whitespace sitting at a fold-point shows up at the start of the next line 🫶. these all represent the same string of bits: Header-name: first value, reallylongsecondvalue, third value <allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine> <allOneLine> Header-name: first value, reallylong second value, third value </allOneLine> Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning. 🙈

4. Mechanism Overview 🌸

the whole mechanism runs on a REGISTER request with a specially formatted Contact URI 💌. this doc also defines an option tag, so registrars and any intermediaries can make sure they understand the mechanism 🫶.

the Contact URI itself has a URI parameter that tells you it actually stands for multiple phone-number-associated contacts 🎀.

we also add some lightweight extensions to the GRUU (Globally Routable UA URIs) mechanism from RFC 5627 [20], so the SSP can assign public and temporary GRUUs 🦋.

other than those extensions, the registrar handles the REGISTER request like any normal registration: it updates its location service with more AOR-to-Contact bindings 💜.

the list of AORs tied to a SIP-PBX is a matter of local provisioning at the SSP and the SIP-PBX 🧾. this mechanism doesn't give you any way to detect or recover from provisioning mismatches 😭. (the registration event package can be used as a standardized way to audit those AORs, see Section 7.2.1 ✨.)

5. Registering for Multiple Phone Numbers 📞💖

5.1. SIP-PBX Behavior 📞✨

okay so to register for multiple AORs, the SIP-PBX sends a REGISTER request to the SSP. this REGISTER request is giving "different" in two big ways 💅 First, it MUST contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. (the option tag "gin" is short for "generate implicit numbers" 🧚)

Second, in at least one "Contact" header field, it MUST include a Contact URI that contains the URI parameter "bnc" (bulk number contact 🍓) and has no user portion, so no "@" symbol. a URI with a "bnc" parameter MUST NOT contain a user portion. apart from the SIP URI "user" parameter, this URI MAY contain any other parameters the SIP-PBX wants 🎀. the SSP echoes those parameters back in any requests bound for the SIP-PBX.

because of the constraints in Section 2, the host portion of the Contact URI will usually contain an IP address 🌸. nothing in this mechanism enforces or relies on that, though. if the SIP-PBX operator decides to keep DNS entries that resolve to the IP address of their SIP-PBX via RFC 3263 resolution procedures, this mechanism works just fine with domain names in the "Contact" header field 🫶.

the "bnc" URI parameter tells everyone that the Contact URI needs special treatment. instead of inserting one Contact URI into the location service, it means that multiple URIs (one for each associated AOR) should be inserted 🦋.

any SIP-PBX that implements the registration mechanism in this document MUST also support the path mechanism defined by RFC 3327 [10], and MUST include a 'path' option tag in the "Supported" header field of the REGISTER request. (this is a stronger requirement than the path mechanism itself imposes 👑) this is necessary because proxies between the SIP-PBX and the registrar may need to insert "Path" header field values in the REGISTER request for this document's mechanism to work properly. per RFC 3327 [10], they can only do that if the User Agent Client (UAC) put the option tag in the "Supported" header field. following the procedures in RFC 3327 [10], the SIP-PBX is allowed to ignore the "Path" header fields returned in the REGISTER response 💅.

5.2. Registrar Behavior 🗂️

the registrar, once it gets a REGISTER request with at least one "Contact" header field that has a "bnc" parameter, uses the value in the "To" header field to figure out which SIP-PBX is registering 🔍. then it authenticates the SIP-PBX (for example, with SIP digest authentication, mutual Transport Layer Security (TLS) [18], or some other authentication mechanism). after the SIP-PBX is authenticated, the registrar updates its location service with a unique AOR-to-Contact mapping for each of the AORs linked to the SIP-PBX. semantically, each of these mappings is treated as a unique row in the location service. the actual implementation can, of course, do internal optimizations to cut down on the memory used to store all this 🧠.

for each of these unique rows, the AOR is in the format the SSP expects to receive from external parties (for example, "sip:+12145550102@ssp.example.com"). the matching contact is made by adding a user portion to the REGISTER request's Contact URI. that user portion holds the fully qualified, E.164-formatted number (including the leading "+" symbol), and the "bnc" parameter gets removed 🪄. apart from that initial "+" symbol, this E.164-formatted number MUST consist exclusively of digits from 0 through 9 and explicitly MUST NOT contain any visual separator symbols (for example, "-", ".", "(", or ")"). for instance, if the "Contact" header field contains the URI <sip:198.51.100.3:5060;bnc>, then the contact value for the AOR above is <sip:+12145550102@198.51.100.3:5060> 🌈.

even though the SSP treats this registration as a bunch of discrete rows when it re-targets incoming requests, the renewal, expiration, and removal of those rows is tied to the registered contact 💜. this means that REGISTER requests trying to de-register a single AOR that was implicitly registered MUST NOT remove that AOR from the bulk registration. in this situation, the registrar just acts like the UA tried to unregister a contact that wasn't actually registered (for example, it returns the list of currently registered contacts in a success response) 🙈. a related point is that an individual extension that was implicitly registered can also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). if that registration exists, it's refreshed independently of the bulk registration and doesn't get removed when the bulk registration is removed ✨.

a registrar that gets a REGISTER request with a Contact URI that has both a "bnc" parameter and a user portion MUST NOT send a 200-class (Success) response 🚫. if no other error applies, the registrar can use a 400 (Bad Request) response to flag this 💀.

note that the paragraph above is talking about the user portion of a URI, so look right here 👀:

      sip:+12145550100@example.com
          ^^^^^^^^^^^^

a registrar that follows this document MUST support the path mechanism defined in RFC 3327 [10]. the reasoning behind supporting this mechanism is in Section 5.1 🔁.

apart from the "bnc" parameter, all URI parameters on the Contact URI in the REGISTER request MUST be copied to the contact value stored in the location service 🎀.

if the SSP servers do processing based on User Agent Capabilities (as defined in RFC 3840 [13]), they treat any feature tags on a "Contact" header field with a "bnc" parameter in its URI as applying to all of the resulting AOR-to-Contact mappings 🌟. the same goes for option tags on the REGISTER request that signal special handling for later requests. those apply to all of the AOR-to-Contact mappings too 🫧.

5.3. SIP URI "user" Parameter Handling 🧩

this document doesn't change the behavior that RFC 3261 [3] specifies for including the "user" parameter on Request URIs 💭. however, to avoid any confusion at the SIP-PBX, the following normative behavior is imposed on how it interacts with the SSP 🔒.

when a SIP-PBX registers with an SSP using a Contact URI that has a "bnc" parameter, that Contact URI MUST NOT include a "user" parameter. a registrar that gets a REGISTER request with a Contact URI that has both a "bnc" parameter and a "user" parameter MUST NOT send a 200-class (success) response. if no other error applies, the registrar can use a 400 (Bad Request) response to flag this 🙅‍♀️.

note that the paragraph above is talking about the "user" parameter of a URI, so check the caret line 👀:

      sip:+12145550100@example.com;user=phone
                                   ^^^^^^^^^^

when a SIP-PBX receives a request from an SSP, and the Request URI has a user portion that matches an AOR registered using a Contact URI with a "bnc" parameter, then the SIP-PBX MUST NOT reject the request (or otherwise make it fail) because of the absence, presence, or value of a "user" parameter on the Request URI 🥹.

6. SSP Processing of Inbound Requests 📥

generally, after the SSP handles the AOR-to-Contact mapping from the previous section, the SSP proxy/registrar (or equivalent entity) does its usual proxy/registrar thing, based on that mapping 🪩. for any inbound SIP request whose AOR points to an E.164 number assigned to one of the SSP's customers, this usually means setting the target set to the registered contacts linked to that AOR and forwarding the request the way Section 16.6 of RFC 3261 [3] describes 💌.

an SSP that uses the mechanism in this document MUST do that processing for inbound INVITE requests and for SUBSCRIBE requests to the "reg" event package (see Section 7.2.2) 📞. it SHOULD do the same processing for all other method types, including unrecognized SIP methods 🌷.

7. Interaction with Other Mechanisms 🤝

the following sections explain how this mechanism works alongside the REGISTER-related extensions the IETF has defined so far 🦋.

7.1. Globally Routable User Agent URIs (GRUU) 🌍

advanced services need to work with UAs behind a SIP-PBX, so it's super important that the GRUU mechanism defined by RFC 5627 [20] works correctly with this document's mechanism 😭. basically, user agents served by the SIP-PBX should be able to acquire and use GRUUs for their own use 👑✨.

7.1.1. Public GRUUs ✨

okay bestie, public GRUUs are OPTIONAL for SSPs and SIP-PBXes 🫶 so you don't have to build them if you don't want to.

Here's the vibe when a SIP-PBX registers a Bulk Number Contact (that's a contact with a bnc parameter) and also uses GRUU procedures for that contact during registration 💅 The SSP gives the SIP-PBX a public GRUU in the normal way. Since the URI being registered has a bnc parameter, the GRUU gets a bnc parameter too. That means the GRUU has no user portion, which is lowkey important 👀

When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX hands the UA a public GRUU made by adding an sg parameter to the GRUU it got from the SSP. That sg parameter holds a disambiguation token, and the SIP-PBX uses it to route inbound requests to the correct UA 🎀

Here's an example. Say the SIP-PBX registers with this Contact header field:

Contact: <sip:198.51.100.3;bnc>;
  +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

The SSP may respond with a Contact header field that looks like this:

Contact: <sip:198.51.100.3;bnc>;
pub-gruu="sip:ssp.example.com;bnc;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200

Now the SIP-PBX can add whatever device identifier it likes in an sg parameter when its own UAs register with GRUU procedures, and then share that value with them 🧚 For example, suppose the UA associated with the AOR +12145550102 sent this Contact header field in its REGISTER request:

Contact: <sip:line-1@10.20.1.17>;
  +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"

The SIP-PBX adds an sg parameter to the pub-gruu it got from the SSP. The token can uniquely identify the device (it could be the URN itself, or some other identifier). It also inserts a user portion with the fully qualified E.164 number tied to the UA, and then sends the result back to the UA as its public GRUU 💖 The Contact header field the SIP-PBX sends to the registering UA would look something like this:

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

When an incoming request reaches the SSP for a GRUU that matches a bulk number contact (bnc), the SSP does something a little different than it would for a URI without a bnc parameter 🦋 When the GRUU gets re-targeted to the registered bulk number contact, the SSP MUST copy the sg parameter from the GRUU over to the new target. That's how the SIP-PBX knows which user agent the request is for. For example, the first line of an INVITE request re-targeted to the SIP-PBX for the UA above would look like this:

INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0

7.1.2. Temporary GRUUs 🔥

Privacy is a whole mood, so the SSP SHOULD implement the temporary GRUU mechanism described in this section 🌈 The exception would be a system that has some other privacy mechanism which keeps public GRUUs intact. For instance, if public GRUUs get anonymized, the anonymizer would need to be able to hand back, as the anonymized URI, a globally routable URI that only routes back to the target identified by the original public GRUU.

Temporary GRUUs exist to keep the party who creates and shares the GRUU anonymous. If someone can tell that two temporary GRUUs came from behind the same SIP-PBX, that breaks the anonymity 😭 So instead of using one invariant identifier for the SIP-PBX in its UAs' temporary GRUUs, we define a mechanism where the SSP gives the SIP-PBX enough info to mint unique temporary GRUUs. The SSP can match them back to the right SIP-PBX, but nobody else can ✨ To get there, we use a slight modification of the procedure in Appendix A.2 of RFC 5627 [20].

The SIP-PBX has to be able to build a temp-gruu that the SSP can decode 🍓 To make sure the SSP can decode GRUUs, we need to standardize the algorithm the SIP-PBX uses to create temp-gruus. That lets the SSP run the algorithm in reverse and find the registration entry that matches the GRUU.

It matters just as much that no party except the SSP can decode a temporary GRUU, and that includes other SIP-PBXes the SSP serves 🙈 To get this, an SSP that supports temporary GRUUs MUST create and store an asymmetric key pair: {K_e1,K_e2}. K_e1 stays secret with the SSP, while K_e2 is shared with the SIP-PBXes through provisioning.

All base64 encoding discussed in the following sections MUST use the character set and encoding defined in Section 4 of RFC 4648 [8], except that any trailing "=" characters are discarded on encoding and added as necessary to decode 💜

The following sections use the term "HMAC-SHA256-80" to describe a specific Hashed Message Authentication Code (HMAC) algorithm. In this document, HMAC-SHA256-80 is defined as applying the SHA-256 [24] secure hashing algorithm and truncating the result to 80 bits by discarding the trailing (least-significant) bits.

An SSP that supports temporary GRUUs MUST include a "temp-gruu-cookie" parameter on all "Contact" header fields that contain a "bnc" parameter in a 200-class REGISTER response. This "temp-gruu-cookie" MUST have the following properties:

It can be used by the SSP to uniquely identify the registration to which it corresponds.
It is encoded using base64. This allows the SIP-PBX to decode it into as compact a form as possible for use in its calculations.
It is of a fixed length. This allows for its extraction once the SIP-PBX has concatenated a distinguisher onto it.
The temp-gruu-cookie MUST NOT be forgeable by any party. In other words, the SSP needs to be able to examine the cookie and validate that it was generated by the SSP.
The temp-gruu-cookie MUST be invariant during the course of a registration, including any refreshes to that registration. This property is important, as it allows the SIP-PBX to examine the temp-gruu-cookie to determine whether the temp-gruus it has issued to its UAs are still valid.

The above properties can be met using the following algorithm, which is non-normative. Implementors may chose to implement any algorithm of their choosing for generation of the temp-gruu-cookie, as long as it fulfills the five properties listed above.

   The registrar maintains a counter, I.  This counter is 48 bits
   long and initialized to zero.  This counter is persistently
   stored, using a back-end database or similar technique.  When the
   registrar creates the first temporary GRUU for a particular SIP-
   PBX and instance ID (as defined by [20]), the registrar notes the
   current value of the counter, I_i, and increments the counter in
   the database.  The registrar then maps I_i to the contact and
   instance ID using the database, a persistent hash-map, or similar
   technology.  If the registration expires such that there are no
   longer any contacts with that particular instance ID bound to the
   GRUU, the registrar removes the mapping.  Similarly, if the
   temporary GRUUs are invalidated due to a change in Call-ID, the
   registrar removes the current mapping from I_i to the AOR and
   instance ID, notes the current value of the counter I_j, and
   stores a mapping from I_j to the contact containing a "bnc"
   parameter and instance ID.  Based on these rules, the hash-map
   will contain a single mapping for each contact containing a "bnc"
   parameter and instance ID for which there is a currently valid
   registration.

   The registrar maintains a symmetric key SK_a, which is regenerated
   every time the counter rolls over or is reset.  When the counter
   rolls over or is reset, the registrar remembers the old value of
   SK_a for a while.  To generate a temp-gruu-cookie, the registrar
   computes:

      SA = HMAC(SK_a, I_i)
      temp-gruu-cookie = base64enc(I_i || SA)

   where || denotes concatenation.  "HMAC" represents any suitably
   strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC
   algorithms.  One suitable HMAC algorithm for this purpose is HMAC-
   SHA256-80.

7.1.2.2. Generation of temp-gruu by the SIP-PBX ✨

okay so, according to Section 3.2 of RFC 5627 [20], every registration refresh makes a brand-new temp-gruu, and that new temp-gruu stays valid for as long as the contact is registered 🦋 this is literally the core of why temp-gruu is so private, and the UAs that do temp-gruu are counting on it. Nothing in this document changes that property in any way, so don't let anyone tell you otherwise 💅 SIP-PBXes that do temporary GRUUs MUST generate a new temp-gruu using the steps in this section for every registration or registration refresh from GRUU-supporting UAs attached to the SIP-PBX. no skipping, bestie 🫶

Also, if the registration the SIP-PBX has with its SSP expires or gets terminated, the temp-gruu cookie it keeps with the SSP changes too 😭 and that change wipes out every temp-gruu the SIP-PBX has handed to its UAs. If the SIP-PBX tracks this (for example, to put <temp-gruu> elements into registration event bodies, like RFC 5628 [9] describes), it can tell the old temp-gruus are dead just by noticing that the temp-gruu-cookie the SSP gave it has changed 👑

A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an HMAC key: PK_a. This is the value used to check that an incoming GRUU was actually generated by the SIP-PBX 🔐

Now, to make a fresh temporary GRUU for its own UAs, the SIP-PBX MUST generate a random distinguisher value: D. How long D is up to the implementor, but it MUST be long enough to keep all the temporary GRUUs the SIP-PBX has issued from colliding. A size of 80 bits or longer is RECOMMENDED 🌸 For more on generating random numbers in a security context, check RFC 4086 [16]. Once D is generated, the SIP-PBX MUST calculate:

  M    = base64dec(SSP-cookie) || D
  E    = RSA-Encrypt(K_e2, M)
  PA   = HMAC(PK_a, E)

  Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)

where || means concatenation. "HMAC" can be any suitably strong HMAC algorithm, and RFC 2104 [1] talks through HMAC algorithms if you want the deep dive 🧚 One suitable HMAC algorithm for this is HMAC-SHA256-80.

Last step: the SIP-PBX adds a "gr" parameter to the temporary GRUU. This is what can be used to uniquely identify the UA registration record that the GRUU belongs to. How the "gr" parameter gets generated is up to the implementor, as long as it still has the properties of a GRUU described in RFC 5627 [20] ✨

One valid way to make the "gr" parameter is to calculate "E" and "A" the way Appendix A.2 of RFC 5627 [20] describes, then form the "gr" parameter like this: gr = base64enc(E) || base64enc(A)

Using this procedure might give the registering UA a temporary GRUU from the SIP-PBX that looks something like this 🍓

<allOneLine>
Contact: <sip:line-1@10.20.1.17>
;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>

7.1.2.3. Decoding of temp-gruu by the SSP 🔍

When the SSP proxy gets a request where the user part starts with "tgruu.", it pulls out the rest and splits it at the "." character into E' and PA'. It throws away PA'. Then it works out E by base64 decoding E'. Next, it computes:

  M = RSA-Decrypt(K_e1, E)

The SSP proxy grabs the fixed-length temp-gruu-cookie information from the start of this M and tosses the rest (that leftover part is the distinguisher the SIP-PBX added). Then it validates this temp-gruu-cookie. If it's valid, the SSP uses it to find the matching SIP-PBX registration record and routes the message to the right place 💖

If the non-normative, exemplary algorithm from Section 7.1.2.1 was used to generate the temp-gruu-cookie, then the identification works like this: the temp-gruu-cookie information gets split into its 48-bit counter I and its 80-bit HMAC. The SSP checks that the HMAC matches counter I, then uses counter I to look up the SIP-PBX registration record in its map. If the counter has rolled over or been reset, the check gets done with the current and previous SK_a.

7.1.2.4. Decoding of temp-gruu by the SIP-PBX 🦄

When the SIP-PBX gets a request where the user part starts with "tgruu.", it pulls out the rest and splits it at the "." character into E' and PA'. Then it computes E and PA by base64 decoding E' and PA', respectively. Next, it computes:

  PAc = HMAC(PK_a, E)

where HMAC is the HMAC algorithm used in the steps from Section 7.1.2.2. If this computed PAc doesn't match the PA value pulled out of the GRUU, then that GRUU gets rejected as invalid 🙅‍♀️

Once that checks out, the SIP-PBX uses the "gr" parameter to find the UA registration the GRUU belongs to, and routes the message accordingly ✨

7.2. Registration Event Package 📮

Neither the SSP nor the SIP-PBX is required to support the registration event package defined by RFC 3680 [12]. BUT if they do support it, they MUST conform to the behavior described in this section and its subsections 🫶

This mechanism is all about REGISTER transaction behavior, so it's super important to think about how it affects the registration event package from RFC 3680 [12]. In practice, there are two main use cases for subscribing to registration data: finding out the overall registration state for the SIP-PBX, and finding out the registration state for a single SIP-PBX AOR 💜

7.2.1. SIP-PBX Aggregate Registration State 📊

If the SIP-PBX (or another interested and authorized party) wants to monitor or audit the registration state for all of the AORs currently registered to that SIP-PBX, it can subscribe to the SIP registration event package at the SIP-PBX's main URI. That's the URI used in the "To" header field of the REGISTER request 🎀

The NOTIFY messages for that subscription will have a body containing one record for each AOR associated with the SIP-PBX. The AORs will be in the format the SSP is expecting to receive (for example, "sip:+12145550105@ssp.example.com"), and the contacts will match the mapped contact created by the registration (for example, "sip:+12145550105@98.51.100.3").

Here's a big one: the "bnc" parameter is forbidden from showing up in the body of a reg-event NOTIFY request, unless the subscriber has indicated it knows what the "bnc" parameter means. How that support gets indicated is out of scope for this document 🙈

Also, because the SSP doesn't necessarily know which GRUUs the SIP-PBX has issued to its associated UAs, these records generally won't include the <temp-gruu> or <pub-gruu> elements defined in RFC 5628 [9]. If that info is needed, it can be learned by subscribing to the individual AOR registration state, as described in Section 7.2.2 🌈

7.2.2. Individual AOR Registration State

okay so, like we covered in Section 6, the SSP will usually re-target every request for an AOR that a SIP-PBX owns over to that SIP-PBX, using the mapping set up at registration time 💅. The SSP's policy is allowed to override that default 🫶, but for the registration event package to work properly, every "reg" event SUBSCRIBE request has to be handled by the SIP-PBX 🎀. So the rules for SSPs processing registration event package SUBSCRIBE requests are not left up to policy 💖.

If the SSP gets a SUBSCRIBE for the registration event package whose Request URI points at an AOR registered through the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX the same way it would proxy an INVITE headed for that AOR 🦋. The one exception is when the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (for example, through an active back-end subscription) ✨.

If the Request URI in a SUBSCRIBE for the registration event package points at a contact that is registered by more than one SIP-PBX, then the SSP proxy will fork the SUBSCRIBE to all the applicable SIP-PBXes 🌸. It's the same vibe if the Request URI matches a contact that is both implicitly registered by a SIP-PBX and explicitly registered directly with the SSP proxy. In that case the SSP proxy will semantically fork the SUBSCRIBE to the applicable SIP-PBX or SIP-PBXes and to the registrar function, which responds with the registration data for the explicit registrations at the SSP 🧚. Forking in both of these cases can be avoided if the SSP has and can maintain a copy of up-to-date information from the PBXes 👑.

Section 4.9 of RFC 3680 [12] says that "a subscriber MUST NOT create multiple dialogs as a result of a single [registration event] subscription request". So subscribers who don't know about the extension in this document will only accept one dialog for these requests 😭. In the forking case above, those clients end up with accurate but incomplete info about the AOR's registration state 💀. This document makes an explicit change to RFC 3680's normative behavior: subscribers to the registration event package MAY create multiple dialogs as the result of a single subscription request 🌈. That's what lets subscribers build a complete view of an AOR's registration state 🙌.

Defining the behavior this way is a big deal, because the reg-event subscriber wants the full list of devices tied to the AOR 🍓. Only the SIP-PBX has authoritative access to that info 🔥. Like, if the user registered multiple UAs with different capabilities, the SSP won't know about those devices or their capabilities 🙈. The SIP-PBX will 💅.

If the SIP-PBX isn't registered with the SSP when a registration event subscription comes in for a contact that would be implicitly registered if the SIP-PBX were registered, then the SSP SHOULD accept the subscription and indicate that the user is not currently registered 🥺. Once the associated SIP-PBX registers, the SSP SHOULD use the subscription migration mechanism defined in RFC 3265 [5] to migrate the subscription to the SIP-PBX 🦋.

When a SIP-PBX gets a registration event subscription addressed to an AOR that was registered using the bulk registration mechanism in this document, then each resulting registration information document SHOULD contain an 'aor' attribute in its <registration/> element, and that attribute should match the AOR at the SSP ✨. Here's how it plays out. Say a SIP-PBX registered with an SSP whose domain is ssp.example.com, and it used a Contact URI of sip:198.51.100.3:5060;bnc. Once that registration is done, a registration event subscription that lands at the SSP with a Request URI of sip:+12145550102@ssp.example.com gets re-targeted to the SIP-PBX, now with a Request URI of sip:+12145550102@198.51.100.3:5060 🧚. The registration document the SIP-PBX builds will have a <registration/> element with an "aor" attribute of sip:+12145550102@ssp.example.com 💖.

Why does that matter? Outside subscribers (who don't know about GIN, aka generate implicit numbers, procedures) will look for the publicly visible AOR, not the address the SSP uses to send stuff to the SIP-PBX 🙃. So with this setup they can actually find the info they want in the registration document 💜.

A SIP-PBX that supports both GRUU procedures and the registration event packages SHOULD implement the extension defined in RFC 5628 [9] 🌟.

7.3. Client-Initiated (Outbound) Connections

RFC 5626 [19] defines a mechanism that lets UAs set up long-lived TCP connections or UDP associations with a proxy, so traffic can flow both ways between the proxy and the UA 🦋. This is super important when NATs are involved, and also whenever TLS [18] security is required 🔐. Neither the SSP nor the SIP-PBX is required to support client-initiated connections 🤷‍♀️.

Generally, the outbound mechanism works with the solution in this document without any changes 💅. Implementors should note that the instance ID used between the SIP-PBX and the SSP's registrar identifies the SIP-PBX itself, not any of the UAs registered with the SIP-PBX 🎀. So any attempt to use caller preferences (defined in RFC 3841 [14]) to target a specific instance is likely to fail 😬. Honestly that's fine, because the preferred way to target specific instances of a user agent is GRUU (see Section 7.1) 👑.

7.4. Non-Adjacent Contact Registration (Path) and Service-Route Discovery

RFC 3327 [10] defines a way for a registrar and its associated proxy to learn about a route that should be used between the proxy and the registered user agent 🛤️. The scope of the route made by a Path header field is contact specific. So if an AOR has multiple contacts, the routes for each contact may be totally different 🌈. Support for non-adjacent contact registration is required in all SSPs and SIP-PBXes implementing the multiple-AOR-registration protocol described in this document 💜.

At registration time, any proxies between the user agent and the registrar can add themselves to the Path header field 🧚. By doing that, they're asking for any requests destined for the user agent (because of that registration) to include them as part of the Route toward the user agent 🦋. The path mechanism does deliver the final path value to the registering UA, but UAs typically ignore the value of the path 🙄.

To set up the same kind of thing going the other way, meaning a route for requests sent by a registering UA, RFC 3608 [11] defines a way for a UA to learn about a route it should use for all outbound requests tied to the AOR in the registration 🚀. That info is scoped to the AOR within the UA, not to the contact (or contacts) in the REGISTER request ✨. Support for service route discovery is OPTIONAL in SSPs and SIP-PBXes 🌸.

The registrar makes up the values of the service route on its own, using whatever local policy it likes 💅. Even though it's common to use the Path and/or Route header field info from the request when composing the service route, the registrar isn't constrained in any way that requires it 🤍.

Now, when you're thinking about how these mechanisms interact with registering multiple AORs in a single request, proxy, registrar, and intermediary implementors have to keep the following issues in mind 🧐. They come from the fact that GIN effectively registers multiple AORs and multiple contacts 🔥.

First, all location service records that come from expanding a single Contact URI containing a bnc parameter will necessarily share one path 🎀. That means proxies can't make policy decisions contact by contact about whether to put themselves in the path 🙈. Second, and similarly, all AORs on the SIP-PBX that are registered with a common REGISTER request will be forced to share a common service route 😭.

One fun technique the path and service route mechanisms make possible is putting a token or cookie in the user portion of the service route or path entries 🍪. That token or cookie can tell proxies about the identity, capabilities, and/or policies tied to the user 💖. Since that info gets shared across several AORs and several contacts when multiple AOR registration is used, you should be careful and make sure it's acceptable for all AORs and all contacts registered in a single REGISTER request ⚠️.

8. Examples ✨

Note that the following examples skip any authentication steps 🙈. That's just for clarity 💅. Real deployments will need a level of authentication that fits their system 🔐.

8.1. Usage Scenario: Basic Registration 🎀

okay so this example walks through a basic bulk REGISTER, and then an INVITE shows up for one of the registered UAs 📞✨ the example messages come right after the sequence diagram

   Internet                        SSP                          SIP-PBX
   |                                |                                 |
   |                                |(1) REGISTER                     |
   |                                |Contact:<sip:198.51.100.3;bnc>   |
   |                                |<--------------------------------|
   |                                |                                 |
   |                                |(2) 200 OK                       |
   |                                |-------------------------------->|
   |                                |                                 |
   |(3) INVITE                      |                                 |
   |sip:+12145550105@ssp.example.com|                                 |
   |------------------------------->|                                 |
   |                                |                                 |
   |                                |(4) INVITE                       |
   |                                |sip:+12145550105@198.51.100.3    |
   |                                |-------------------------------->|

(1) the SIP-PBX registers with the SSP for a whole range of AORs 💅

   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
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.100.3:5060;bnc>
   Expires: 7200
   Content-Length: 0

(3) the SSP gets a request for an AOR that belongs to the SIP-PBX 👀

   INVITE sip:+12145550105@ssp.example.com 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>

(4) the SSP re-targets the incoming request using what the SIP-PBX told it at registration time 🦋

   INVITE sip:+12145550105@198.51.100.3 SIP/2.0
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 68
   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>

8.2. Usage Scenario: Using Path to Control Request URI 🌸

this one is giving "Path" header field extension energy 💜 [10] it's a bulk REGISTER where the SSP uses that extension, and it lets the SSP name a domain on the incoming Request URI that doesn't necessarily resolve to the SIP-PBX when the SSP applies RFC 3263 procedures to it 🧚

   Internet                        SSP                          SIP-PBX
   |                                |                                 |
   |                                |(1) REGISTER                     |
   |                                |Path:<sip:pbx@198.51.100.3;lr>   |
   |                                |Contact:<sip:pbx.example;bnc>    |
   |                                |<--------------------------------|
   |                                |                                 |
   |                                |(2) 200 OK                       |
   |                                |-------------------------------->|
   |                                |                                 |
   |(3) INVITE                      |                                 |
   |sip:+12145550105@ssp.example.com|                                 |
   |------------------------------->|                                 |
   |                                |                                 |
   |                                |(4) INVITE                       |
   |                                |sip:+12145550105@pbx.example     |
   |                                |Route:<sip:pbx@198.51.100.3;lr>  |
   |                                |-------------------------------->|

(1) the SIP-PBX registers with the SSP for a range of AORs 🎀 it puts the form of URI it wants to see in the Request URI into its "Contact" header field, and it puts the routing info that gets it back to the SIP-PBX into the "Path" header field 🫶

   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: 326983936836068@998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Path: <sip:pbx@198.51.100.3:5060;lr>
   Contact: <sip:pbx.example;bnc>
   Expires: 7200
   Content-Length: 0

(3) the SSP gets a request for an AOR assigned to the SIP-PBX 👑

   INVITE sip:+12145550105@ssp.example.com 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: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 24762 INVITE
   Contact: <sip:line-1@192.0.2.178:2081>
   Content-Type: application/sdp
   Content-Length: ...

   <sdp body here>

(4) the SSP re-targets the request using the registration info from the SIP-PBX 🍓 following the usual "Path" processing, it drops the "Path" value the SIP-PBX gave at registration into a "Route" header field, and it sets the Request URI to the registered contact ✨

   INVITE sip:+12145550105@pbx.example SIP/2.0
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   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>

9. IANA Considerations 🌈

okay the IANA part, bestie 🙈 this doc registers a brand new SIP option tag so people can tell the mechanism is supported, two new SIP URI parameters, and a "Contact" header field parameter. the process for registering all of these is laid out in RFC 5727 [21] 💖

9.1. New SIP Option Tag

this section defines a new SIP option tag following the guidelines in Section 27.1 of RFC 3261 [3] 🦋

Name: gin

Description: this option tag identifies the extension that provides registration for Multiple Phone Numbers in SIP. when it shows up in a "Require" or "Proxy-Require" header field of a REGISTER request, it means support for this extension is required of registrars and proxies, respectively, that are a party to the registration transaction 📞

Reference: RFC 6140

9.2. New SIP URI Parameters

this spec defines two new SIP URI parameters, as per the registry created by RFC 3969 [7] 💜

9.2.1. 'bnc' SIP URI Parameter

Parameter Name: bnc

Predefined Values: No (no values are allowed) 🙅‍♀️

Reference: RFC 6140

9.2.2. 'sg' SIP URI Parameter

Parameter Name: sg

Predefined Values: No

Reference: RFC 6140

9.3. New SIP Header Field Parameter

this section defines a new SIP header field parameter per the registry created by RFC 3968 [6] 🔥

Header field: Contact

Parameter name: temp-gruu-cookie

Predefined values: No

Reference: RFC 6140

10. Security Considerations 🔐💅

okay bestie, this section is SERIOUS but also kind of iconic, so let's go 🫶

The change in this document takes the unprecedented step of extending the previously defined REGISTER method to apply to more than one AOR 😳. Honestly that's a big plot twist, and it can cause problems for intermediaries (like proxies) that are part of the REGISTER transaction 🚨. Those middlemen might try to apply policy to the user shown in the "To" header field (so, the SIP-PBX's identity 🏢) without knowing that multiple AORs are being implicitly registered at the same time. Not it. 🙅‍♀️

The mechanism in this document fixes that by adding an option tag to a "Proxy-Require" header field in those REGISTER requests ✨. Proxies that don't know about this mechanism won't process the requests, so they can't misapply policy. Proxies that DO process requests with this option tag are clearly aware of what a REGISTER like this is, so they can make reasonable policy decisions. Main character energy for the proxies that are paying attention 💖.

As noted in Section 7.4, intermediaries need to take care if they use a policy token in the path and service route mechanisms 🧐. Doing that will make them apply the same policy to all users served by the same SIP-PBX. This may frequently be the correct behavior, but there are situations where different users need different policies, so differentiation may be required 🌈.

Section 7.4 also notes that these techniques use a token or cookie in the "Path" and/or "Service-Route" header values, and that this value is shared among all AORs associated with a single registration 🍓. Since user agents can see this information under certain conditions, proxy designers who use this mechanism together with the techniques in this document need to be careful that they don't leak sensitive information 🙈😭.

One of the key properties of the outbound client connection mechanism in Section 7.3 is the assurance that a single connection is tied to a single user and can't be hijacked by other users 🔒. With the mechanism in this document, those connections become shared between users, no cap. BUT the only entity that can hijack calls because of this is the SIP-PBX itself 👑. The SIP-PBX is already the registrar for all the potentially affected users, so it already has the power to redirect any of those communications however it likes. In other words, the SIP-PBX must be trusted to handle calls appropriately, and using the outbound connection mechanism adds no extra vulnerabilities 💅✨.

The ability to learn the identity and registration state of every user on the PBX (as described in Section 7.2.1) is invaluable for diagnostic and administrative purposes 🦋. For example, it lets the SIP-PBX figure out whether all its extensions are properly registered with the SSP. HOWEVER, this info can also be super sensitive, since lots of organizations don't want their entire list of phone numbers visible to outside entities 😬. So SSP servers are advised to use explicit (i.e., white-list) and configurable policies about who can access this information, with very conservative defaults (e.g., an empty access list or an access list containing only the PBX itself) 🔐🌸.

The procedure for generating temporary GRUUs requires an HMAC to detect any tampering that external entities may try to do to the contents of a temporary GRUU 🕵️‍♀️. The mention of HMAC-SHA256-80 in Section 7.1.2 is only meant as an example of a suitable HMAC algorithm 🎀. Since all HMACs used in this document are generated and consumed by the same entity, the choice of an actual HMAC algorithm is totally up to the implementation, as long as its cryptographic properties are strong enough to stop third parties from spoofing GRUU-related information 💖.

The temporary GRUU procedure also requires RSA keys 🔑. Picking the right key length takes careful analysis, considering the current and foreseeable processing speed over the period during which GRUUs must stay anonymous, plus emerging cryptographic analysis methods 🧠. The most recent guidance from RSA Laboratories [25] suggests a key length of 2048 bits for data that needs protection through the year 2030, and 3072 bits after that 🦋✨.

Similarly, implementors are warned to take precautions to prevent unauthorized disclosure of the private key used in GRUU generation 🚨. Any such disclosure would let someone correlate temporary GRUUs with each other and, potentially, with their associated PBXes. Yikes, not good 😭.

Also, using RSA decryption when processing GRUUs received from arbitrary parties can be exploited by Denial-of-Service (DoS) attackers to amplify the impact of an attack 💀. Because a cryptographic operation is part of processing those messages, CPU load may be slightly higher when an attacker uses (valid or invalid) temporary GRUUs in the messages used for such an attack. Normal DoS mitigation techniques, such as rate-limiting the processing of received messages, should help reduce the impact of this issue too 🛡️🍓.

Finally, good security practices should be followed regarding how long an RSA key is used 🌈. For implementors, this means systems MUST include an easy way to update the public key provided to the SIP-PBX 💜. To avoid immediately invalidating all currently issued temporary GRUUs, the SSP servers SHOULD keep the retired RSA key around for a grace period before discarding it 🧚. If decryption fails with the new RSA key, the SSP server can attempt to use the retired key instead 🔁. By contrast, the SIP-PBXes MUST discard the retired public key immediately and exclusively use the new public key 🫶🔥.

11. Acknowledgements 🎀🫶

This document is the hard work of lots of people in the IETF MARTINI working group and the IETF RAI community as a whole 🌸. Big thanks to John Elwell for his requirements analysis of the mechanism, to Dean Willis for his analysis of how this mechanism interacts with the "Path" and "Service-Route" extensions, to Cullen Jennings for his analysis of how it interacts with the SIP Outbound extension, and to Richard Barnes for his detailed security analysis of the GRUU construction algorithm 👑. Thanks to Eric Rescorla, whose text in the appendix of RFC 5627 was lifted directly to provide substantial portions of Section 7.1.2 ✨. Finally, thanks to Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their careful reviews and constructive feedback on this document 💖🦋.

12. References 📚

12.1. Normative References

[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[9] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.

12.2. Informative References

[10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[16] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[19] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[20] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[21] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[22] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)", RFC 5947, September 2010.
[23] Kaplan, H., "GIN with Literal AORs for SIP in SSPs (GLASS)", Work in Progress, November 2010.
[24] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
[25] Kaliski, B., "TWIRL and RSA Key Size", May 2003.

Appendix A. Requirements Analysis ✨

okay bestie, this appendix is the receipts 🧾. The document "Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)" [22] has a list of requirements and desired properties for a way to register multiple AORs in one SIP transaction. So this section goes through each one and checks whether the mechanism in this document actually hits it. Spoiler: it's giving completeness 💅

REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking arrangement with an SSP whereby the two parties have agreed on a set of telephone numbers assigned to the SIP-PBX.

✅ The requirement is satisfied. 🌸

REQ2 - The mechanism MUST allow a set of assigned telephone numbers to comprise E.164 numbers, which can be in contiguous ranges, discrete, or in any combination of the two.

✅ The requirement is satisfied. The Direct Inward Dialing (DID) numbers tied to a registration are set up by bilateral agreement between the SSP and the SIP-PBX. They are not part of the mechanism in this document, so the SSP and the SIP-PBX sort that out between themselves 🤝

REQ3 - The mechanism MUST allow a SIP-PBX to register reachability information with its SSP, in order to enable the SSP to route to the SIP-PBX inbound requests targeted at assigned telephone numbers.

✅ The requirement is satisfied. 🦋

REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process.

✅ The requirement is satisfied; in the presumed architecture, SIP-PBX UAs register with the SIP-PBX and need no interaction with the SSP. The SSP is not in the loop for this one, which is so efficient 🙌

REQ5 - The mechanism MUST allow a SIP-PBX to handle requests originating at its own UAs and targeted at its assigned telephone numbers, without routing those requests to the SSP.

✅ The requirement is satisfied; SIP-PBXes may recognize their own DID numbers and GRUUs, and perform on-SIP-PBX routing without sending the requests to the SSP. Local calls stay local, periodt 🏠

REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its assigned telephone numbers originating outside the SIP-PBX and arriving via the SSP, so that the SIP-PBX can route those requests onwards to its UAs, as it would for internal requests to those telephone numbers.

✅ The requirement is satisfied 💖

REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows which of its assigned telephone numbers an inbound request from its SSP is targeted at.

✅ The requirement is satisfied. For ordinary calls and calls using public GRUUs, the DID number shows up in the user portion of the Request URI. For calls using Temp GRUUs built with the mechanism in Section 7.1.2, the "gr" parameter gives the SIP-PBX a correlation token, so it can tell which UA the call should go to 🎯

REQ8 - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.

✅ The requirement is satisfied through the 'gin' option tag and the 'bnc' Contact URI parameter. No awkward mismatch drama between the two sides 🫶

REQ9 - The mechanism MUST observe SIP backwards compatibility principles.

✅ The requirement is satisfied through the 'gin' option tag. Old friends stay friends 🧚

REQ10 - The mechanism MUST work in the presence of a sequence of intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e., between the SIP-PBX and the SSP's domain proxy), where those intermediate SIP entities indicated during registration a need to be on the path of inbound requests to the SIP-PBX.

✅ The requirement is satisfied through the use of the path mechanism defined in RFC 3327 [10]. The middle-person entities get to be part of the route, and nobody gets left out 🛤️

REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.

✅ The requirement is satisfied by letting the SIP-PBX use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field. Dynamic IP? No problem, bestie 🌈

REQ12 - The mechanism MUST work without requiring the SIP-PBX to have a domain name or the ability to publish its domain name in the DNS.

✅ The requirement is satisfied by letting the SIP-PBX use an IP address in the Bulk Number Contact URI contained in a REGISTER "Contact" header field. No domain name needed, so no DNS stress 😌

REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on other domains, which are expected to be able to use normal RFC 3263 procedures to route requests, including requests needing to be routed via the SSP in order to reach the SIP-PBX.

✅ The requirement is satisfied by letting the domain name in the Request URI used by external entities resolve to the SSP's servers via normal RFC 3263 resolution procedures. Everyone else's routing stays untouched, which is the respect we love to see 👑

REQ14 - The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP, e.g., using TLS as specified in [3].

✅ The requirement is satisfied; nothing in the proposed mechanism prevents the use of TLS between the SSP and the SIP-PBX. Private and protected 🔐

REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa, e.g., using SIP digest authentication plus TLS server authentication as specified in [3].

✅ The requirement is satisfied; SIP-PBXes may employ either SIP digest authentication or mutually authenticated TLS for authentication purposes. Both sides can vouch for each other, which is very healthy relationship energy 💜

REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [20].

✅ The requirement is satisfied via the mechanisms detailed in Section 7.1. GRUUs for everyone 🎀

REQ17 - The mechanism MUST work over any existing transport specified for SIP, including UDP.

✅ The requirement is satisfied to the extent that UDP can be used for REGISTER requests in general. Some extensions and/or network topologies may exceed UDP MTU sizes, but those issues show up both with and without the mechanism in this document. This document doesn't make them worse ✨

REQ18 - Documentation MUST give guidance or warnings about how authorization policies may be affected by the mechanism, to address the problems described in Section 3.3 [of RFC 5947].

✅ These issues are addressed at length in Section 10, and also summarized in Section 7.4. Read those sections, they're important 📚

REQ19 - The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in RFC 3966 [15], which can be in contiguous ranges, discrete, or in any combination of the two.

Assigning telephone numbers to a registration is handled by the SSP's registrar, and it isn't stopped from assigning local numbers in whatever combination it wants 🧩

REQ20 - The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in RFC 3261 [3], as opposed to just telephone numbers, without requiring a complete change of mechanism as compared to that used for telephone numbers.

✅ The mechanism is extensible in that way, as shown by the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23]. Glow-up unlocked 🦋

DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms for providing SIP service to normal UAs in order to provide a SIP trunking service to SIP-PBXes.

✅ The desired property is satisfied; the routing mechanism in this document is identical to the routing performed for singly registered AORs. Same energy, same vibes 💅

DES2 - The mechanism SHOULD scale to SIP-PBXes of several thousand assigned telephone numbers.

✅ The desired property is satisfied; nothing in this document precludes DID number pools of arbitrary size. Big pools, no problem 🌊

DES3 - The mechanism SHOULD scale to support several thousand SIP-PBX's on a single SSP.

✅ The desired property is satisfied; nothing in this document precludes an arbitrary number of SIP-PBXes from attaching to a single SSP. The guest list is open 🎉

Author's Address

Adam Roach
Tekelec
17210 Campbell Rd.
Suite 250
Dallas, TX  75252
US

EMail: adam@nostrum.com

📦 where this page comes from

ietf: rfc6140 2011-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 6140

Abstract ✨

Status of This Memo 📋

Copyright Notice ©️

Table of Contents 🗂️

1. Introduction ✨

2. Constraints 🚧

3. Terminology and Conventions 📖

4. Mechanism Overview 🌸

5. Registering for Multiple Phone Numbers 📞💖

5.1. SIP-PBX Behavior 📞✨

5.2. Registrar Behavior 🗂️

5.3. SIP URI "user" Parameter Handling 🧩

6. SSP Processing of Inbound 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.1.2.1. Generation of "temp-gruu-cookie" by the SSP 🍪

7.1.2.2. Generation of temp-gruu by the SIP-PBX ✨

7.1.2.3. Decoding of temp-gruu by the SSP 🔍

7.1.2.4. Decoding of temp-gruu by the SIP-PBX 🦄

7.2. Registration Event Package 📮

7.2.1. SIP-PBX Aggregate Registration State 📊

7.2.2. Individual AOR Registration State

7.3. Client-Initiated (Outbound) Connections

7.4. Non-Adjacent Contact Registration (Path) and Service-Route Discovery

8. Examples ✨

8.1. Usage Scenario: Basic Registration 🎀

8.2. Usage Scenario: Using Path to Control Request URI 🌸

9. IANA Considerations 🌈

9.1. New SIP Option Tag

9.2. New SIP URI Parameters

9.2.1. 'bnc' SIP URI Parameter

9.2.2. 'sg' SIP URI Parameter

9.3. New SIP Header Field Parameter

10. Security Considerations 🔐💅

11. Acknowledgements 🎀🫶

12. References 📚

12.1. Normative References

12.2. Informative References

Appendix A. Requirements Analysis ✨

Author's Address