[cisco-voip] How does Transfer work?

[Ryan Ratliff]

Are your operators using the AC client to do the transfer or doing it on the phone?  AC is a CTI application and has the ability to use the CTI redirect operation which is a true one-step transfer.  With a redirect there is no held call, no split/join.  The redirected call is sent directly to the destination.

Is your UCCx script redirecting to the AC pilot point or to the agent directly?  I'm confused why you would need to combine AC with UCCx. 

The bug you mentioned is another way transfers can fail, but requires that the transfer destination be a CTI application like IPCC, AC, etc.  Unless UCCx is somehow pulling the call back after the agent puts it on hold I doubt this call flow is applicable to your situation.  That bug is also fixed in 7.1.5.  

-Ryan

On Sep 22, 2010, at 5:16 PM, Scott Voll wrote:

Ryan--

So as I'm playing detective, it sounds like (maybe) the common thread in all of this is that the operators are using the legacy AC client.

our setup is call comes in mgcp VGW --> UCCx --> agent (running AC) transfer to end phone.

Looking through the Bug tool kit, I find CSCsx37599

Transfer fails when receiving redirect request during split operation 
Symptom:

A transfer into a CTI application may fail resulting in dead air to both the caller and the party that receives the transfer.  

Conditions:

This can happen when the CTI application redirects the call after the transfer completion has been started but has not yet finished.

Workaround:

Either delay the CTI application so that the transfer can complete before the redirect occurs or delay the transfer completion until after the CTI application has redirected the call.

Further Problem Description:

Most commonly this is seen with Unity transferring to IPCC or Attendant Console. Both of these applications redirect inbound calls immediately and have no configurable option to delay. When Unity is doing a "release to switch" transfer it will complete the transfer as soon as the outbound call gets to the call proceeding state. For a call to a CTI route point (AC pilot) this is when the call is extended to the application, before the redirect. The easiest workaround here is to make Unity do a consultative transfer (ie wait for the call to be connected).

So is this the same kind of issue?

Yes I have opened a TAC case sr615518399  (and haven't heard from my TAC engineer all day)

Scott
On Wed, Sep 22, 2010 at 12:08 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
A transfer works by splitting the original call into two legs.  The first leg (with the original caller) is placed on hold.  The second (new) leg becomes for all intents and purposes a new call on the phone that initiates the transfer.  This leg is used for the consultative call.  When the Trnsfr softkey is hit for the second time the two call legs are joined back together.

There are several places within this process that can result in the call dropping.  Media negotiation is one, and would generally be a codec mismatch at the joining of the two call legs.   A sneakier one is where the hold fails for the original call leg.  This isn't always immediately obvious and so the transferring party will go on with the new call until they find that the transfer completion fails (either gracefully with a message to the phone or both legs just drop).

If you are having a tough time with debugging just open a TAC SR.  We see these quite frequently.

-Ryan

On Sep 22, 2010, at 1:55 PM, Scott Voll wrote:

Sounds really stupid, I know.

But how does a transfer work?

With a Conference, it uses the Conference resource.

We are having intermittent calls drop during a transfer and I'm trying to find an all in compassing reason.

originally I thought it was a soft phone issue.  but it looks to be happening in house too.

So even on a completely G711 call I'm getting calls drop.  Unfortunately I don't have Caller ID on the incoming calls so it's making it even harder to troubleshoot.

I can NOT reproduce on demand but it's happening frequently enough to try and get to the bottom of it.

TIA

Scott 
_______________________________________________
cisco-voip mailing list

cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100923/093bc1d2/attachment.html>