cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3918
Views
20
Helpful
1
Comments
avinsrid
Level 1
Level 1

Using Dummy SIP Trunk to get REFER based transfers working

In CUCM Versions below 9.X, we have a limitation of SIP Route Pattern not allowing us to point to a SIP Trunk that is already associated with a route group. This creates problems in call scenarios such as below :

SCENARIO :


[ Home-1 Cluster] User Calls 7777 --> CUSP ( via SIP Trunk CUSP1) --> CVP --> ICM (Script Runs, If no agents available = Kick out to 110011 = Hunt Pilot on Home-2 Cluster) --> CVP --> CUSP ( via SIP Trunk CUSP1) --> Home-2 Cluster Hunt Pilot 110011 [Fails]

If we use a RE-INVITE method of performing a transfer, this scenario can be quite easy to achieve. However, at times customers would like to use the REFER mechanism for transfer. During such a scenario, CUCM has the capability of accepting the INBOUND REFER and handles this call based on the SIP Route Pattern configuration.

In the above case, as an example this is what should happen ideally from signalling perspective :

CUCM                                    CUSP1 Trunk
                 --INVITE-->
                <--TRYING--
               <--200 OK--

                 -- ACK-->
               <--REFER--
         --202 ACCEPTED-->

*Note REFER here will have "Refer to" header with the destination IP Address that CUCM needs to send the new INVITE to for transfer purpose. CUCM will generate this new INVITE based on the "IPAddress Routing" type SIP Route Pattern that is configured.

ISSUE we face during configuration  :

Note that once the REFER comes, the "Refer to" header would have the destination IP Address same as the destination IP Address of the CUSP1 Trunk that CUCM originally initiated the INVITE to. Say we have a set up as below:

Route Pattern 7777 --> Route List (RL-1) --> Route Group --> DEVICE 1: CUSP1 || DEVICE 2: CUSP2

Now to get the REFER transfer working for above call scenario, we will need CUSP1 to be configured under the SIP Route Pattern. Since it is associated to a route group, this configuration is a restriction on CUCM. The only workaround would be to point the SIP Route Pattern to RL-1( Route List), however this is a feature made possible on CUCM Versions 9 and above only.

WORKAROUND :

  • Configure an alternate SIP Trunk CUSPTEST that has the same destination IP Address as that of CUSP1. Since we cannot create two SIP Trunks with same destination IP Address, associate the new SIP Trunk with a SIP TRUNK SECURITY Profile "TEST_PROFILE" that has incoming port as any dummy port such as 5065.
  • We don't need to bother about the dummy incoming port because CUSP is never going to talk to CUCM on that port for incoming messages.
  • Once we have associated the new SIP Trunk CUSPTEST with the "TEST_PROFILE" we can now successfully associate this SIP Trunk to the SIP Route Pattern to get the above call flow working.

This is a great example of how a dummy SIP Trunk can be used to get a simple REFER transfer working in such a deadlock situation.

Hope this helps!

Regards,

Avinash

Comments
Prashanthi Velpula
Cisco Employee
Cisco Employee

This is very informative post Avinash !

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: