<div dir="ltr">Ed sent me his traces and I took a look. The transfer is failing due to the TWaitResponse timer kicking off. It looks like that hits after 12 seconds.<div><br></div><div><div>10645759.000 |22:58:50.306 |SdlSig |TWaitResponse |getting_secondary_call_info |Transferring(3,100,51,311897) |SdlTimerService(3,100,3,1) |2,100,13,430037.412135^10.192.2.164^CUCxnUM1-VI78 |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] </div>
<div>10645759.001 |22:58:50.306 |AppInfo |Transferring::getting_secondary_call_info_TWaitResponse - ERROR time out on waiting for correct transfer destination</div><div>10645759.002 |22:58:50.306 |AppInfo |Transferring - handleTransferErrorPreStart, ERROR fid=[4], Retaining Calls, xferring[3, 58262431], xferred[3, 58262428]. infoCause=63, clearCause=41</div>
</div><div><br></div><div><br></div><div><br></div><div>In the working call scenario, the destination answers the call within 12 seconds (10 seconds until Connect). In the failed scenario, we see the call isn't answered until the 13 second mark.</div>
<div><br></div><div>Does anyone know what the TWaitResponse timer corresponds to?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 12:04 PM, Daniel Pagan <span dir="ltr"><<a href="mailto:dpagan@fidelus.com" target="_blank">dpagan@fidelus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Ed:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Detailed CCM traces should suffice. If it indeed was a 12 second media exchange timeout, you should notice a missing SCCP or MGCP transaction after receiving
the ISDN Call Proceeding event. I would check to make sure I see the OpenReceiveChannel, StartMediaTransmission, and OpenReceiveChannelACK on the SCCP call-leg followed by a MDCX with SDP to the MGCP gateway and a 200 response – all immediately after ISDN
Call Proceeding comes in. If you notice one of these missing then it’s likely an MX timeout issue. I’ve recently seen an issue where StationD doesn’t ACK an OpenReceiveChannel signal, resulting in a MX timeout. Doubt it’s related to this problem though… my
issue was related to CTI ports.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">- Dan<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Ed Leatherman [mailto:<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, September 02, 2014 10:36 AM<br>
<b>To:</b> Daniel Pagan<br>
<b>Cc:</b> Sreekanth Narayanan; Mike Nickolich; Cisco VOIP</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [cisco-voip] SCCP/SDL trace question re:transfer<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Dan,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm not seeing a MXTimeout, however the "Cannot Complete Transfer" is 12 seconds after the ISDN Proceeding. Any special trace settings necessary to see that message?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">22:58:38.411 |AppInfo |In Message -- PriCallProceedingMsg -- Protocol= PriNi2Protocol<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">..<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">22:58:50.310 |AppInfo |StationD: (0331221) DisplayNotify timeOutValue=15 notify='Cannot Complete Transfer' content='Cannot Complete Transfer' ver=12.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Sep 2, 2014 at 9:34 AM, Daniel Pagan <<a href="mailto:dpagan@fidelus.com" target="_blank">dpagan@fidelus.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040">Ed:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040">As a test, are you able to recreate the issue when PSTN leg doesn’t answer for 12 seconds after the
transfer attempt? I ask because, based on the timestamps below, it seems the media exchange timer might be expiring. If you still have SDL traces, you can search for “MXTimeout”. If you find one, you should be able to backtrack 12 seconds and find the ISDN
Call Proceeding message that triggers CUCM’s attempt at connecting media between the two call-legs.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040">- Dan</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#404040"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Sreekanth Narayanan<br>
<b>Sent:</b> Tuesday, September 02, 2014 2:22 AM<br>
<b>To:</b> Ed Leatherman<br>
<b>Cc:</b> Mike Nickolich; Cisco VOIP<br>
<b>Subject:</b> Re: [cisco-voip] SCCP/SDL trace question re:transfer</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Hi Ed,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If the Unity is sending the 2nd transfer command as soon as the initial call setup begins, it looks more like a blind transfer. The other transfer type 'Supervise Transfer' is the
consult transfer. Have you tried to do blind transfers from SCCP phones?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">As per the RTS description, it's the responsibility of the CUCM to handle the call if the target of the transfer is busy or doesn't answer.<u></u><u></u></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black">
<span style="font-size:9.0pt;font-family:"Arial","sans-serif"">Release to Switch—Unity Connection puts the caller on hold, dials the extension, and releases the call to the phone system. When the line is busy or is not answered, the phone system—not Unity Connection—forwards
the call to the user or handler greeting. This transfer type allows Unity Connection to process incoming calls more quickly. Use Release to Switch only when call forwarding is enabled on the phone system.</span><u></u><u></u></li>
</ul>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Thanks</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black">Sreekanth</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On 1 September 2014 19:29, Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi Sreekanth,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The problem is inconsistent, but definitely more than say 20%. Load on our systems doesn't appear to be an issue, we did testing late at night/after hours and regular call volume
is very low then. We were able to duplicate the issue just with cell phones as the target, so it seems the problem is not just the answering service not picking up; not had a problem where direct calls weren't answered promptly.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">In looking through the trace files, it seems like Unity does a consult transfer even when set to "Release to switch", its just sending the 2nd transfer command as soon as the initial
call setup starts - IIRC it was doing it right after we got "PROCEEDING" from PSTN. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I did check out the T301 timer in CUCM but its still set to 3 minutes - so we're not hitting that one at least.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Your idea of reproducing the issue with a consultative transfer from a phone is a good one, we'll give that a try.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For now we just have their line directly forwarded after hours manually and skipping Unity completely and it works. They pay per call to the answering service though so they really
want the front end IVR to pick up first. It is a suicide prevention hotline and they are very sensitive to us throwing solutions at it until something works - I'll have to at least pin down the part that is failing before they will accept a workaround. I have
a mini UCCX script setup to do a call redirect to the number, if I can verify that it is the consultative transfer that is the issue I plan on just sending the call from Unity to UCCX and letting UCCX get the call offsite - will probably just move the whole
call tree to UCCX for IVR at that point.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for your ideas!!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
Ed<u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Sep 1, 2014 at 3:04 AM, Sreekanth Narayanan <<a href="mailto:sknth.n@gmail.com" target="_blank">sknth.n@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi Ed,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Could it be possible that the answering service does not answer the call sometimes? This may be causing the timeout.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What is the frequency of this issue? In 10 calls transferred this way, how many times do you see it?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Maybe you could try a couple of different tests here to try and isolate the issue:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks<br>
Sreekanth<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On 1 September 2014 00:28, Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">Hello!<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">On the trace side of things, for the transfer leg on a failure I see:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">19:55:27.146 : Unity "presses transfer" , dials out the digits<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">19:55:29.853 : Q931 IN from PSTN for the transfer leg, PROGRESS message<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">19:55:29.855 : CUCM OUT to Unity: Call State Ring out<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b>19:55:41.020 : CUCM OUT to Unity: DisplayNotify timeOutValue=15 notify='Cannot Complete Transfer' content='Cannot Complete Transfer' ver=12</b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Any ideas much appreciated<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Ed<br clear="all">
</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="color:#888888"> </span><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">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><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="color:#888888">--
<br>
Ed Leatherman</span><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <br>
Ed Leatherman<u></u><u></u></p>
</div>
</div></div></div>
</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>