Oracle SBCs can be used to integrate different solutions and making changes in its behavior and the way it processes specific SIP methods. In this entry we will review a scenario where a transfer needs to be implemented in order to have a correct integration with different elements in the network.

This is a graphical view of the scenario we will be working, let’s think about a customer calling in and the call is answered in a SIP IVR (Interactive Voice Response) system that when needed, the customer call is then transferred to a live agent in an ACD:

As you can see in the image above Oracle SBC can provide the solution, making the proper changes in the configuration. Let’s now define our scenario with devices and IP addresses (we will use the same scenario we have used previously having 3 realms, please refer to those posts in case of any doubt):

Let’s summary the configuration made:

1. phy-interface

name 		Customer
operation-type	Media
slot		0
port		0

name 		IVR
operation-type	Media
slot		1
port		1

name 		ACD
operation-type	Media
slot		1
port		2

2. network-interface

name		Customer
ip-address	192.168.200.1
netmask		255.255.255.0
gateway		192.168.200.100
hip-ip-list	192.168.200.1
icmp-address	192.168.200.1

name		IVR
ip-address	192.168.100.1
netmask		255.255.255.0
gateway		192.168.100.100
hip-ip-list	192.168.100.1
icmp-address	192.168.100.1

name		ACD
ip-address	192.168.101.1
netmask		255.255.255.0
gateway		192.168.101.100
hip-ip-list	192.168.101.1
icmp-address	192.168.101.1

3. realm-config

identifier		Customer
network-interfaces	Customer:0

identifier		IVR
network-interfaces	IVR:0

identifier		ACD
network-interfaces	ACD:0

4. sip-interface

realm-id		Customer
   sip-port
      address	192.168.100.1

realm-id		IVR
   sip-port
      address	192.168.100.1

realm-id		ACD
   sip-port
      address	192.168.101.1

5. steering-pool

ip-address	192.168.200.1
start-port	20000
end-port	21999
realm-id	Customer

ip-address	192.168.100.1
start-port	30000
end-port	31999
realm-id	IVR

ip-address	192.168.101.1
start-port	40000
end-port	41999
realm-id	ACD

6. session-agent

hostname	Customer
ip-address	192.168.200.100
realm-id	Customer

hostname	IVR
ip-address	192.168.100.100
realm-id	IVR

hostname	ACD
ip-address	192.168.101.100
realm-id	ACD

7. local-policy

local-policy
        from-address		*
        to-address		100
        source-realm		Customer
        description		Initial Call/Refer received
        policy-attribute
                next-hop			IVR

As you can see in the previous local-policy configuration, there is only one bridging connecting the customer realm to the IVR realm, this will help us to see the behavior of the transfer when it is requested by the IVR, lets test calling 100 in the customer softphone, and when the call is answered in the IVR, request a transfer of the current call to 300 which represents the ACD:

As you can see in the above image, REFER transaction fails as the customer softphone doesn’t know how to resolve that request.

In this case we will use a feature called refer-call-transfer which converts a received REFER method into an INVITE method (REFER is created from the INVITE settings, we will see this later), allowing the SBC to transfer a call without having to proxy the REFER back to the other UA. Refer to Oracle documentation for more information and scenarios where this configuration can fail and success.

Refer-call-transfer works in a realm and session agent level, taking preference with the session agent, as we defined session agents for all devices, IVR session agent will be the only place we will enable it. Other important configuration we need to add is a new local policy that will route the new INVITE to the ACD realm. Time to see the configuration added to make this work:

With changes required complete, its time to test again:

As you can see in the image above, call is answered normally by the IVR, then a REFER is requested by the IVR to the SBC interface 192.168.100.1, then the next message is the INVITE seen at the end of the screenshot.

This flow demonstrate how the INVITE is generated with the REFER method request, but lets take a closer look on the messages (we will omit the SDP and focus on the SIP headers):

This is the REFER message:

This is the INVITE generated from that REFER message (Request line and To header are created from the Refer-to header and from is modified to show the Customer original number and the contact number to show the original number and the IP address of the ACD sip-interface in the SBC).

This concludes our entry.