H323 won't pass DTMF but SIP will

[Teslanut2011]

I have a C40 (but is happening to C20's and C60's as well). When I set the default call to SIP, I can pass DTMF (Dialing into Meeting Place, Lync Conferencing etc). But if my default call is set to H323, DTMF will not pass. Any ideas?

[Paulo Souza]

Hi Chrys, welcome to Cisco Support Community!

Your problem may be related to the DTMF method. There are two methods to send DTMF sequence, out-of-band (dial tones are not sent through media/RTP) and in-band (dial tones are sent through media/RTP). C40 and another TC endpoints use H245 alphanumeric DTMF method in H323 calls, which is an out-of-band method. In SIP calls, they use RFC 4733, which is an in-band DTMF method.

So I think your problem may be related to DTMF method applied, because (If I am not wrong) MS Lync and Cisco Meeting Place use an in-band DTMF method and for H323 calls your C40 will use an out-of-band method (H245 alphanumeric), so that the method won't match.

I have something in mind to suggest you, but first, provide additional information about your environment, including the servers you are using, protocols, how the insfrastructure components are integrated, versions and so on.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Alok Jaiswal]

Hi Chrys,

As Paulo mentioned this could be a dtmf mismatch issue.

Lync and meeting place uses sip trunk so for better interop the call leg should be end to end sip only.

Also if you can invoke  a transcoder in this you might get a workaround for the problem.

Rgds

Alok

[Martin Koch]

As the others already said, DTMF looks quite simple but as there are different methods how

to transmtit it it can become trickey.

Please always mention how your deployment looks like, incl, the software versions used and

infos about the call flow.

As also said, when sip works, why not use it? ;-)

Please remember to rate helpful responses and identify helpful or correct answers.

[Chad Patterson]

Hey Chrys,

As the others have stated, deployment information may be useful for troubleshooting this issue. However, from your description it sounds like you could be hitting a bug on the vcs where interworked calls from H323 to SIP do not pass DTMF. This is an issue where the VCS does not correctly handle interworking the H.245 signal to 2833 events. See bug CSCug34686

[Teslanut2011]

Hey guys, thanks for the feedback. I have VCS running x7.2.2

I am running several C series codecs all up to latest code release. I have a sip trunk built to my CUCM (8.6.2) & it can dial fine, but once the call is set up, the demo will not pass if the call is h323. If I change the default cll protocol to SIP, the call works fine, but then I can no longer call my end points that are (older mxp series) via e164 or URI. It breaks something somewhere.

Where would I augment the settings for in-band vs out of band?

Again, thanks for all the replies thus far, it is appreciated.

Chrys

[Chad Patterson]

Hey Chrys,

Did you check on your VCS to see if when DTMF is not being passed if the VCS is interworking the call from H323 to SIP? You are running a version of VCS that is susceptible to not passing DTMF correctly for interworked calls from H323 to SIP which would then make sense that when you set your call preference to SIP and the call is not interworked the calls work. (the bug for this is in my comment above)

If you switch your default call protocol to SIP you should still be able to connect to your older endpoints by dialing their e164 or h323id. You just need to make sure you have a search rule on your VCS that will strip off the domain and search the VCS for that endpoint using only the e164 number or h323id.

[Paulo Souza]

Hi Chad,

Now I am very curious about this bug, because the bug Toolkit says it is "fixed", then, if Chrys is running the latest VCS version (X7.2.2), I think he should not have this bug going on, correct?

Is the bug really fixed? In which version?

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Alok Jaiswal]

Hi Paulo,

seems this bug is not fixed yet and supposed to be fixed in x8 release version.

Rgds

Alok

[Paulo Souza]

Hi Chrys,

Just in case, can you check your SIP Trunk configuration in your CUCM? Make sure that the DTMF protocol is set to "RCF 2833", which is the same used by VCS in SIP calls. Also make sure that you have applied the SIP normalization script "vcs-interop".

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Paulo Souza]

In addition, if you want to know if your DTMF problem is really related to VCS's bug or to some configuration issue in the CallManager's side, you can do the following:

Make a SIP to H323 call involving only endpoints registered to VCS. Test sending DTMF to see if it works, if it works, so you can come to conclusion that your problem is not related to a bug in VCS. Maybe it is something in the configuration between your CUCM and Meeting Place, or CUCM and VCS. You can improve the DTMF interoperability in CUCM my enabling MTP in the trunk towards Meeting Place, then CUCM will be able to convert out-of-band DTMF methods if necessary. You can test it to see what you get.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".