Operators are using the AC client to do transfers.<div><br></div><div>Most all calls are a console transfer. Hello I have joe on the line, transferring. </div><div><br></div><div>UCCx is a ACD queue to the agent. Agent has AC installed for BLF / Lookups / etc</div>
<div><br></div><div>Why, a lot comes down to Stats. AC doesn't have the wallboards / reports / etc. (besides, I wasn't my design ;-)</div><div><br></div><div>--Scott<br><br><div class="gmail_quote">On Thu, Sep 23, 2010 at 6:22 AM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">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.<div>
<br></div><div>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. <br><div><br></div><div>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. </div>
<div><br><font color="#888888"><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
-Ryan</div></span>
</div></font><div><div></div><div class="h5">
<br><div><div>On Sep 22, 2010, at 5:16 PM, Scott Voll wrote:</div><br>Ryan--<div><br></div><div>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.</div>
<div><br></div><div>our setup is call comes in mgcp VGW --> UCCx --> agent (running AC) transfer to end phone.</div>
<div><br></div><div>Looking through the Bug tool kit, I find CSCsx37599</div><div><br></div><div><span><strong>Transfer fails when receiving redirect request during split operation </strong>
</span>
<span>
<br><b>Symptom:</b><br><br>A transfer into a CTI application may fail resulting in dead air to both the caller and the party that receives the transfer. <br><br><b><b>Conditions</b>:</b><br><br>This
can happen when the CTI application redirects the call after the
transfer completion has been started but has not yet finished.<br><br><b>Workaround:</b><br><br>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.<br><br><b>Further Problem Description:</b><br><br>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).<br><br><span style="font-size:large">So is this the same kind of issue?<br><br><span style="font-size:small">Yes I have opened a TAC case sr615518399 (and haven't heard from my TAC engineer all day)<br>
<br>Scott</span></span></span><br><div class="gmail_quote">On Wed, Sep 22, 2010 at 12:08 PM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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.<div>
<br></div><div>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).</div>
<div><br></div><div>If you are having a tough time with debugging just open a TAC SR. We see these quite frequently.</div><div><br><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
-Ryan</div></span>
</div>
<br><div><div><div></div><div><div>On Sep 22, 2010, at 1:55 PM, Scott Voll wrote:</div><br>Sounds really stupid, I know.<div><br></div><div>But how does a transfer work?</div><div><br></div><div>With a Conference, it uses the Conference resource.</div>
<div><br></div><div>We are having intermittent calls drop during a transfer and I'm trying to find an all in compassing reason.</div>
<div><br></div><div>originally I thought it was a soft phone issue. but it looks to be happening in house too.</div><div><br></div><div>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.</div>
<div><br></div><div>I can NOT reproduce on demand but it's happening frequently enough to try and get to the bottom of it.</div><div><br></div><div>TIA</div><div><br></div><div>Scott </div></div></div>
_______________________________________________<br>cisco-voip mailing list<div><br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br></div><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div><br></div></div></blockquote></div><br></div>
</div><br></div></div></div></div></div></blockquote></div><br></div>