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
userPartat the surrogate registration level. With this method, you cannot associate a
surrRegprofilewith this peer.
- Multiple AoRs for IP Peer for surrogate registration—Associate more than one AoR to the same peer by configuring and attaching a
surrRegprofileto the IP peer. When using this profile, you cannot configure
userPartat 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:
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:
Group multiple PBXs to form a cluster.
- Map each cluster to an Ingress IPTG via IP Prefix.
- 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.
- Create an Ingress IPTG facing the PBX cluster and enable IPTG Authentication. See Configure Ingress IPTG facing PBXs/Clusters below for example commands.
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.
- Configure Surrogate Registration under dummy ipPeer.
- Create an Egress IPTG and enable IPTG Authentication. See Configure Egress IPTG Facing Core/Registrar below for example commands.
authUserPartis the same as
authUserNameof the corresponding Surrogate Registration under IP Peer with the dummy IP Address.
authPasswordis the same as
regAuthPasswordof the corresponding Surrogate Registration under IP Peer with the dummy IP Address.
The following diagram illustrates the SBC configuration to accommodate this feature.
Configure Ingress IPTG facing PBXs/Clusters
requireRegistrationparameter to none.
Configure Authentication feature under IPTG.
Configure Surrogate Registration under IP Peer with dummy IP Address.
A dummy IP Address can be any unused private IP Address. Only set surrogate registration state to 'enable' after completing configuration on egress side.
Enable Authentication under both ipPeer with dummy IP Address and ipPeer with PBX's IP Address.
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.