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
