<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#404040;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">If you’re certain the hold request is coming from IM&P, and the hold request is in reference to the call reference (CI) associated with the call in question,
then my suggestion would be to open a TAC case. At this point, assuming this finding is applicable to the problem at hand, and end-user intervention isn’t the cause, then it’s possibly a new or existing defect. The only thing I could add here would be to provide
TAC with the CI numbers and process IDs associated with the call-leg being placed on hold to speed up the process. There’s probably some information they can dig up in Topic Search if there’s history to this issue…
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">But I still wonder if these events are actually applicable to the problem you’re facing. Providing this information to TAC might only prolong RCA if it isn’t
related to the problem at hand. One thing I would certainly confirm is the hold request coming into CCM from CTIDeviceLineMgr to StationD (or SIPStationD) should contain the IP address of the device sourcing the request. In this case it should be IM&P. More
importantly, I would also ensure the hold request is for the correct CI - if this isn’t confirmed then further troubleshooting could involve lots of wheel spinning with no progress. My experience w/ Lync is limited but SIP transactions off the Lync server
should help you determine if the hold request is sourcing from there, passed to IM&P, then sent to CUCM via QBE/CTI. Either way, this should help determine the source of this hold request (assuming it’s related of course).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">I wasn’t able to find any public defects related to this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">Sorry this isn’t a root cause but hope you find it helpful regardless.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">- Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></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"> cisco-voip [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Reto Gassmann<br>
<b>Sent:</b> Tuesday, November 10, 2015 11:17 AM<br>
<b>To:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> Re: [cisco-voip] called party hears music on hold<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><br>
I looked at the log files (SDL Trace) and found a CtiLineCallHoldReq that comes from the IM&P server. It looks like RCC with Lync has something to do with it. I found something similar in the Cisco Support Community:<o:p></o:p></p>
<div>
<p class="MsoNormal"><a href="https://supportforums.cisco.com/discussion/10576466/being-placed-hold">https://supportforums.cisco.com/discussion/10576466/being-placed-hold</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It says that is has something to do with the status of the previous call did not clear the "In a call" status from CUPS in OCS.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, I could not find out, when there is a problem with clearing the In a call status.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards Reto<br>
<br>
Am Donnerstag, 5. November 2015 schrieb Wes Sisk (wsisk) :<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">I tracked one of these down once several years back:<br>
<br>
a calls b<br>
a puts call on hold<br>
b transfers call to c<br>
c answers and hears MoH<br>
<br>
when a, b, and c are all phones registered on the same node/cluster this shouldn’t happen. However, if the call from a to b traverses a trunk (SIP/H.323/MGCP) then there is no “hold” state/communication/update in the signaling stream to prevent the transfer
from b to c.<br>
<br>
Just a thought.<br>
<br>
-w<br>
<br>
On Nov 5, 2015, at 10:57 AM, Reto Gassmann <<a href="javascript:;">voip@mrga.ch</a>> wrote:<br>
<br>
Hello Group<br>
<br>
we have a strange problem on our UCM 10.5, that sometime happens.<br>
<br>
If someone calls my IP Phone (7961) and I pick up the call, I hear music on hold. The caller then puts the call on hold and then gets back to the call. Now music on hold is gone and we can talk.<br>
<br>
Has anyone had this issue before?<br>
<br>
Regards Reto<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="javascript:;">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><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>