That's what I was reading. I worked this out with TAC, Luis (a pretty sharp IE) is trying to raise a bug evaluation.
Thanks, Ryan -------- Original Message -------- From: Brian Meade <[email protected]> Sent: Friday, May 8, 2015 01:47 PM To: Ryan Huff <[email protected]> Subject: Re: [cisco-voip] Codec negotiation issue, a little strange CC: [email protected] >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. > >The 79XX series should be able to handle the new media without an inactive >exchange first. > >On Fri, May 8, 2015 at 12:58 PM, Ryan Huff <[email protected]> wrote: > >> Brian, >> >> Enabling "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. >> >> This shouldn't be needed for supplementary service midcall INVITES on 79XX >> endpoints if I'm understanding that feature correctly, yes? >> >> -ryan >> ------------------------------ >> Date: Thu, 7 May 2015 20:21:18 -0400 >> Subject: Re: [cisco-voip] Codec negotiation issue, a little strange >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> >> 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. >> >> On Thu, May 7, 2015 at 7:50 PM, Ryan Huff <[email protected]> wrote: >> >> Brian, >> >> I'm guessing that the router in this case is somehow, messing with the >> codec. >> >> Since the regions are g722/g711 that means g729 would be allowed in the >> region because it fits the bandwidth profile of the region. >> >> 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? >> >> As I understand it, this should allow sdp to pass to the other call leg >> without media negotiations. >> >> Thanks, >> >> Ryan >> >> >> -------- Original Message -------- >> From: Brian Meade <[email protected]> >> Sent: Wednesday, May 6, 2015 05:54 PM >> To: Ryan Huff <[email protected]> >> Subject: Re: [cisco-voip] Codec negotiation issue, a little strange >> CC: [email protected] >> >> 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. >> >> On Wed, May 6, 2015 at 5:40 PM, Ryan Huff <[email protected]> wrote: >> >> 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). >> >> Call path when G729 is negotiated: >> >> 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 >> >> Call path when G711 is negotiated: >> >> PSTN - >h .323(PRI) dial-peer match -> CCM -> ring phone >> >> - The gateway and IP phone are in the same region and the region is >> related to itself with G711. >> - 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 >> - The voice class codec on the router only has g711 set as the 1st >> preference >> - The matched dial-peer (h.323) for the SIP trunk to CUSP is specifying >> the voice class codec correctly >> - The IP phone is a 7962/42 >> >> 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. >> >> 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. >> >> Content-Type: application/sdp >> App-Info: <*vXMLVoiceServerIPAddress*:8000:8443> >> v=0 >> o=CiscoSystemsSIP-GW-UserAgent 7410 5486 IN IP4 *GatewayIpAddress* >> s=SIP Call >> c=IN IP4 *GatewayIpAddress* >> t=0 0 >> m=audio 19808 RTP/AVP 0 18 100 101 >> c=IN IP4 *GatewayIpAddress* >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:18 G729/8000 >> a=fmtp:18 annexb=yes >> a=rtpmap:100 X-NSE/8000 >> a=fmtp:100 192-194 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-16 >> >> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >> >>
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
