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
