Page History

Overview

Overview

The SIP Signaling Registration facility enables

...

Search Method Using AOR and RegID in show Command

To retrieve the entry status that is not in the table but registered in SBC application, provide two parameters (AOR and RegID) in show command. If the RegID is unknown, use 0 as a wildcard to complete the command. Use userPart or the entire AOR name (userPart+hostname) as a first parameter to get the information. For example:

Example 1: In this case, userPart is used as first parameter to get the information.

SIP Active Register Name Status Search Options

The SBC includes the ability to view active register name status details for following scenarios using 'show status/table addressContext sipActiveRegisterNameStatus' command as shown in the examples below.

• View all active register information
• View active register information based on full AOR  (userPart+hostname)
• View active register information based on AOR/partial AOR and registration
• based on full AOR , part of AOR (userPar only) and AOR plus RegID

To view all active register details, use the following CLI syntax:

> show table addressContext <addressContextName> sipActiveRegisterNameStatus

admin@SBC>> show statustable addressContext defaultADDR_CONTEXT_1 sipActiveRegisterNameStatus
 67891 0
state                       completed;
contactURI                  sip:67891@10.54.80.101:7070;
nextHopIpAddress                    10.54.80.101;
nextHopPortNum              7070;
registrarIpAddressNEXT
              10.54.19.168;
registrarPortNum            7080;
externalExpirationTime      1800;
internalExpirationTime      3600;
creationTime                2016-01-28T06:39:34+00:00;
registrarDomainName            NEXT HOP   "";
endPointBehindNaptHOP    REGISTRAR      0;
natPinholeLearningStatus    none;
securityMechanismType   EXTERNAL    none;
registrationType            normal;
e2aeMediaSecurity           none;
isRoaming                   0;
transportProtocolToEndpoint udp;
transportProtocolToAS       udp;
externalExpirationTimeLeft  1602;
internalExpirationTimeLeft  3052;
[ok][2016-01-28 12:12:53]

Example 2: In this case, entire AOR name (userPart+hostname) is used as first parameter to get the information.

admin@SBC> show status addressContext default sipActiveRegisterNameStatus 67891@10.54.80.101 0
state    IP         PORT   IP        completed;
contactURI REGISTRAR  EXPIRATION  
AOR NAME            sip:67891@10.54.80.101:7070;
nextHopIpAddressID      STATE      10.54.80.101;
nextHopPortNum CONTACT URI             7070;
registrarIpAddress   ADDRESS    NUM   10.54.19.168;
registrarPortNum  ADDRESS    PORT NUM   TIME   7080;
externalExpirationTime     
----------------------------------------------------------------------------------------------------------------------
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   

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        

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   1800;
internalExpirationTime      3600;
creationTime                2016-01-28T06:39:34+00:00;
registrarDomainName         "";
endPointBehindNapt          0;
natPinholeLearningStatus    none2015-09-04T13:36:37+00:00;
securityMechanismTyperegistrarDomainName         none"";
registrationTypeendPointBehindNapt            normal0;
e2aeMediaSecuritynatPinholeLearningStatus    none;
securityMechanismType       none;
isRoamingregistrationType            normal;
e2aeMediaSecurity           0none;
transportProtocolToEndpoint udpnone;
transportProtocolToAS       udp;
externalExpirationTimeLeft  16063178;
internalExpirationTimeLeft  3056;
[ok][2016-01-28 12:12:48]2463;

Bulk Registration Support

...

Registration Establishment

...

Surrogate Registration Support

...

• 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

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.

Quick Re-registration on Alternate SIP Server When Primary Server is Down

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

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.

Quick Re-registration on Alternate SIP Server When Primary Server is Down

In Access scenarios, SIP Registrars on core side 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 In Access scenarios, SIP Registrars on core side 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,

To overcome this issue,  immediately when Primary is down and reverts when Primary SIP server is up. The status of the servers is detected through Address Reachability Service (ARS) blacklist. For every switch from primary to secondary/alternate or from secondary/alternate to primary,

IPSP Configuration

Four new flags are added to the registrarRecovery parameter. These new flags are introduced to the IPSP profile to configure this feature.

• registrarRecovery
  • newRegistrarIndex      
  • overRideInternalExpires
  • registrarFqdn  
  • registrarIpAddress

For configuring IPSP flags on PSX, refer to PSX Configuration.

request Command

registers to the alternate SIP server immediately when Primary is down and reverts when Primary SIP server is up. The status of the servers is detected through Address Reachability Service (ARS) blacklist. For every switch from primary to secondary/alternate or from secondary/alternate to primary,

Force PSX Query on Refresh Register

The A new CLI request queryPsxOnNextRefreshRegister command is used to force PSX query on subsequent refresh REGISTER. This enables new routing information configured in PSX to reflect in SBC when registrations are active for a long period of time.

The CLI request command syntax is :

...