<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dave, perhaps this is some variation on CSCuv04949 or CSCtr50458. I'm not sure if you're using SRTP for the media, or just using SIP/TLS for the signaling with RTP media. In any case, if you look at the list of caveats in the CallManager 10.5(2)SU3a release notes - yes the CallManager release notes - you'll see a handful of TLS and SRTP related caveats resolved, especially in the ES train upon which the SU3a build is based. I am referring to the section entitled "Resolved Cisco Unity Connection Caveats in 10.5(2)ES55; base ES for 10.5(2)SU3"</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">You might wish to try pulling up the Mixer and/or CuCsMgr logs for a call while it's working and when it begins to fail and attempt to look for any errors yourself. But in any case, it sounds to me like a TAC case is in order and prepare to supply them the logs if possible.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Regards,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 10:52 AM, Dave Wolgast <span dir="ltr"><<a href="mailto:dwolgas1@rochester.rr.com" target="_blank">dwolgas1@rochester.rr.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">Unity Connection 10.5(2)su2<div>CUCM 10.5(2)su2</div><div><br></div><div>We have a secure SIP integration set up between CUCM and UCxn, which works...for awhile.</div><div><br></div><div>After some number of hours/days, we stop getting rtp. The SIP setup happens exactly as expected, and the devices think that a call is happening, but the caller hears no audio...just dead air for the duration of the call. We are preferring g.711u but allowing g.729.</div><div><br></div><div>We temporary fix we have been using has been to remove the g.729 advertisement from the port group, reset the port group, then replace the g.729 advertisement and reset again. Reset itself doesn't seem to fix it, though I am not sure that there is anything specific about changing codec advertisement that is fixing it either.</div><div><br></div><div>Regardless, after awhile, it stops working again.</div><div><br></div><div>None of the publicly-visible defects seem to apply. Has anyone seen anything like this? Any tips for further troubleshooting?</div><div><br></div><div>I just wanted to check with the experts before opening a TAC case.</div><div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div>Dave Wolgast</div><div>Livonia, NY</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" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>