In this section:
Overview
The SIP Signaling Registration facility enables
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
The
The
SIP Active Register Name Status Search Options
The
The
- Viewing All Active Register Information
- Viewing Active Register Information Based on Full AOR (userPart+hostname)
- Viewing Active Register Information Based on AOR/Partial AOR and Registration
Viewing All Active Register Information
To view all active register details, use the following CLI syntax:
> show table addressContext <addressContextName> sipActiveRegisterNameStatus
> 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
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>
> 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
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.
> 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;
For more information on SIP active register search option, refer to:
Registration Display Enhancements
The S-SBC and I-SBC (in 1:1 deployments) support the display of various statistics and registration records in the system through EMS. To mitigate an historical upper limit of records that could be shown, the SBC:
- Upon receiving a dump request from the customer over Unable to show "metadata-from": No such page "_space_variables":
- Dumps the status of all the registered endpoints into a csv file in a compressed format (.gz).
- Dumps all the subscriptions generated by the SBC – specifically, sipGeneratedSubscriptionStatus – and the status for SIP endpoints, into a .csv file in a compressed format (.gz).
- All dump requests are addressed by the SBC only if the feature global config is enabled.
- The SBC includes a Deleted Registers dump table, which dumps the last deleted (or expired) Registered endpoints.
On a switchover, this feature is available on the newly-active SBC. Any rollover of the dump commands started on the earlier Active SBC is not supported.
For configuration and statistics details, refer to:
Bulk Registration Support
The
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
For complete SIP trunk group configuration details, refer to:
EVENT Records Generation
The
ACT
log files) for each successful registration and de-registration.For details on enabling the EVENT records, see the following wiki pages:
- CLI: Accounting - CLI
- EMA: Services - Admin - Event Acct Methods
- Rf: Rf Interface Support
Registration Establishment
The
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:
- 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 asurrRegprofile
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 configureuserPart
at the surrogate registration level.
Surrogate Registration Profile Limitations
- Configuration limitations:
- Up to 200 subscribers for each AoR
- Up to 1,000 surrogate registration profiles system-wide
- Up to 256,000 AoRs for surrogate registration system-wide and 64,000 for AoRs in the SBC SWe:
The maximum number on the SBC 7000 and SBC 5400 platforms is 256,000. (1,000 Surrogate Registration profiles, each supporting 256 surrogate AORs).
The maximum number on the SBC SWe platform is 64,000 per SCM instance, up to 256,000.
- Subscriber numbers must be unique across the system.
- Configure subscriber numbers using the same format as expected from the received call.
- The SBC supports a registration rate of 100 registrations/second.
Refer to SBC Provisioning Limits for details regarding limitations.
If the same AorUsername is configured on two different peers, AorUserName start and end range values for either peer should not fall within start and end range values of the other peer.
In Access and Enterprise scenarios, the
When 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
- REGISTER
- INVITE
- PRACK
- UPDATE
- REINVITE
- BYE
For surrogate registration configuration commands and examples, refer to:
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.
To configure SIP Authentication, refer to:
Authenticating New Connections by Registrar
The
- 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
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
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,
In earlier releases, when the primary SIP server goes down, the
The
The
request
command to query PSX on new refresh REGISTERs.Quick Re-registration on Alternate SIP Server When Primary Server is Down
IPSP Configuration
The registrarRecovery
parameter is added to IPSP commonIpAttributes object, and includes following flags:
registerToAlternateOnPrimaryDown
(This flag must be enabled to viewoverrideInternalExpiresTimer
andrevertToPrimaryOnRecovery
flags.)overrideInternalExpiresTimer
revertToPrimaryOnRecovery
(This flag must be enabled to viewdeRegisterAlternateOnPrimaryRecovery
flag.)deRegisterAlternateOnPrimaryRecovery
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
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.
The queryPsxOnNextRefreshRegister
command has following optional values:
newRegistrarIndex
overRideInternalExpires
registrarFqdn
registrarIpAddress
For more information, refer to the section Configuring Alternate SIP Server When Primary Server is Down.