rtp-nte does not relay digits before connecting

[paolo bevilacqua]

I found a peculiar problem when using "dtmf-relay rtp-nte" (that is pretty much an universal standard) from a CME box to a PRI gateway, only when calling AT&T teleconferencing service.

No digit is recognized, I believe the digits duration is 160 mS. Any other IVR number have been working ok since one year. I try dtmf-interworking and doesn't help.

I switched to sip-notify that I believe has a default digit duration of 250 ms and things worked ok that way.

I can't find a way to change digit duration with rtp-nte - there is ?

[Payal Bhaduri]

Hi Paolo,

In CME, under ephone and ephone-template configuration, there is a

command to lengthen the dtmf duration from the default  to 200ms

(max). The CLI command is nte-end-digit-delay.

.

Note that the max is 200ms.

You will also need the

CME-CUE-28#conf t

CME-CUE-28(config)# voice service voip

CME-CUE-28(config-voi-serv)# dtmf-interworking rtp-nte

then

CME-CUE-28(config-ephone)#nte-end-digit-delay 200

You need to configure both voice service dtmf-interworking rtp-nte and the

nte command on the ephone/ephone-template in question to produce the

necessary delay on the end packet.

Please note this command was introduced in 12.4(15) and rolled into 12.4(20).

[paolo bevilacqua]

Payal, thank you for your answer.

I tried the aboive configuration and AT&T conferencing (1-866-633-8631) still does not recognize the digits.

I tried dtmf-interworking under both voice service coip and dial peer, and nte-end-digit-delay under both ephone and ephone-template.

I use 15.0(1)M5 on both CME and PRI VG.

Is there any debug I can take for this, beside a packet capture ?

[Payal Bhaduri]

Hi Paolo,

Can you also try the following commnad:

CME-CUE-28(config-ephone)#keypad-normalize

keypad-normalize

Ensures that the delay configured for a dtmf-end event is always honored.

I am not aware of a debug but a packet capture can help to troubleshoot this.

[paolo bevilacqua]

Thanks, also tried keypad-normalize to no effect.

Either 200ms digit duration is still too short for this service, or nte digit configuration has no effect.

With sip-notify, it works.

I will try to take a capture later.

I've rated both your posts above.

[paolo bevilacqua]

[EDITED - Explanation at the bottom]

I did quite a bit of testing and got not very comforting results.

I captured the generated DTMF digit by calling into an IPCP with wireshark.

First of all, when setting nte-end-digit-delay higher than 190, the terminating VG generates three digits of the wanted duration, separated by 50 ms, instead of a single one. Beside that, the duration seems to be set accurately.

Second, when configuring nte-end-digit-delay the CME router start logging many messages like

%SKINNYMAIN-4-KEYPADFAST: Keypad messages from the phone 10 are too fast

That can be quite a problem and is a bug in my opinion.

Third and strangest, that with a value of 190 ms, AT&T Conferencing still does not recognize digits.

So I made some further test with sip-notify. I verified that the default digit duration is 200 ms as per documentation, and as mentioned before, that makes AT&T work.

Then I wanted to know what would happen by shortening it, but found that sip-ua configuration "notify telephone-event max-duration" has no effect.

Finally, it dawned on me what is happening. This particular conferening system does not actually connect the call until the correct ID digits are entered. Problem is, rtp-nte does not relay digits if the call is not in connected state, that is reasonable as no forward media stream has been built yet. Instead sip-notify begin a completely OOB mechanism, does not care. So the first fails and the digit duration track was wrong..