12.4.7d/g

12.4.15T8

12.4.20T2

all have proven to be good ones to us. We test IOS codes in detail as this can burn you very quickly.

HTH,

Chris

A few things I'll throw out there:

12.4(15)T8 - this has a nasty MGCP T38 bug in it.

12.4(15)T7 - this has a duplicate DTMF bug that's pretty bad, as well as a fax-detection issue (not too common).

We're pretty hopeful about 12.4(15)T9 which will be coming out within the month.

If you're using MGCP, 12.4(3j) has a nasty one where it will not recover from a reload and your ISDN Q.921 will not come up, as well as a few DSP crash issues.

12.4(20)T and later seem to be fairly good, which would be either 12.4(20)T2 or 12.4(22)T1. They're still relatively new, however.

If you're using SIP, I would be on 12.4(20)T or later because of the amount of corner cases and core stack updates that have been done with SIP.

12.4(7) and 12.4(10) trains also have some mixed issues with MGCP, such as the bind command becoming inactive while configured, but are fairly stable.

(gateway IOS in a nutshell)

hth,

nick

Nick,

+5 for excellent summary.

Any recommandation for CVP 7 IOS? You may recall me having issue with dtmf when using 3 dtmf-types, it was fixed with chnaging the preference to use h245-alpha, however that does not work with sip on another deployment, so my only option is rtp-nte, which again causes some digit mis-interpretation. I am usong 12.4.15T8.

Chris

Hi Chris,

I don't work directly with CVP on a regular basis, but I do understand they require sticking strictly to the BOM and the last I checked I thought 12.4(15)T was the only approved train.

We have not had much in terms of RFC 2833 bugs on the gateway (some with CUBE), so it's possible that it's configuration or something else going on there. (You may want to try the 'voice service voip' command 'dtmf-interworking'). You may also want to make rtp-nte the last choice, which can affect some preferences.

hth,

nick

12.4.20T is now supported and listed in BOM.

I don't see the dtmf-interworking command as option, is this a hidden one or something?

What I had found with H323 is that when I had 3 dtmf types listed it would cause the issues, if I chnaged it to only list one it no longer misbehaved.

But now I am seeing the same issue with SIP even when only 1 type is listed (only tried nte-rtp) as the other ones are not working with SIP.

The issue is that I allow callers to enter 4 digits extensions at any time, and at times as soon as the first digit is collected to matches the menu option and routes the call immediately instead of waiting for additional digits.

Chris

Hi Chris,

Sorry, forgot to mention that dtmf-interworking was something added into 12.4(20)T. That works out well now that it's in the BOM.

It kind of sounds like a IVR issue, but it's hard to say.

-nick

Many thanks for all your suggestions