Overview
The SIP Signaling Registration facility enables
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 the
to relay out-of-dialog “subscribe” and “notify” requests between unregistered endpoints. Unknown registration to the
may occur because the
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
.
The
supports implicit registration of SIP endpoints. In other words, the
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
. 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.
The
uses the entire AOR name to search the registration name status wherever the AOR name is present in the statistics table. The
supports to search the registration name status based on the part of the AOR and the entries, which are not in the statistics table but registered in the
application using a part of the AOR name or the entire AOR name. The registration ID (RegID) is also used as a search function. In case of unknown registration ID, 0 is specified as a wildcard entry. AOR consists of userPart (user name) and hostname (user name end point IP address), and is expressed in the userPart@hostname format.
SIP Active Register Name Status Search Options
The
searches the registration name status based on part of the AOR and also provides the ability to search the entries, which are not in the statistics table but registered in the
application using a part of the AOR name or the entire AOR name. The registration ID (RegID) is also used as a search function. In case of unknown registration ID, 0 is specified as a wildcard entry. AOR consists of userPart (user name) and hostname (user name end point IP address), and is expressed in the userPart@hostname format.
The
includes the ability to view active register name status details for following scenarios using "show status/table addressContext sipActiveRegisterNameStatus" command as shown in the following examples. These examples are based on the full AOR, part of AOR
(userPar only), and partial AOR (AOR+RegID).
| Anchor |
|---|
| View all active register information |
|---|
| View all active register information |
|---|
|
Viewing All Active Register Information
To view all active register details, use the following CLI syntax:
> show table addressContext <addressContextName> sipActiveRegisterNameStatus
| Code Block |
|---|
|
> show table addressContext ADDR_CONTEXT_1 sipActiveRegisterNameStatus
NEXT
NEXT HOP HOP REGISTRAR EXTERNAL
IP PORT IP REGISTRAR EXPIRATION
AOR NAME ID STATE CONTACT URI ADDRESS NUM ADDRESS PORT NUM TIME
----------------------------------------------------------------------------------------------------------------------
xiyu0@10.7.6.40 129024 completed sip:xiyu0@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
xiyu1@10.7.6.40 95488 completed sip:xiyu1@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
xiyu2@10.7.6.40 106496 completed sip:xiyu2@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
xiyu3@10.7.6.40 2560 completed sip:xiyu3@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
xiyu4@10.7.6.40 32000 completed sip:xiyu4@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
...
xiyu2047@10.7.6.40 32170 completed sip:xiyu4@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598 |
| Anchor |
|---|
| View active register information based on full AOR |
|---|
| View active register information based on full AOR |
|---|
|
Viewing Active Register Information Based on Full AOR
To view active register details based on AOR name (full AOR name, including userPart+hostName), append AOR to the end of the command:
> show table addressContext <addressContextName> sipActiveRegisterNameStatus <userPart> <hostName>
| Code Block |
|---|
|
> show table addressContext ADDR_CONTEXT_1 sipActiveRegisterNameStatus xiyu24@10.7.6.40
NEXT
NEXT HOP HOP REGISTRAR EXTERNAL
IP PORT IP REGISTRAR EXPIRATION
AOR NAME ID STATE CONTACT URI ADDRESS NUM ADDRESS PORT NUM TIME
----------------------------------------------------------------------------------------------------------------------
xiyu24@10.7.6.40 129024 completed sip:xiyu24@10.7.6.40:14283 10.7.6.40 14283 10.7.6.40 14284 3598
|
| Anchor |
|---|
| View active register information based on AOR/partial AOR and registration |
|---|
| View active register information based on AOR/partial AOR and registration |
|---|
|
Viewing Active Register Information Based on AOR/Partial AOR and Registration
To view active register details based on an AOR and registration, append AOR (userPart+hostName) or partial AOR (userPart) and regID parameters to the end of the command.
- If the userPart is not unique in the filtered results, the show command only returns the first match.
- If regID is unknown, use the wildcard "0".
In the below example, userPart "xiyu2545" and regID wildcard "0" are appended to the command.
| Code Block |
|---|
|
> show table addressContext ADDR_CONTEXT_1 sipActiveRegisterNameStatus xiyu2545 0
state completed;
contactURI sip:xiyu2545@10.7.6.40:14283;
nextHopIpAddress 10.7.6.40;
nextHopPortNum 14283;
registrarIpAddress 10.7.6.40;
registrarPortNum 14284;
externalExpirationTime 3598;
internalExpirationTime 3600;
creationTime 2015-09-04T13:36:37+00:00;
registrarDomainName "";
endPointBehindNapt 0;
natPinholeLearningStatus none;
securityMechanismType none;
registrationType normal;
e2aeMediaSecurity none;
transportProtocolToEndpoint none;
transportProtocolToAS udp;
externalExpirationTimeLeft 3178;
internalExpirationTimeLeft 2463; |
| Info |
|---|
|
For more information on SIP active register search option, refer to: |
Bulk Registration Support
The
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:
| Code Block |
|---|
|
% set addressContext <ac_name> zone <zone name> sipTrunkGroup <tg_name> signaling registration bulkRegisterFormat enable |
| Info |
|---|
For complete SIP trunk group configuration details, refer to: |
EVENT Records Generation
The
can generate EVENT records (which appear in the .
ACT log files) for each successful registration and de-registration.
| Info |
|---|
For details on enabling the EVENT records, see the following wiki pages: |
Registration Establishment
The
servers can function as registration proxies for access subscribers by accepting SIP REGISTERs and relaying the requests to an inside registrar. Additionally, the
can significantly offload the registrar by locally handling the registration refreshes and only periodically updating the registrar. This function is particularly critical in NAPT environments when the endpoints need to send a REGISTER as fast as every 30 seconds.
Refer to 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:
- INVITE
- 100 Trying
- 180 Ringing
- 200 OK
- ACK
- <talk time>
- BYE
- 200 OK
The basic initial REGISTER flow in this example consists of the following four-message exchange. In general, the registration capacity is associated with handling both the initial registration and registration refresh.
- REGISTER
- 401 (Unauthorized)
- REGISTER
- 200 OK
A refresh register flow consists of:
| Note |
|---|
|
| The subscription ratio for UDP and TCP access load connection is 10:1. |
Surrogate Registration Support
The
supports configuring surrogate registration information for a single IP Peer. Up to 256 Surrogate Registration entries are supported for each IP Peer.
The
also supports configuring multiple AoRs for the same IP-PBX using the Surrogate Registration Profile. Surrogate registration specific statistics are generated separately per surrogate AoR, as applicable, even if the statistics are associated with the same IP Peer.
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.
| Include Page |
|---|
| One_SurrogateRegistrationProfile_Per_Peer |
|---|
| One_SurrogateRegistrationProfile_Per_Peer |
|---|
|
In Access and Enterprise scenarios, the
can act as a surrogate registration entity between a non-registering IP-PBX (or SIP UA) and a REGISTRAR requesting registration. As an example, a new REGISTER request is sent towards the REGISTRAR to help the core network forward the incoming call to
. The
then forwards call to SIP UA based on SIP Registration Data and PSX configuration. An optional keep-alive message (based on OPTIONS Ping) is sent towards SIP UA to determine reachability of the UA from Access Server (AS), and the subsequent outage is reported to REGISTRAR with a ‘deregister’ message. On determining reachability of SIP UA, the UA is registered again with Registrar by the
.
When the
forwards requests coming from the IP-Peer to the AS, in some cases the AS will challenge the requests coming from IP-PBX. If IP-PBX does not support authentication handling, the
can be configured to respond to challenges from the AS on behalf of the IP-PBX using the "
sendCredentials" parameter in the surrogate registration configuration for IP peers. The "
sendCredentials" parameter supports three configurable options:
- Challenge for any message
- Challenge for any message and in-dialog requests
- Challenge for register
The
supports responding to challenges from AS for the following methods:
- REGISTER
- INVITE
- PRACK
- UPDATE
- REINVITE
- BYE
| Info |
|---|
For surrogate registration configuration commands and examples, refer to: |
SIP Authentication Using Dedicated User Name
The
supports configuring a case-sensitive “Authentication ID” and password under the IP Peer object associated with an IP Peer which allows user to configure pilot number other than authorization user name. If IP Peer password is not empty, and if surrogate AoR password is empty, IP Peer password is used for credentials for all applicable methods, (e.g. REGISTER, INVITE).
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
retrieves the “Authentication ID” from the associated “IP Peer” object.
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.
| Note |
|---|
|
If automatically filling Authentication ID is undesirable, after the LSWU completes, configure the “Authentication ID” with a new value such that its corresponding password in a server-specified protected realm can be located. |
| Info |
|---|
To configure SIP Authentication, refer to: |
Authenticating New Connections by Registrar
The
forwards the refresh register to the Registrar under the following conditions:
- Change in the source IP address
- Change in the source Port when Integrated Access Device (IAD) is behind the Network Address Translation (NAT)
When an IAD re-establishes a TCP connection, it uses a different source port and same IP address. the
forwards the refresh register only if the IAD is configured behind the NAT, leaving the new connection unauthenticated.
The SIP Service Group logic forwards a register request when a change in connection parameter is detected under the following conditions, and the IAD is not required to be behind NAT. By forwarding the refresh register, the Registrar can authenticate the user by sending a 401 response.
- Change in connection ID
- Change in source IP address or port
Using New Connection for Existing Calls/Subscriptions
Currently, after a failover if the IAD reestablishes the connection and sends a refresh REGISTER, the
does not use the connection for mid dialog requests towards the IAD for both calls and subscription. With the implementation of this feature, the
supports to use the new connection for sending in-dialog requests for the existing calls and subscriptions towards the IAD.
Quick Re-registration on Alternate SIP Server When Primary Server is Down
In Access scenarios, SIP Registrars on Core facing Trunk Group are considered as primary-secondary/alternate for a particular user. The users are registered to the Primary Registrar when it is available and registered with the Secondary Registrar only when the Primary is down. After the Primary Registrar goes down, the Secondary Registrar allows any new calls or requests only after the completion of Successful registration. Whenever the Primary is down,
must send subsequent refresh registration from the user to the Secondary Registrar to establish the binding at the Secondary Registrar. Similarly, when the Primary comes back up,
must send the next subsequent refresh registration to the Primary Registrar. Any delay in this scenario causes loss of traffic until the registration is successful.
In earlier releases, when the primary SIP server goes down, the
did not register the alternate SIP server immediately. The
did not send the refresh REGISTER to the alternate SIP server until the internal refresh timer expired (3600 seconds). This resulted in a long downtime before the refresh REGISTER is passed on to the alternate SIP server for registration.
The
now supports relaying the first refresh REGISTER to alternate SIP server after it detects any status change in the primary SIP Server. This is controlled by
IP Signaling Profile (IPSP) flags described later in this section. The
registers to the alternate SIP server immediately when Primary is down and reverts when Primary SIP server is up. The status of the server is detected through the blacklisting mechanism of PathCheck/ARS. For every switch from primary to secondary/alternate or from secondary/alternate to primary, the
queries the ERE/PSX to get the latest routing information and route refresh REGISTERs.
The
also supports a CLI
request command to query PSX on new refresh REGISTERs.
| Caption |
|---|
| 0 | Figure |
|---|
| 1 | Quick Re-registration on Alternate SIP Server When Primary Server is Down |
|---|
|
 |
IPSP Configuration
| Note |
|---|
|
This feature requires Pathcheck support using OPTIONS Ping and ARS static blacklisting to detect the reachability of a particular IP/FQDN. |
The registrarRecovery parameter is added to IPSP commonIpAttributes object, and includes following flags:
registerToAlternateOnPrimaryDown (This flag must be enabled to view overrideInternalExpiresTimer and revertToPrimaryOnRecovery flags.)overrideInternalExpiresTimerrevertToPrimaryOnRecovery (This flag must be enabled to view deRegisterAlternateOnPrimaryRecovery flag.)deRegisterAlternateOnPrimaryRecovery
| Note |
|---|
|
Configure the IPSP flags on Egress Trunk Group only. |
request Command
The CLI request queryPsxOnNextRefreshRegister command is used to force PSX query on subsequent refresh REGISTER. This enables new routing information configured in the PSX to be reflected in the
when registrations are active for a long period of time.
The queryPsxOnNextRefreshRegister command is used for one sequence of refresh REGISTERs on all active registrations. The new refresh REGISTERs is routed after a PSX query and the routes are selected from the PSX response.
| Note |
|---|
|
Any new registrations that are received after the command is executed are not affected by this command. |
The queryPsxOnNextRefreshRegister command has following optional values:
newRegistrarIndex overRideInternalExpires registrarFqdn registrarIpAddress
| Note |
|---|
|
The request queryPsxOnNextRefreshRegister command must be executed only on the Ingress Trunk Group. The request queryPsxOnNextRefreshRegister command is applied to all the refresh REGISTERs on all active registrations, which are currently handled by the . |
| Note |
|---|
|
If both request command and IPSP flags are configured, command takes the preference over IPSP flags. |
For more information, refer to the section Configuring Alternate SIP Server When Primary Server is Down.
Call Admission Control (CAC) Support for Non-Registered Endpoints
The
supports per-endpoint and peer Call Admission Control (CAC) profiles for registered endpoints and manually configured IP peers. The is enhanced to extend this support to non-registered endpoints. The signaling IP address and port for a non-registered endpoint is not known and cannot be configured in the . When the supports CAC profile for non-registered endpoints, the Registrar and Application Server (AS) check the authenticity of the non-registered endpoint.The
considers a 2xx response as an indication of successful authentication of the endpoint. Once the initial INVITE is successfully authenticated, a non-registered endpoint is considered secure.| Note |
|---|
The existing Require Registration configuration functions independently from CAC Profiles. However, the parameter Require Registration continues to verify whether the calls from the non-registered endpoints are allowed or not.The 3xx responses are used for redirection. SBC processes and honors these responses without terminating the CAC profile for a non-registering endpoint.If a non-registered endpoint CAC profile is terminated due to an error response, the source of the initial INVITE is not blacklisted.After a switchover, the CAC values for Maximum Number of Calls, and Allocated Bandwidth are retained for non-registered endpoints too. However, the CAC value for Maximum Call Rate starts as a new instance.