Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
updates
- rfc-3680 — A Session Initiation Protocol (SIP) Event Package for Registrations
Extracted elements (30)
A REGISTER-based approach was chosen because it has seen significant deployment momentum in SIP-PBX environments, particularly for E.164-addressed systems needing to avoid DNS entries or static IP addresses. This document standardizes an approach already in widespread use rather than introducing a wholly new mechanism.
Temporary GRUUs for bulk registrations cannot reuse a single invariant SIP-PBX identifier, because that would allow any party to correlate multiple UAs as being behind the same SIP-PBX, violating GRUU anonymity. The SSP therefore provides a per-registration 'temp-gruu-cookie' that the SIP-PBX uses to mint GRUUs that only the SSP can decode.
The mechanism focuses specifically on E.164 phone numbers because SIP URIs with an E.164 user portion are globally unique regardless of the domain, satisfying the requirement that each AOR map to a unique contact set without coordination between SSPs.
All location-service records resulting from a single 'bnc' Contact URI expansion share a single Path. Proxies cannot make per-contact path-inclusion policy decisions. Similarly, all AORs registered in a single bulk REGISTER share a common service route.
This document updates RFC 3680 normative behavior: subscribers to the registration event package MAY create multiple dialogs as the result of a single subscription request. RFC 3680 Section 4.9 previously required that a subscriber MUST NOT create multiple dialogs; the change is necessary when an AOR is registered at both the SSP and one or more SIP-PBXes.
When a SIP-PBX receives a registration event subscription for an AOR registered via the bulk mechanism, each resulting registration information document SHOULD carry an 'aor' attribute in its <registration/> element corresponding to the AOR at the SSP (e.g., 'sip:+[email protected]'), so that subscribers unaware of GIN can find the relevant information.
A Contact URI with a 'bnc' parameter MUST NOT include the SIP URI 'user' parameter. A registrar receiving such a combination MUST NOT return a 200-class response.
A registrar compliant with this document MUST support the Path mechanism defined in RFC 3327. Additionally, all URI parameters present on the 'bnc' Contact URI (except 'bnc' itself) MUST be copied to the contact value stored in the location service.
A SIP-PBX sending a bulk REGISTER request MUST include the option tag 'gin' in both a 'Require' header field and a 'Proxy-Require' header field, and MUST include at least one Contact URI containing the 'bnc' parameter with no user portion.
A SIP-PBX that issues temporary GRUUs MUST generate a new temp-gruu for every registration or registration refresh from GRUU-supporting UAs. The random distinguisher D MUST be at least 80 bits (RECOMMENDED) to prevent collisions among all temp-GRUUs issued by the SIP-PBX.
A URI carrying the 'bnc' parameter MUST NOT contain a user portion. A registrar that receives a REGISTER request with a Contact URI containing both 'bnc' and a user portion MUST NOT send a 200-class response; a 400 (Bad Request) is appropriate.
An SSP supporting temporary GRUUs MUST create and store an asymmetric RSA key pair {K_e1, K_e2}; K_e1 is kept secret by the SSP while K_e2 is shared with SIP-PBXes via provisioning. The SSP MUST include a 'temp-gruu-cookie' parameter on all 'Contact' header fields with a 'bnc' parameter in 200-class REGISTER responses.
An SSP using the GIN mechanism MUST process inbound INVITE requests and SUBSCRIBE requests to the 'reg' event package by re-targeting them to the registered contact for the AOR, and SHOULD perform this processing for all other SIP method types including unrecognized methods.
Any SIP-PBX implementing the GIN registration mechanism MUST also support the Path mechanism defined in RFC 3327 and MUST include the 'path' option tag in the 'Supported' header field of the REGISTER request, so that intermediate proxies can insert Path header field values.
If the SSP and SIP-PBX support the registration event package (RFC 3680), the SSP MUST proxy a SUBSCRIBE for the reg event package addressed to a bulk-registered AOR to the SIP-PBX in the same way it would proxy an INVITE, unless the SSP can maintain accurate, up-to-date registration information independently.
REGISTER requests that attempt to de-register a single AOR that has been implicitly registered via a bulk registration MUST NOT remove that AOR; the registrar acts as if the UA tried to unregister a contact that was not registered. Renewal and removal are bound to the bulk registered contact as a whole.
Systems MUST include an easy mechanism to update the RSA public key provided to the SIP-PBX. The SSP SHOULD retain the retired RSA key for a grace period and attempt decryption with it when decryption under the new key fails. SIP-PBXes MUST discard the retired key immediately and use only the new key.
When forming each derived contact from a 'bnc' registration, the registrar MUST add a user portion containing the fully qualified E.164-formatted number (including the leading '+'), and this number MUST consist exclusively of digits 0–9 after the '+'; visual separators such as '-', '.', '(', or ')' are explicitly prohibited.
The 'bnc' (bulk number contact) SIP URI parameter is placed on a Contact URI in a REGISTER request to indicate that the contact represents multiple phone-number-associated registrations rather than a single contact. A URI with a 'bnc' parameter MUST NOT contain a user portion (no '@' symbol).
The GIN (Generate Implicit Numbers) mechanism allows a SIP-PBX to register with an SSP for multiple phone-number AORs using a single REGISTER request containing a specially formatted Contact URI with the 'bnc' (bulk number contact) parameter. The registrar expands this single registration into one AOR-to-Contact mapping per assigned E.164 number.
The 'sg' SIP URI parameter is added by a SIP-PBX to the public GRUU it received from the SSP when constructing a per-UA public GRUU. The SSP copies the 'sg' parameter from an inbound GRUU-addressed request to the re-targeted contact, allowing the SIP-PBX to route the request to the correct UA.
The 'temp-gruu-cookie' Contact header field parameter is included by the SSP on all 200-class REGISTER responses for contacts containing a 'bnc' parameter. It is base64-encoded, fixed-length, unforgeable, and invariant across registration refreshes, enabling the SIP-PBX to construct decodable temporary GRUUs.
Registers a new SIP Contact header field parameter 'temp-gruu-cookie' (no predefined values). This parameter is included by the SSP in 200-class REGISTER responses for bulk-number contacts and conveys the cryptographic cookie the SIP-PBX needs to construct valid temporary GRUUs.
Registers the SIP option tag 'gin' (Generate Implicit Numbers). When present in Require or Proxy-Require of a REGISTER request, it signals that support for the multiple-phone-number registration extension is required of registrars and proxies party to the transaction.
Registers two new SIP URI parameters: 'bnc' (no predefined values; indicates a bulk number contact on a Contact URI) and 'sg' (no predefined values; carries a disambiguation token enabling the SIP-PBX to route inbound requests to the correct UA when GRUUs are used).
RSA keys used for temporary GRUU generation should be at least 2048 bits for data requiring protection through 2030, and at least 3072 bits thereafter, per RSA Laboratories guidance. Private key disclosure would allow any party to correlate temporary GRUUs to each other and to their associated PBXes.
SSP processing of requests containing temporary GRUUs involves an RSA decryption operation, which can be exploited in Denial-of-Service attacks to amplify CPU load. Standard DoS mitigations such as rate-limiting received-message processing should be applied.
The aggregate registration state of a SIP-PBX (a list of all phone numbers) is highly sensitive. SSP servers MUST use explicit, configurable whitelist policies controlling access to this information, with conservative defaults such as an empty access list or access restricted to the PBX itself.
The 'gin' option tag in the Proxy-Require header field ensures that proxies unaware of the bulk-registration semantics will reject the REGISTER request rather than silently misapply policy intended for a single AOR to all AORs being implicitly registered.
The temporary GRUU user part is formatted as 'tgruu.' followed by base64(E) followed by '.' followed by base64(PA), where E = RSA-Encrypt(K_e2, base64dec(SSP-cookie) || D) and PA = HMAC(PK_a, E). All base64 encoding uses RFC 4648 Section 4 with trailing '=' stripped on encoding.