<div dir="ltr">In my experience, turning up SIP services is like peeing an onion, you do it one layer at a time. I don't just swoop in a blast the CUBE with all these commands that worked in the past, rather, I turn on the necessary ones first (sip to sip) and then starting layering on new commands as my pre-testing exposes their need. It's really too bad IOS config doesn't have a commenting feature, so when you do a show run you can read comments on why a command is present.<div><br></div><div>Some commands that seem to always be needed are:</div><div><br></div><div><div><font face="monospace, monospace">voice service voip<br></font></div></div><div><font face="monospace, monospace"> mode border-element ; Not really required unless doing local transcoding interfaces, </font></div><div><font face="monospace, monospace"> ; which I'm usually not, but I put this in anyway for the show cube commands</font></div><div><font face="monospace, monospace"> allow-connections sip to sip ; should be obvious and really the only required command to enable CUBE </font></div><div><div><font face="monospace, monospace"> sip</font></div><div><font face="monospace, monospace"> midcall-signaling passthru media-change ; Suppresses most chatter from peer but passes any media changes required</font></div><div><font face="monospace, monospace">!</font></div></div><div><font face="monospace, monospace">voice iec syslog ; Awesome for logging error messages that would otherwise go unnoticed<br></font></div><div><div><font face="monospace, monospace">dial-peer voice 100 voip ; Not a complete DP config, just some important bits</font></div><div><font face="monospace, monospace"> session protocol sipv2 ; Should be obvious<br></font></div><div><font face="monospace, monospace"> dtmf-relay sip-kpml rtp-nte digit-drop ; I've seen CUC receive double digit presses without the drop<br></font></div><div><font face="monospace, monospace"> codec g711ulaw ; feel free to use a voice class to the PSTN, but if migrating from PRI to SIP, </font></div><div><font face="monospace, monospace"> ; then g729 is a step backwards in quality and your SIP trunk may receive negative reviews</font></div><div><font face="monospace, monospace"> ip qos dscp cs3 signaling ; if you're into CS3 vs AF31</font></div><div><font face="monospace, monospace"> no vad ; should be obvious</font></div><div><font face="monospace, monospace"> voice-class sip options-keepalive ; This is such a must now. Always turn on SIP OPTIONS where you can, </font></div><div><font face="monospace, monospace"> ; even in CUCM SIP Profile for the trunk. (Only needed on outgoing DP)</font></div><div><font face="monospace, monospace"> ; And now you don't have to tweak timers and retries under sip-ua</font></div><div><font face="monospace, monospace">!</font></div></div><div><br></div><div>Also, I don't always go straight to binding the media and control, because most of the time I have two interfaces for enterprise side and ITSP side, and I let the Layer 3 routing decide which interface is best to egress. But if I had, for example, a Loopback interface which I needed to bind to, then I would do it at the Dial-Peer level.</div><div><br></div><div>Lastly, I don't even use the address-hiding command, as address-hiding is not needed under normal circumstances; it's a natural part of CUBE being a back to back user agent. Never would your internal enterprise IP addresses be sent to the ITSP...normally. If you are however, using SDP pass thru, or SIP transparencies, then yes they could. The <a href="http://www.cisco.com/c/en/us/td/docs/ios/voice/command/reference/vr_book/vr_a1.html#wp1612621" target="_blank">documentation on the command</a> is a bit confusing for me, so I might have it wrong, though empirical evidence and a few years of experience in SIP trunking tells me it's not a required command.</div><div><br></div><div>I'm always willing to learn more to be the best, so please comment if I'm wrong here.</div><div><br></div><div>Reference Material: <a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 5:12 PM, 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"><p dir="ltr">Hi Anthony, </p>
<p dir="ltr">For #2.. Its just there because the sp's integration guide had it in there- I'll try it tomorrow without and see if it fixes it, what you say makes sense. thanks! </p><div class="HOEnZb"><div class="h5">
<br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 8, 2016, 5:49 PM Anthony Holloway <<a href="mailto:avholloway%2Bcisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.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="ltr">I just wanted to comment on two things:<div><br></div><div>1) The port 4000 thing. CUCM does this to just give a port number, it doesn't actually use it. I wouldn't be looking to hard at that as a problem.<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b><i>4000 - 4005 / TCP</i></b></div><div><i>These ports are used as phantom Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) ports for audio, video and data channel when Cisco Unified Communications Manager does not have ports for these media.</i></div><div><i>Source: <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/10_0_1/CUCM_BK_T537717B_00_tcp-port-usage-guide-100.html" target="_blank">TCP and UDP Port Usage Guide for Cisco Unified Communications Manager, Release 10.0(1)</a></i></div></blockquote><div><br></div><div>With the way SDP works, if the offered port is 4000, and the media attribute a=sednonly is present, then the port is essentially ignored. Hence, a half duplex stream, and not full duplex.</div><div><br></div><div>2) Why are you using this command "pass-thru content sdp" As far as I am aware, that command will pass thru SDP from CUCM directly to the ITSP. Is that something you need? Typically, CUBE is your demarc between your enterprise network and the service provider, and as such, you don't pass through anything directly. If you don't know why that's there, then I would recommend removing it and re-testing your MOH scenario.</div><div><br></div><div>A similar command you might want to run is to suppress all of the chatter CUCM will send to CUBE that really has no business going out to the ITSP, but keeping the important messages, such as mid-call media changes.</div><div><br></div><div><font face="monospace, monospace">voice service voip</font></div><div><div><font face="monospace, monospace"> sip</font></div><div><font face="monospace, monospace"> midcall-signaling passthru media-change</font></div></div><div><font face="monospace, monospace">!</font></div><div><br></div><div>As far as your 4K router and the closeness of the AS1K defect, I really don't know.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 8, 2016 at 3:47 PM, Ed Leatherman <span dir="ltr"><<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><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'm working on getting a SIP trunk with an ITSP fully functional. I can get basic calls ok but Unicast MOH is not working out - no audio. Going off-hold i get the call audio back.<div><br></div><div>Quick packet cap on the CUBE confirms i'm getting MOH packets from CUCM but they don't make it across CUBE out to the SP.</div><div><br></div><div>For the re-INVITE to get the music audio, CUCM is sending SDP with:<br></div><div><div>m=audio 4000 RTP/AVP 0<br></div></div><div><br></div><div>From the packet cap, the audio packets are not being sourced from port 4000 - they are coming in from ephemeral ports. Could this be causing an issue with CUBE not translating the streams?<br></div><div><br></div><div>The reason I ask is that I noticed a bug out there <a href="https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCtb32219" style="outline:none;color:rgb(74,115,153);text-decoration:none;font-family:Arial,sans-serif;font-size:14.4px" target="_blank">CSCtb32219</a> for ASR1K which seems close, in my case this is a 4431 (Also ios-xe) running 15.5(1)S. Anyone run into that? The workaround is to enable duplex streaming in CUCM, which seems a little goofy.</div><div><br></div><div>I dont feel like I have anything special configured on CUBE:</div><div><div>voice service voip</div><div> ip address trusted list</div><div> ipv4 blahblahblah</div><div> address-hiding</div><div> allow-connections sip to sip</div><div> no supplementary-service sip refer</div><div> fax protocol pass-through g711ulaw</div><div> sip</div><div> pass-thru content sdp</div><div> sip-profiles 100</div><div>!</div></div><div><br></div><div>dialpeers all have </div><div>!</div><div><br></div><div><div> dtmf-relay rtp-nte</div><div> codec g711ulaw</div><div> no vad</div></div><div><br></div><div><br></div><div>Thanks!</div><span><font color="#888888"><div><br></div><div><br></div><div><div><br></div>-- <br><div>Ed Leatherman<br></div>
</div></font></span></div>
<br></blockquote></div></div><div class="gmail_extra"><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>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>