<p dir="ltr">That's what I was reading. I worked this out with TAC, Luis (a pretty sharp IE) is trying to raise a bug evaluation. </p>
<p dir="ltr">Thanks,</p>
<p dir="ltr">Ryan</p>
<br><br>-------- Original Message --------<br>From: Brian Meade <bmeade90@vt.edu><br>Sent: Friday, May 8, 2015 01:47 PM<br>To: Ryan Huff <ryanhuff@outlook.com><br>Subject: Re: [cisco-voip] Codec negotiation issue, a little strange<br>CC: cisco-voip@puck.nether.net<br><br><div dir="ltr">That feature is really only needed by some carrier/3rd party equipment. Some want to see a full inactive exchange before setting new media info which isn't technically required by any RFC that I know of. Some devices handle switching media without going inactive fine.<div><br></div><div>The 79XX series should be able to handle the new media without an inactive exchange first.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 12:58 PM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Brian,<br><br>Enabling "<span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Require SDP Inactive Exchange for Mid-Call Media Change" in the SIP profile of the CCM SIP trunk pointing at the CUSP server seems to have done the trick. No transcoding so far, and no call failures due to lack or transcoding resources.<br><br>This shouldn't be needed for supplementary service midcall INVITES on 79XX endpoints if I'm understanding that feature correctly, yes?<br><br>-ryan<br></span><div><hr>Date: Thu, 7 May 2015 20:21:18 -0400<span class=""><br>Subject: Re: [cisco-voip] Codec negotiation issue, a little strange<br></span><span class="">From: <a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a><br>To: <a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a><br>CC: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><br></span><div><div class="h5"><div dir="ltr">That may help but it's probably easier to just start with the "debug ccsip messages" to see what the router is sending in the outgoing Invite to CUSP.</div><div><br><div>On Thu, May 7, 2015 at 7:50 PM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Brian,</p>
<p dir="ltr">I'm guessing that the router in this case is somehow, messing with the codec.</p>
<p dir="ltr">Since the regions are g722/g711 that means g729 would be allowed in the region because it fits the bandwidth profile of the region.</p>
<p dir="ltr">Do you think doing a "pass-thru content unsupp" would be helpful in either eliminating or proving the router as the source of the issue?</p>
<p dir="ltr">As I understand it, this should allow sdp to pass to the other call leg without media negotiations.</p>
<p dir="ltr">Thanks,</p>
<p dir="ltr">Ryan</p><span>
<br><br>-------- Original Message --------<br>From: Brian Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>><br>Sent: Wednesday, May 6, 2015 05:54 PM<br>To: Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>><br>Subject: Re: [cisco-voip] Codec negotiation issue, a little strange<br></span><div><div>CC: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><br><div dir="ltr">CVP doesn't change SDP info and CUSP might not either, don't remember. Can you run "debug ccsip messages" on the H.323 GW to see if it's offering anything other than G.711ulaw in the Invite to CUSP? If it's only G.711 there, it must be getting changed by CUSP. I'm not familiar enough with it to know what to check though.</div><div><br><div>On Wed, May 6, 2015 at 5:40 PM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">I have a situation, where, in some case the ingress pstn call leg is trying to use g.729 (when there is nothing in the gateway that would indicate it's preference).<br><br>Call path when G729 is negotiated:<br><br>PSTN -> h.323(PRI)
dial-peer match -> SIP trunk to Unified Proxy Server - > SIP
Customer Voice Portal -> SIP To vXML Server -> Send SIP invite to
call manager and the SDP contains G729<br><br>Call path when G711 is negotiated:<br><br>PSTN - >h .323(PRI) dial-peer match -> CCM -> ring phone<br><br>- The gateway and IP phone are in the same region and the region is related to itself with G711.<br>- The region of the DP of the SIP trunk is related to the region of the gateway and the region of the phone with G711<br>- The voice class codec on the router only has g711 set as the 1st preference<br>- The matched dial-peer (h.323) for the SIP trunk to CUSP is specifying the voice class codec correctly<br>- The IP phone is a 7962/42<br><br>My question is how and why is the far end negotiating G729? This site does have limited CIR (10 Mbps) and the CVP/vXML servers are in a different geographic location than the gateway/IP phone.<br><br>My thought is that since the IP phone can negotiate G.729, it could be a bandwidth thing where it is just choosing to use the lower bandwidth codec BUT the invite to CCM is coming from CVP. The SDP in the invite shows G729.<br><br>Content-Type: application/sdp<br>App-Info: <<i>vXMLVoiceServerIPAddress</i>:8000:8443><br>v=0<br>o=CiscoSystemsSIP-GW-UserAgent 7410 5486 IN IP4 <i>GatewayIpAddress</i><br>s=SIP Call<br>c=IN IP4 <i>GatewayIpAddress</i><br>t=0 0<br>m=audio 19808 RTP/AVP 0 18 100 101<br>c=IN IP4 <i>GatewayIpAddress</i><br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:18 G729/8000<br>a=fmtp:18 annexb=yes<br>a=rtpmap:100 X-NSE/8000<br>a=fmtp:100 192-194<br>a=rtpmap:101 telephone-event/8000<br>a=fmtp:101 0-16<br><br><br> </div></div>
<br>_______________________________________________<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" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div> </div></div>
</blockquote></div><br></div>