[cisco-voip] How does Transfer work?

[Scott Voll]

Operators are using the AC client to do transfers.

Most all calls are a console transfer.  Hello I have joe on the
line, transferring.

UCCx is a ACD queue to the agent.  Agent has AC installed for BLF / Lookups
/ etc

Why, a lot comes down to Stats.  AC doesn't have the wallboards / reports /
etc.  (besides, I wasn't my design ;-)

--Scott

On Thu, Sep 23, 2010 at 6:22 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> 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/52d5b7c0/attachment.html>