SIP Registration

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:

• Show Table Address Context (CLI)
• Show Status Address Context (CLI)
• Registration - SIP Active Register Name Status (EMA)

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

• 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.

• Signaling - Global - CLI
• Request Global - CLI
• Show Status Global

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:

• EMA: Trunk Group - SIP Trunk Group
• CLI: Zone - SIP Trunk Group - CLI

EVENT Records Generation

The 

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:

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. In general, the registration capacity is associated with handling both the initial registration and registration refresh.

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. re-INVITE
6. BYE

For surrogate registration configuration commands and examples, refer to:

• CLI: Surrogate Registration Profile - CLI, Zone - IP Peer - CLI
• EMA: Services - Surrogate Registration Profile, IP Peer - Surrogate Registration, Zone - IP Peer - Surrogate Registration

Surrogate Registration Support for CNe Solution

The SBC currently supports IP-PBX registration pass-through without registration between an IP-PBX and the core SIP network. However, the SBC does not support an IP-PBX that does not register when a REGISTER message expects registration. To support this scenario, the SBC performs surrogate registration by generating REGISTER requests for IP-PBXs.

For more information on surrogate registration, refer to:

• Services - Surrogate Registration Profile (EMA)
• Surrogate Registration Profile - CLI

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:

• CLI: Surrogate Registration Profile - CLI
• EMA: Services - Surrogate Registration Profile

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 

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 view overrideInternalExpiresTimer and revertToPrimaryOnRecovery flags.)
• overrideInternalExpiresTimer
• revertToPrimaryOnRecovery (This flag must be enabled to view deRegisterAlternateOnPrimaryRecovery 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.

Perform a Register IP Lookup After an SBC Switchover

Note: This feature is only applicable for TCP/TLS transports.

After an SBC switchover, the first REGISTER request sent by the UE is not matched to an existing TCP connection on the newly-active SBC. This will eventually lead the UE to become aware of the lost TCP connection, and the UE will then establish a new TCP connection and send an initial REGISTER request using the same IP address but with a different port compared to the TCP connection established before the switchover as the selection of client source port for a new TCP connection is usually ephemeral.

The SBC relays the initial REGISTER request sent by the UE to the Registrar as it creates a new AoR. Thus, the Registrar receives a high rate of REGISTER requests after an SBC switchover.

Enable the SIP Sig Controls flag Register IP Lookup Post Switchover for the SBC to search for and validate that the initial REGISTER over the new TCP/TLS connection matches the synchronized RCB after a switchover. The SBC checks that the source IP address used for the new connection matches the old one regardless of the port value (It needs to update the port value and only for the first initial REGISTER received after the switchover for an AoR). Afterwards, the check is again based on the IP/port. 

Note: You must enable Multiple Contacts Per Aor to use this flag.

For configuration details, refer to:

• Signaling - Global - CLI
• Signaling - SIP Sig Controls (EMA)