<div dir="ltr">Hi Ed,<div><br></div><div>Could it be possible that the answering service does not answer the call sometimes? This may be causing the timeout.</div><div>From the POV of the CUCM, this is just another regular outgoing call over PRI starting from a VM port (which acts like an SCCP phone), which would then do the transfer to the initial caller.</div>
<div>The transfer type in your case seems to be semi-attended or consult transfer and not blind. I don't know if this can be changed on Unity.</div><div><br></div><div>What is the frequency of this issue? In 10 calls transferred this way, how many times do you see it?</div>
<div>Maybe you could try a couple of different tests here to try and isolate the issue:</div><div>1. Make direct calls from an IP phone (sccp preferably) to the answering service and see if the answering service picks the call up every time without fail.</div>
<div>2. Make an inbound call to the CUCM from PSTN, and direct this call to an sccp phone (this is replacing the Unity), and then do a blind, consult transfer (2 different tests) to the answering service and see if you can reproduce the problem.</div>
<div><br></div><div>Thanks<br>Sreekanth</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 September 2014 00:28, Ed Leatherman <span dir="ltr"><<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello!<div><br></div><div>I'm trying to help chase down a intermittent issue where Unity needs to transfer a caller off-site to an answering service, and sometimes the transfer doesn't complete and the caller gets left on-hold. I was hoping someone could explain a message i'm seeing in the traces during a failure.</div>

<div><br></div><div>SCCP integration to unity connection. 9.1 software versions on both CUCM and Unity. MGCP to PRI gateways. All gateways are set to offnet and service parameter is configured to allow transfers between offnet to rule that out as a issue.<br>

</div><div><br></div><div>On the trace side of things, for the transfer leg on a failure I see:</div><div>19:55:27.146 : Unity "presses transfer" , dials out the digits</div><div>19:55:29.853 : Q931 IN from PSTN for the transfer leg,  PROGRESS message</div>

<div>19:55:29.855 : CUCM OUT to Unity: Call State Ring out</div><div><b>19:55:41.020 : CUCM OUT to Unity: DisplayNotify timeOutValue=15 notify='Cannot Complete Transfer' content='Cannot Complete Transfer' ver=12</b></div>

<div><br></div><div>It looks like an abnormal amount of time for the call to connect, is that a possible reason for the "Cannot Complete Transfer" message? Is the timeout tweakable someplace?<br></div><div><br>
</div>
<div>On successful tries, the transfer leg connects faster (less than 10 seconds). So far we haven't found anything else different on our own; have a TAC case open on it but getting shuffled between groups now (unity team wants CUCM team to look at it).</div>

<div><br></div><div>Unity never seems to retrieve the caller from hold or try again, eventually the caller hangs up (I see the the DISCONNECT message from PSTN) at which point that call leg gets torn down.<br></div><div>
<br>
</div><div>Any ideas much appreciated</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Ed<br clear="all"><div><br></div>
</div></font></span></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>