<div dir="ltr">Anthony,<div><br></div><div>Removing the sdp passthru did the trick; now I need to take some debugs and compare so maybe i can understand what was passing thru causing the problem. I'll try that other command you suggested too. I have an exact duplicate of this trunk to turn up in a few weeks so I'm happy to learn this stuff now.</div><div><br></div><div>Erick - I didn't try the duplex media streaming - wanted to see if there was something I could do locally on CUBE instead of making a cluster-wide change like that... but I was close to trying it.</div><div><br></div><div>Thanks!!</div><div><br></div><div>Ed</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 5:49 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.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">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 class="h5">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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></div></div>_______________________________________________<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><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ed Leatherman<br></div>
</div>