SIP Registration

Overview

The SIP Signaling Registration facility enables SBC to relay SIP endpoint registration information between these endpoints and the Registrar. The SIP Trunk group commands configure the time span allowed for an IAD before requiring re-registration.

The registration facility allows different expiration time on the untrusted versus trusted network. This can be used to reduce the registration refresh load on the registrars without sacrificing fast detection of failed IADs.

SIP Signaling Subscription enables SBC to relay out-of-dialog “subscribe” and “notify” requests between unregistered endpoints. Unknown registration to the SBC may occur because the SBC is not located between an IAD and its Registrar. The Registrar’s default IP address is 0.0.0.0, and the portNum is “0”. This, or any other configured address, is overridden by per-transaction routing data from the SBC.

The SBC supports implicit registration of SIP endpoints. In other words, the SBC supports a SIP registrar returning a set of associated URIs that are implicitly registered in response to a “Register” message for a single Address of Record (AoR). The 200 response to the “Register” request identifies each implicitly registered URI in a P-Associated-URI header. P-Associated-URI headers in the 200 response are passed transparently by the SBC. Up to 20 P-Associated-URIs (each up to 103 bytes in length) can be carried in a single 200 response, except on NOTIFY where only 20 P-Associated-URIs are supported.

Bulk Registration Support

The SBC supports the SIPConnect 1.1 feature as per the RFC 6140 “Registration for Multiple Phone Numbers in the SIP” (bulk registration) with the addition of “gin” option tag to Proxy-Require/Require headers. Additionally, in at least one Contact header, a Contact URI containing “bnc” parameter must be included to signify it is a bulk registration value. The default SIP To and From header username is sip:sbc@sonusnet.com.

To set registration requests to bulk registration format, use following CLI syntax:

% set addressContext <ac_name> zone <zone name> sipTrunkGroup <tg_name> signaling registration bulkRegisterFormat enable

Registration Establishment

The 

See SBC Product Specifications page for the maximum initial REGISTER rate when coincident with REGISTER refreshes and background call load for existing registrations. Note that the maximum initial REGISTER rate without any background load is much higher. However, customers should use these numbers for planning purposes since the absence of other background load is unrealistic in real networks. 

This initial register rate is for the case when initial registers are challenged for authentication by the registrar. While the unchallenged initial register rate is much higher, the best practice is to securely authenticate subscribers before accepting registrations.

For best performance, use the default overload control settings and configure the unknown peer policer to admit the appropriate initial register rate for your subscriber environment. This ensures that the system provides acceptable performance when the actual initial register attempt rate is much higher than the values below (for example, after a major city comes back online after a power outage).

SIP session and registration capacity limits are derived using the following call flow baseline:

1. INVITE
2. 100 Trying
3. 180 Ringing
4. 200 OK
5. ACK
6. <talk time>
7. BYE
8. 200 OK

The basic initial REGISTER flow in this example consists of the following four-message exchange:

1. REGISTER
2. 401 (Unauthorized)
3. REGISTER
4. 200 OK

A refresh register flow consists of:

• REGISTER
• 200 OK

Surrogate Registration Support

The 

The

When configuring surrogate registration, only one of the following mutually exclusive parameters should be enabled at the IP Peer Surrogate Registrationlevel depending upon the number of AoRs per IP Peer desired.

• Only one AoR per IP Peer to for surrogate registration—Configure only userPart at the surrogate registration level. With this method, you cannot associate a surrRegprofile with this peer.
• Multiple AoRs for IP Peer for surrogate registration—Associate more than one AoR to the same peer by configuring and attaching a surrRegprofile to the IP peer. When using this profile, you cannot configure userPart at the surrogate registration level.

In Access and Enterprise scenarios, the

When the

• Challenge for any message
• Challenge for any message and in-dialog requests
• Challenge for register 

The 

1. REGISTER
2. INVITE
3. PRACK
4. UPDATE
5. REINVITE
6. BYE

SIP Authentication Using Dedicated User Name

The

In support of Surrogate Registration, when a REGISTER message is (re)sent with an Authorization or Proxy-Authorization header field in response to a challenge for authentication, the

The selected “Authentication ID” is also used among other parameters, e.g., password, nonce, etc., in computing the “response” parameter of the header field per RFC 2617. The From/To/Contact header fields, however, continue to take the existing “User Part” from the associated “IP Peer/Surrogate Registration” entry as the “userinfo” part of the SIP URI.

To maintain backwards compatibility, during an LSWU from a previous release the value of the “Authentication ID” field is automatically filled with the existing “IP Peer/Surrogate Registration/User Part” field used for authorization in the previous release.