[cisco-voip] Codec negotiation issue, a little strange

[Ryan Huff]

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 <bmeade90 at vt.edu>
Sent: Friday, May 8, 2015 01:47 PM
To: Ryan Huff <ryanhuff at outlook.com>
Subject: Re: [cisco-voip] Codec negotiation issue, a little strange
CC: cisco-voip at puck.nether.net

>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 <ryanhuff at outlook.com> 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: bmeade90 at vt.edu
>> To: ryanhuff at outlook.com
>> CC: cisco-voip at puck.nether.net
>>
>> 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 <ryanhuff at outlook.com> 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 <bmeade90 at vt.edu>
>> Sent: Wednesday, May 6, 2015 05:54 PM
>> To: Ryan Huff <ryanhuff at outlook.com>
>> Subject: Re: [cisco-voip] Codec negotiation issue, a little strange
>> CC: cisco-voip at puck.nether.net
>>
>> 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 <ryanhuff at outlook.com> 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
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150508/11899f66/attachment.html>