Re: CUCM / CUBE / Unity Cxn - fun with G729 variants

TONY SMITH · ‎11-20-2019

Hi,

There are a couple of sites that I'm trying to get working without MTP, and I'm having some problems getting consistent results where the calls need to use G729. Two things seem to be irreconcilable ..

(1) Outbound call via CUBE, of CUCM presents the call without Annex B, CUBE nevertheless presents it to the ITSP as Annex B, and the call fails. Both dial peers have the same codec list, including both g729r8 and g729br8

Any idea why that would be? As it is this means that an outbound call has to use Annex B or the call fails.

(2) Unity Connection appears not to support Annex B and again there seems no way to enable it. So if a call transfers to Unity over a low bandwidth link the call fails.

Any comments on either of these? The only way that appears to reconcile these issues is to use MTP on the CUCM to CUBE trunk.

Thanks, Tony S

TONY SMITH · ‎11-22-2019

Any thoughts? Particularly on the CUBE and dial peer issue, why would the CUBE receive an inbound call specifying G729 without Annex B, but insist on offering it outbound with Annex B specified.

Codec selection as applied to both dial peers ...

voice class codec 20
 codec preference 1 g711ulaw
 codec preference 2 g711alaw
 codec preference 3 g729r8
 codec preference 4 g729br8

Inbound SDP from CUCM ..

m=audio 26330 RTP/AVP 18 101
a=ptime:20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Outbound to ITSP ..

m=audio 32264 RTP/AVP 18 97 19
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Is there some default parameter somewhere in CUBE configuration that forces Annex B unless explicitly disabled either globally or at dial peer level?

Thanks, Tony S

Anthony Holloway · ‎11-22-2019

"Cisco implements support for multiple G.729 codec versions by using a=fmtp and a=rtpmap attributes in the SDP body of outgoing INVITE requests. For the G.729 codec, the value of a=fmtp is 18 (the IANA assigned static value), and the annexb value is either yes or no. The default for annexb is yes."

Source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-qos.html

"If both g729r8 and g729br8 are configured in the codec preference list, then the only way to advertise the full capability in the invite is to use the annexb= yes parameter in fmtp line. Since both codecs use 18 as payload value, there is no other way to differentiate if both codecs are on the preference list."

Source: https://community.cisco.com/t5/collaboration-voice-and-video/in-the-g-729a-codec-preference-configuration-on-a-cisco-ios/ta-p/3113713

TONY SMITH · ‎11-23-2019

At first sight he behaviour of the two gateways in question appear not to match that document. My Invite matches the second to last line. Both codecs configured, and SDP incldes "annexb=no", so according to the table it should negotiat G729r8, not G729br8. However the table also contradicts itself as in that line it also says "annexb= yes or no fmtp line" should result in G729r8, but next line says "no fmtp line" means it'll negotiate B.

Configured Codec(s)Remote End Supports Annex BNegotiated Codec

G729r8	annexb= no or no fmtp line	G729r8
G729br8	annexb = yes or no fmtp line	G729br8
G729r8 and G729br8	annexb= yes or no fmtp line	G729br8
G729r8 and G729br8	no fmtp line	G729br8
G729r8 and G729br8	annexb=no or no fmtp line	G729r8
G729r8 and G729br8	annexb=yes	G729br8

Anthony Holloway · ‎11-24-2019

If you have both in your pref list, which you do, you will only see annex b offered, since it's "masking" the non-annex b offering. Since your are not using codec transparent on your CUBE, but instead forcing a set of codecs, it's entirely possible for CUBE to send out annex B after have receiving non-annex B from CUCM.

"so according to the table it should negotiat G729r8, not G729br8." <--- Therefore, this statement is false.

You have to recall that CUBE will terminate one leg, and generate a new leg, to include setting up different media capabilities, IP Addresses, port numbers and SIP Headers.

TONY SMITH · ‎11-25-2019

Thanks for all your comments. I had a chance to do a little bit more testing and have a possibly working configuration. It all seems to hinge around circumventing or adapting to CUBE's love of Annex B. All of the following was carried out with Annex B disabled in CUCM.

First I tried removing G729B from the codec class. In this case the Invite was received as expected with "a=fmtp:18 annexb=no", and the Invite to ITSP went out similarly. First received SDP was 180 ringing with Annex B unspecified

m=audio 24964 RTP/AVP 18 97
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=ptime:20
a=rtpmap:18 G729/8000/1

Followed by CUBE dropping the call "Reason: Q.850;cause=65".

Next I tried with "codec transparent" on both dial peers. As before the Invite was sent with "a=fmtp:18 annexb=no", and 180 Ringing received with Annex B unspecified. However now the CUBE passes that back to CUCM as 183 Session Progress, but now it's added Annex B.

m=audio 17482 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

Again passed through to CUCM with Annex B and the call connects apparently correctly, but as G729B.

Incoming call is almost a mirror image, incoming Invite from ITSP has Annex B unspecified, Invite from CUBE to CUCM adds "annexb=yes". SDP back from CUCM has "annexb=no", and the call connects as G729.

I need to revert the configuration just now while I review whether I need to do any further testing to accept this change, but it's looking hopeful. I found some other documentation to review as well, as I am still not clear why the CUBE insisting on adding Annex B is considered normal behaviour.

Alternatively if I could persuade Unity Connection to accept Annex B then I could leave CUCM and CUBE in their default B loving configurations. Or if there was some way to invoke MTP or Transcoder solely for G729 calls that would do the trick as well. Specifying MTP required on the CUCM trunk makes everything work, but the second of these two sites is a bit short on DSPs so I'm not completely happy with everything hitting the MTP.

Anthony Holloway · ‎11-25-2019

"CUBE's love of Annex B"

It's really not a CUBE love thing though. If you just think about how G729 and G729b use the same RTP Payload Type of 18, then you'll realize that the only other way to signify the nuance of VAD in annex B is to use the ftmp SDP header to set annex B = yes. However, this tramples on non-annex B. There isn't a way to independently offer both. And setting annex B to no in this instance would ignore your command in CUBE to offer annex B.

"First received SDP was 180 ringing with Annex B unspecified"

Which is the same as annex b = yes, therefore, your carrier must be also supporting/advertising annex B capabilities. In fact, they might even have a paper stating that all g729 must be annex B.

"CUBE passes that back to CUCM as 183 Session Progress, but now it's added Annex B"

Yeah, that makes sense. CUBE isn't necessarily "changing" anything here. It's just taking the implicit rule and making it explicit.

"apparently correctly, but as G729B"

Did you verify the codec in use, and whether a media resource was inserted?

"CUBE insisting on adding Annex B is considered normal behaviour"

Again, it's not. the ITSP omitting annex B is the one adding the "yes" in there, CUBE is just taking it from implicit to explicit.

2.1.9. Registration of Media Type audio/G729

Type name: audio
Subtype name: G729
Required parameters: none
Optional parameters:
- ptime, maxptime: see RFC 4566
- annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.

Source: RFC 4856 - Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences

Also, I agree with you, in that I wouldn't engineer towards an MTP based solution either, but sometimes you have to.

Lastly, if your carrier is always going to prefer annex B, but you don't want it, you might be able to use one or both of a SIP Profile on CUBE or a Lua Script on CUCM to force it to "no".

TONY SMITH · ‎11-25-2019

Thanks again.

"Did you verify the codec in use, and whether a media resource was inserted?"

I verified with "sh call act voice comp" to confirm codec and end points. Based that the end point for the outgoing call was the phone handset, codecs for both legs shown as "g729br8". Incoming call going to voicemail, the end point was the VM server, and both legs "g729r8".

So this configuration uses different codecs depending on the call direction, and which end sends the final SDP. If it's CUBE then the call uses Annex B, if it's CUCM it doesn't. (Edit - that's with Annex B disabled in CUCM of course)

There's another G729 scenario that I haven't tested, inbound call picked up by remote handset, I need to check that during the next test window.

Anthony Holloway · ‎11-22-2019

Annex B is silence suppression right, and don't we always hear "VAD is BAD"? I typically turn off silence suppression in CUCM (it's on by default), and I do not use it in CUBE. Do you need silence suppression?

TONY SMITH · ‎11-23-2019

"Annex B is silence suppression right, and don't we always hear "VAD is BAD"? I typically turn off silence suppression in CUCM (it's on by default), and I do not use it in CUBE. Do you need silence suppression?"

At the moment I could take it or leave it. For preference I wouldn't have it, and in fact it appears Unity Cxn doesn't support Annex-B. There's inconsistency across the products, CUCM defaults to always using it, but can be disabled globally. CUBE appears to really like Annex-B, in fact to insist on it so that even when a call is offered without, it passes it on with Annex-B and thus makes sure the call fails.