[cisco-voip] How does Transfer work?

[Scott Voll]

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/20100922/0cd2f164/attachment.html>