cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1169
Views
0
Helpful
5
Replies

Is there anyway to do anti-tromboning in CUCM/Jtapi

derrickgunter
Level 5
Level 5

Can Cisco CUCM/JTAPI handle tromboning for transfers or conferences?

TRANSFER Call flow is like this:

  1. Inbound call to agent A on CUCM (CiscoCallID 1).
  2. Agent A does outbound consult (CiscoCallID 2) to a DN (xDN) on another switch (could be another CUCM or SIP or other)
  3. xDN on the other switch transfer to agent B on CUCM (CiscoCallID 3).
  4. From real life perspective we have 2 calls:
    1. Inbound call to agent A
    2. Consult call between agent A and B.
  5. But from Cisco perspective we have 3 calls:
    1. Inbound call to agent A (CiscoCallID 1)
    2. Outbound call from A (CiscoCallID 2)
    3. Inbound call B (CiscoCallID 3)

CONFERENCE Call flow is like this:

  1. Inbound call to agent A on CUCM (CiscoCallID 1).
  2. Agent A does outbound consult (CiscoCallID 2) to a DN (xDN) on another switch (could be another CUCM or SIP or other)
  3. xDN on the other switch conferences in agent B on CUCM (CiscoCallID 3).
  4. From real life perspective we have 2 calls:
    1. Inbound call to agent A
    2. Consult call with agent A, xDN, and B.
  5. But from Cisco perspective we have 3 calls:
    1. Inbound call to agent A (CiscoCallID 1)
    2. Outbound call from A to xDN (CiscoCallID 2)
    3. Inbound call from xDN to B (CiscoCallID 3)

So, we have this tromboning effect.

QUESTION: Is it possible in CUCM/JTAPI to perform some kind of anti-tromboning so that the outbound consult (CiscoCallID 2) and return inbound (CiscoCallID 3) are collapsed to just one CiscoCallID?

Or is there some other solution or approach.

Thanks!
Derrick

5 Replies 5

smupadhy
Cisco Employee
Cisco Employee

Hi Derrick,

I discussed this with the team. There is no way in JTAPI to do that. As we understand it, there is no way to move signalling for a particular call, from one CUCM to another.

Thanks,

Thanks Smita.  Just for clarification...

In this case the outgoing consult may be going to a non Cisco switch, and then be coming back to the same CUCM from the non-Cisco switch.  I assume this makes no difference?

QSIG trunking allows for this type of optimization. When configured correctly QSIG trunk will recognize the loop back the renegotiate the signaling and media path to optimize the trunk usage. In this scenario CiscoCallID 2 and CiscoCallID 3 will be renegotiated into a 1 call CiscoCallID 4. JTAPI applications observing B will see a CiscoCallChangedEv.

QSIG is a industry standard and is typically supported by all switches. So the other switch can be a cisco or a non-cisco switch to use QSIG.

Thanks Mohan.  As I understand QSIG trunks are not common for North America.  Is this the case?

Yes. QSIG is more popular in Europe, not so much in North America.