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 :
[ 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 :
*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.
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.
Hi All, We are currently experiencing the issue that all IPPA agents cannot get incoming calls. All agents are logged in and in ready status. CTI ports are registered in CUCM. All services are up and running in UCCX. Is there anything in CUCM and the...
Hi everyone, I have a problem with incoming call on our cucm systems. when we received incoming call from external number phone (*such as mobile phone number), the ip phone screen is not get the caller-id or an unknown number appears on ip phone scre...
Hello:I have the next problem....I am trying to do XMPP Interdomain Federation between Cisco Presence Servers (cup) Version 10...I did every step of configuration as Cisco says:Turn On XMPP FederationConfigure SRV RegistersTurn on XMPP Federation Ser...
hello, we have a cisco UCCX server installed and working properly.Then out manager ask we must get a report about only work hours and another report about non-working hours but these report is not beeing in uccx reports. And I want to know where...
ello Experts , I am trying to use the record voice element feature in CVP as part of a project . The objective is to collect the audio captures from customer. Preferred approach is to detect the silence from customer end instead of customer manually ...