Skip to end of metadata
Go to start of metadata

In this section:

Availability: Since 4.2.4

Surrogate Registration

The SBC Core supports configuring surrogate registration information for a single IP Peer. Up to 256 Surrogate Registration entries are supported for each IP Peer.

The SBC 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.

Up to 256 surrogate registration profiles can be configured system-wide. Do not attach a surrogate registration profile to more than one peer.

 Up to 10,000 AoRs can be configured for surrogate registration system-wide.

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 SBC 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 SBC. The SBC 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 SBC.

When the SBC 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 SBC 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 SBC supports responding to challenges from AS for the following methods:

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

For surrogate registration configuration commands and examples, see the following wiki pages:

SIP Authentication Using Dedicated User Name

The SBC 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).

The SBC supports challenge requests such as REGISTER, INVITE, PRACK, UPDATE, and BYE for Surrogate Registration and IP Trunkgroup Authentication mechanisms. When a credential request is sent, a uri parameter is present in the Authorization or Proxy-Authorization header. The SBC automatically generates uri parameter for Authorization or Proxy-Authorization header with the Request-URI of the request (except “SIP/2.0 part”) for the challenge responses. If the SBC replies to a challenge as part of the Surrogate Registration functionality, the value must be within quotation marks (" ").

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.

To configure SIP Authentication, see the following pages:

Multiple IP-PBX for a Surrogate AoR

The SBC Core supports assigning a cluster of IP-PBXs to one particular Surrogate AoR involving IP Trunk Group (IPTG) Authentication, Surrogate Registration and associating a different IPTG for each IP-PBX cluster.

Assigning a cluster of IP-PBXs to a Surrogate AoR involves following steps:

  1. Group multiple PBXs to form a cluster.

  2. Map each cluster to an Ingress IPTG via IP Prefix.

  3. Create an ipPeer for each PBX in the cluster, and enable authentication. If you are converting from an existing setup, simply enable authentication under ipPeer.

  4. Create an Ingress IPTG facing the PBX cluster and enable IPTG Authentication. See Configure Ingress IPTG facing PBXs/Clusters below for example commands.
     
  5. Create an ipPeer using a dummy IP Address and tie this dummy IP address to the same ITPG facing the PBX via ingressIpPrefix. A dummy IP Address can be an unused private IP address.

    Do not assign a dummy IP Address to a PBX.



  6.  Configure Surrogate Registration under dummy ipPeer. 

  7. Create an Egress IPTG and enable IPTG Authentication. See Configure Egress IPTG Facing Core/Registrar below for example commands.
    1. Ensure authUserPart is the same as authUserName of the corresponding Surrogate Registration under IP Peer with the dummy IP Address. 
    2. Ensure authPassword is the same as regAuthPassword of the corresponding Surrogate Registration under IP Peer with the dummy IP Address. 


The following diagram illustrates the SBC configuration to accommodate this feature.

Figure : SBC IPTG Cluster Diagram

Configure Ingress IPTG facing PBXs/Clusters

  1. Set requireRegistration parameter to none.

    % set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> signaling registration requireRegistration none



  2. Configure Authentication feature under IPTG.

    % set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> signaling authentication
    Possible completions:
      authPassword           - <Can be left empty>
      authUserPart           - <Can be left empty>
      incInternalCredentials - <enabled>
      intChallengeResponse   - <enabled>



  3. Configure Surrogate Registration under IP Peer with dummy IP Address.

    % set addressContext <addressContext_name> zone <zone_name> IpPeer <IpPeer_name> <dummy_IpAddress> surrogateRegistration
    Possible completions:
      authUserName                  - authorizationUserName for surrogate registration.
      regAuthPassword               - Authentication password for surrogate registration (min 6 characters, max 32 characters).
      retryTimer                    - Retry time for surrogate registration.
      sendCredentials               - Defines how the Credentials will be sent.By default it is set to challengeForRegister.
      state                         - Defines if surrogate registration is enabled or disabled
      suppressRegRetryAfterAuthFail - Controls if the REGISTER needs to be send when REGISTER with credentials is challenged.
      surrRegProfile                - Surrogate registration profile.
      userPart                      - Userpart for surrogate registration.

    A dummy IP Address can be any unused private IP Address. Only set surrogate registration state to 'enable' after completing configuration on egress side.



  4. Enable Authentication under both ipPeer with dummy IP Address and ipPeer with PBX's IP Address.

    % set addressContext <addressContext_name> zone <zone_name> ipPeer <IpPeer_Name> authentication
    Possible completions:
      incInternalCredentials - <enabled>
      intChallengeResponse   - <enabled>
  5. Configure IP Peer without pathCheck.

    Ensure the pathCheck is Off for IP Peer with a dummy IP Address.

Configure Egress IPTG Facing Core/Registrar

Configure Authentication feature under IPTG.

% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> signaling authentication
Possible completions:
  authPassword           - <Authentication password for Trunk Group>
  authUserPart           - <userPart used for authentication>
  incInternalCredentials - <disabled>
  intChallengeResponse   - <disabled>