Call Flow Examples
The call flows in this topic demonstrate how the SBC identifies the surrogate-agent for an incoming call for the purpose of authentication. Your surrogate-agent, session-agent, and sip-interface configuration are key to processing these calls.
Call Flow 1
This first call flow depicts the SBC successfully handling the end station authentication. In this case, the SBC identifies the surrogate-agent by matching PPI with the register-user and register-host parameters in the surrogate-agent configuration.
surrogate-agent:
register-host: oracle.com
register-user: 123
source-ip-prefix: 192.168.0.0/16
Next, the SBC matches the source IP of the INVITE request with the source-ip-prefix parameter in the surrogate-agent configuration to determine if it should perform surrogate authentication. Note the source IP address, 192.168.1.1 falls in the range of the setting, 192.168.0.0/16.
![This image depicts the OCSBC using the source-ip-prefix configuration to authenticate a calling end station behind a surrogate agent. This image depicts the OCSBC using the source-ip-prefix configuration to authenticate a calling end station behind a surrogate agent.](img/sagentmatch-works2.png)
The SBC does not reference the customer-next-hop parameter because you have configured the source-ip-prefix with some value.
Call Flow 2
This next call flow depicts the SBC not handling an end station authentication. In this case, the source-ip-prefix, configured to 172.16.0.0/16, does not match the source IP address.
surrogate-agent:
register-host: oracle.com
register-user: 123
source-ip-prefix: 172.16.0.0/16
![This image depicts the OCSBC bypassing authentication because the source IP Prefix configuration does not match the FROM. This image depicts the OCSBC bypassing authentication because the source IP Prefix configuration does not match the FROM.](img/sagentmatch-breaks2.png)
Again, the SBC does not reference the customer-next-hop parameter.
Call Flow 3
Consider this next case, wherein the source-ip-prefix is not configured. But the relevant configuration, shown below, includes a customer-next-hop configuration that provides a match.
surrogate-agent:
register-host: oracle.com
register-user: 123
customer-next-hop: SA1
source-ip-prefix: <empty>
session-agent:
hostname: SA1
ip-address: 192.168.1.1
![This image depicts the OCSBC using the customer-next-hop configuration to authenticate a calling end station behind a surrogate agent. This image depicts the OCSBC using the customer-next-hop configuration to authenticate a calling end station behind a surrogate agent.](img/custnext-works2.png)
Call Flow 4
Consider this next case, wherein the surrogate-agent configuration fails to identify the source correctly. Because the register-host and register-user values do not match either the PPI or FROM presented in the INVITE, the SBC does not have a means of forwarding the INVITE, so it replies with '480 - No Routes Found' message.
surrogate-agent:
register-host: acmepacket.com
register-user: 486
customer-next-hop: <any value>
source-ip-prefix: <any value>
![This image depicts the OCSBC failing to find a route to the surrogate agent due to configuration. This image depicts the OCSBC failing to find a route to the surrogate agent due to configuration.](img/sagentmatch-480-2.png)
Separate from the feature, the SBC could use a local-policy or other routing configuration, to route this call.