voice payload size setting on Cisco 2901 doesn't work

[secanlab1]

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.

[Tristan Cober · Accepted solution]

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)

Preferred G.729 Millisecond Packet Size:	This parameter specifies the preferred size for delivering G.729 packets. To avoid adding latency, the value values specify 10, 20, 30, 40, 50, or 60 milliseconds.
	This is a required field.
	Default: 20
Always Use Preferred G.729 Packet Size For SIP Trunk Answers:	This parameter determines whether the value specified in the Preferred G.729 Millisecond Packet Size service parameter is always used in outgoing answers containing G.729 (including any of the four variants: G.729, G.729a, G.729b, or G.729ab) that are sent to SIP Trunks. Valid values specify True or False, with False being the default value. When set to True, the preferred G.729 packet size is used as the G.729 ptime (packetization time) in the outgoing answer to the SIP trunk, regardless of what G.729 ptime is specified in the incoming offer from the trunk, only when Cisco Unified Communications Manager (Unified CM) selects G.729 out of the codecs in the offer. This answer to the SIP trunk tells the device behind the trunk to send a G.729 stream with that packet size to the other party in the call. The other party in the call will also be signaled to stream G.729 with that packet size to the device behind the SIP trunk. However, if the other party uses SCCP, H.323, or MGCP, and the preferred packet size exceeds what is advertised by the other party, then the other party's advertised packet size will be used instead for both the outgoing answer to the SIP trunk and the signals to the other party. This service parameter only applies to calls in which media resources (including media termination points and transcoders) are not allocated. When set to False, the preferred G.729 packet size is only used when it does not exceed the packet sizes advertised by the SIP trunk and the other party in the call. This is the procedure that is normally used for all audio codecs.
	This is a required field.
	Default: False

[secanlab1]

(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. 

[Tristan Cober]

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?

[secanlab1]

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.)

[Guillem Alsina Navarro]

Is the call matching the correct dial-peers (inbound and outbound)?

What you see on SDP of CUCM - CUBE leg?

[jdeysel]

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

[secanlab1]

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.