<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>
<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">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>