06-11-2016 04:37 AM - edited 03-17-2019 07:12 AM
I'm trying to set the size of G.729 packets to something other than the 20 ms default. According to this, it should be easy:
http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html
Cisco-Router(config-dial-peer)#codec g729r8 bytes ? Each codec sample produces 10 bytes of voice payload. Valid sizes are: 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230 Any other value within the range will be rounded down to nearest valid size. <10-230> Choose a voice payload size from the list above
But packet captures show that this isn't working. Here's my dial peer config:
dial-peer voice 110 voip
description CUBE-SOUTH
destination-pattern 602....
session protocol sipv2
session target ipv4:10.6.253.1
session transport tcp
voice-class sip early-offer forced
srtp
codec g729r8 bytes 80
no vad
Other than that, the call works fine.
Solved! Go to Solution.
06-11-2016 10:04 PM
What do the SDPs look like in the SIP messaging? Are you pointing this at a Call Manager? There are some settings for this in Call Manager (below). You might be invoking a transcoder/MTP on that CUBE if you have one.
Clusterwide Parameters (System - Location and Region)
06-11-2016 10:04 PM
What do the SDPs look like in the SIP messaging? Are you pointing this at a Call Manager? There are some settings for this in Call Manager (below). You might be invoking a transcoder/MTP on that CUBE if you have one.
Clusterwide Parameters (System - Location and Region)
06-13-2016 12:53 PM
(Clicked Correct Answer by accident and now I can't undo it)
I tried setting those CUCM parameters, but the call is still using the default 20 ms payload.
The CUBE is transcoding properly from G711 to G729 but the payload size settings for G729 don't have an effect.
06-13-2016 01:03 PM
Are you doing an embedded capture on the CUBE? If a transcoder/MTP was invoked, you would see the 20 ms payload towards the CUBE, which is then transcoded to 80 ms on the CUBE in your case.
I could be wrong, so more research is required I would think.
Edit: read your comment a bit further. So the phones are in a G711 region, and the SIP Trunk is in a G729 region. In that case if a hardware transcoder is invoked I would expect G711 being done towards the CUBE where it is then transcoded to G729 w/ ptime 80ms. What the other side of the call?
06-13-2016 01:04 PM
No, the capture is via span ports.
CUCM --- CUBE-left --- CUBE-right --- CUCM
CUBE-right is transcoding between G729 on the left to G711 on the right. That part works, but only for default 20 ms payloads.
The left CUCM parameters you mentioned are set for higher packet sizes.
CUBE-right sends up ptime 80 in SDP, but CUBE-left responds with ptime 20. But setting the codec on CUBE-left breaks the call (that CUBE does not have DSP modules).
(I have also tried this with 60 ms payloads because some documentation seems to say that 60 ms is max.)
08-04-2016 07:52 AM
Is the call matching the correct dial-peers (inbound and outbound)?
What you see on SDP of CUCM - CUBE leg?
08-03-2016 09:56 PM
Hi,
Did you resolved this problem? I have the same problem but only on 7811 phones.
THe service provider sends 60ms and I want to step it down to 20ms. Also configure dial-peer with voice class but it is not working.
Thanks
08-04-2016 06:03 AM
Yes, but I am not sure what fixed it.
The codec command has an option "fixed-bytes" option that means "codec bytes fixed (no negotiation)"
Try that? The early-offer settings seem to make a difference sometimes. Try turning that on or off.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide