<div dir="ltr">And a good morning to you sir!<div><br></div><div>DTMF: Right, I wasn't saying DTMF mismatch was causing one way audio, I was saying that one cannot simply ascertain whether an MTP/XCODE is involved based on audio codec parameters alone.  One would need to consider DTMF as well, and possibly a few other parameters, such as Early Offer (Forced) on trunks, require TRP or MTP on trunks/phones.</div><div><br></div><div>IP Trust List: I have never heard of a stressed CPU causing a delay in processing the trusted list; however, I would suspect that the net result would be a failed call setup and the phone wouldn't ring at all.  I have not yet seen the trusted list get in the way of a SIP dialog past the initial SIP Request.  Then again, what I've seen is not necessarily what's true.</div><div><br></div><div>On a related topic, I have seen a CUBE not send a 100 response back to an INVITE for no apparent reason other than it just didn't want to.  It wasn't CPU related, but could have been CPS related.</div><div><br></div><div>Isn't it also interesting that the phone received 2 packets of audio?  That would indicate that the RTP stream was established.</div><div><br></div><div>And a hold/resume would cause a delay offer RE-INVITE to setup the audio once more, unless they're using the "send send/receive on mid-call invites" on their SIP Profile, or the duplex streaming enable svc param in CUCM, or the mid-call signaling media change in voice service voip on the CUBE.  All of which we don't know.</div><div><br></div><div>I would say seeing the SIP logs from a call that fails to setup correctly, and then uses hold/resume to fix it would be good, as well as a call that works to another building, so we can compare them.</div><div><br></div><div>Lastly, the statement that 2 of 30 buildings are impacted on a metro ethernet, really points the finger at layer 3 routing and/or security appliances.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 6, 2018 at 8:57 AM Ryan Huff <<a href="mailto:ryanhuff@outlook.com">ryanhuff@outlook.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="auto">
<div><span></span></div>
<div>Good morning to you Mr. Holloway :)!</div>
<div><br>
</div>
<div>DTMF: Generally speaking, mis-matched DTMF methods, in my experience, presents with different symptoms than shown on that screenshot of the phone.</div>
<div><br>
</div>
<div>SIP ACL: Correct, only applies to signaling, and if blocked, would ultimately lead to a loss of RTP (but would then generally lead to the call being disconnected and in most cases, stop the call from even setting up. However, in a stressed CPU scenario
 (more common than you might think, ACL application can be delayed). This would lead into my question about how long the call was staying connected and what call flow that screen shot depicts (in or out). I assume an inbound call based on the OP using the word
 “caller”.</div>
<div><br>
</div>
<div>The reason I suggest adding media and signaling addresses into the sip ACL list is because some carriers will send signaling and media from the same address or pool of addresses. Just did one not too long ago like that.<br>
<br>
<div id="m_6303772402110252289AppleMailSignature">Sent from my iPhone</div></div></div><div dir="auto"><div>
<div><br>
On Feb 6, 2018, at 9:22 AM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Ryan,
<div><br>
</div>
<div>For what you said here:</div>
<div><br>
</div>
<div><i>"Your call doesn’t appear to have a need for MTP or Transcoding (G711 both sides and matching sample sizes); so I wouldn’t start there."</i></div>
<div><br>
</div>
<div>Don't forget that DTMF relay needs to match too, and this is something, in my opinion, that people miss-configure a lot!  In fact, I see people with h245 alpha on their SIP dial peers?  Like what?  Typically, the SIP ITSP will support RTP-NTE (RFC2833
 [RFC 4733]) only, and your CUBE will need to inter-work that DTMF with an OOB DTMF relay, such as SIP NOTIFY.  But then your SIP Trunk Sec Prof will need to allow Unsolicited Notifications in order for that to work.  Also, some devices can support RTP-NTE,
 but usually your CTI based apps cannot.  E.g., UCCX<br>
<div><br>
</div>
<div>And for here:</div>
<div><br>
</div>
<div><i>"CUBE: ip trusted address list (make sure all provider signaling and media addresses are authorized or ip authentication is off (which I do not recommend) and make sure you include any CUCM addresses that are not used in dial peers)."</i></div>
<div><br>
</div>
<div>Since this feature is just for signaling, and the call does establish, this wouldn't be the cause of an RTP issue, and you wouldn't be putting your media addresses in here.</div>
<div><br>
</div>
<div>Do you agree with both of those remarks, or did I misunderstand something?</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Feb 5, 2018 at 5:14 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div><span></span></div>
<div>
<div><span></span></div>
<div>
<div><span></span></div>
<div>Empirically, this “looks” like one way audio. How long will the call stay connected? Indefinitely? 30 seconds? 2 minutes?</div>
<div><br>
</div>
<div>Your call doesn’t appear to have a need for MTP or Transcoding (G711 both sides and matching sample sizes); so I wouldn’t start there.</div>
<div><br>
</div>
<div>Check these items and see what you find;</div>
<div><br>
</div>
<div>CUBE: ip trusted address list (make sure all provider signaling and media addresses are authorized or ip authentication is off (which I do not recommend) and make sure you include any CUCM addresses that are not used in dial peers).</div>
<div><br>
</div>
<div>CUBE: double check your media and signal bindings and make sure they are binding correctly. Are you globally binding or dial peer binding?</div>
<div><br>
</div>
<div>CUCM: verify the SIP trunk points to the CUBE interface that signaling is bound to (generally the same interface media would be bound to as well).</div>
<div><br>
</div>
<div>CUBE: </div>
<div>#logging buffered 10000000</div>
<div>#enable debug ccsip messages</div>
<div><br>
</div>
<div>Place a call and then look at the logs. Do you see any SIP error messages in the 4xx, 5xx (or more rare 6xx) range?</div>
<div><br>
</div>
<div>As a quick gut check, if you can, enable “MTP Required” on the CUCM SIP trunk facing the CUBE (and make sure it has access to an MRGL/MRG that uses a CUCM node for MTP) and reset the trunk and test a call. If this works, it likely means you’re facing a
 network path issue between the phone’s IP network and the network of the CUBE interface facing CUCM.</div>
<div><br>
</div>
<div>Outside of that, like Anthony said, it could be almost anything. A “sh run” or “sh tech” on the cube with a logging buffer from a ccsip messages during a failed call will generally get the ball rolling for most of us on this list in terms of offering targeted
 assistance.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Ryan</div>
<div></div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<div><br>
On Feb 5, 2018, at 2:37 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:<br>
<br>
</div>
</div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">The fact that you received 2 packets is interesting.  Tells me that there is routing happening correctly...to some degree.
<div><br>
</div>
<div>If you go to the web page of the phone and click on stream 1, does the far end IP address match your CUBE address?</div>
<div><br>
</div>
<div>Also, there's a lot of settings that need to be considered when implementing SIP, such as:</div>
<div><br>
</div>
<div>Early Offer and MTP usage</div>
<div>PRACK/Early Media</div>
<div>Offfer/Answer (Capabilities)</div>
<div>Interface Binding</div>
<div>Transport Protocol</div>
<div>OPTIONS Ping</div>
<div>Duplex Streaming</div>
<div>Midcall Signaling</div>
<div>Timers</div>
<div>etc.</div>
<div><br>
</div>
<div>Depending on your setting, a lot of different possibilities exist for why you might have the experience you have.  If you could paint a clearer picture of your scenario, that might help out.</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<div dir="ltr">On Fri, Feb 2, 2018 at 5:47 PM Jonatan Quezada <<a href="mailto:jonatan.quezada@chemeketa.edu" target="_blank">jonatan.quezada@chemeketa.edu</a>> wrote:<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I get that this is usually routing but, is it also routing when the issue is intermittent?
<div><br>
</div>
<div>our call flow is like so</div>
<div><br>
</div>
<div>CentLink(Provider) ----siptrunk30Meg-PPP(IQ-private)---Cube---CUCM10.5, uccx,unity</div>
<div><br>
</div>
<div><image.png><br>
</div>
<div><br>
</div>
<div>bonus facts, I have an operator who is in one of the two most affected buildings and she can recover the call after hold, resume,hold,resume sequence. then full rtp stream is there and she can hear and speak with caller.</div>
<div><br>
</div>
<div>are there SIP state change timers I can adjust, I want to tread lightly though because out of all of our outreachs seperated by a metro ethernet hub and spoke topology and almost 30 buildings here on main campus only 2 seem to be affected.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br clear="all">
<div><br>
</div>
-- <br>
<div class="m_6303772402110252289m_-2619895726589588286m_9197210602978245346gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><font face="arial, helvetica, sans-serif" size="2">For immediate assistance please reach out to Chemeketa IT Help Desk at
<a href="tel:(503)%20399-7899" value="+15033997899" target="_blank">5033997899</a></font></div>
<div><font face="arial, helvetica, sans-serif" size="2">-or-</font></div>
<div><font face="arial, helvetica, sans-serif" size="2">Visit the help center from your employee dashboard found here:</font></div>
<div><font face="arial, helvetica, sans-serif" size="4"><b><a href="https://dashboard.chemeketa.edu/helpcenter/default.aspx" target="_blank">https://dashboard.chemeketa.edu/helpcenter/default.aspx</a></b><br>
</font></div>
<div><font face="arial, helvetica, sans-serif" size="4"><br>
</font></div>
<div dir="ltr"><font face="arial, helvetica, sans-serif" size="4"><br>
</font></div>
<div dir="ltr"><font face="arial, helvetica, sans-serif" size="4">Johnny Q</font></div>
<div dir="ltr"><span style="font-family:arial,helvetica,sans-serif;font-size:small">Voice Technology Analyst - TelNet</span><font face="arial, helvetica, sans-serif" size="4"><br>
</font>
<div><font face="arial, helvetica, sans-serif" size="4">Chemeketa Community College</font></div>
<div><span style="font-size:12.8px"><a href="mailto:Johnny.Q@chemeketa.edu" target="_blank">Johnny.Q@chemeketa.edu</a></span></div>
<div><font size="1"><span style="font-family:arial,helvetica,sans-serif">Building 22 Room 131</span><br>
</font></div>
<div><font face="arial, helvetica, sans-serif" size="1">Work <a href="tel:(503)%20399-5294" value="+15033995294" target="_blank">
5033995294</a></font></div>
<div><font face="arial, helvetica, sans-serif" size="1">Mobile <a href="tel:(971)%20218-2110" value="+19712182110" target="_blank">
9712182110</a></font></div>
<div><span style="font-family:arial,helvetica,sans-serif;font-size:x-small">SIP <a href="tel:(503)%20540-6686" value="+15035406686" target="_blank">
5035406686</a></span><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<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" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<div dir="auto">
<div>
<div>
<div>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div></div></blockquote></div>