DTMF interworking KPML <-> INFO/NOTIFY

[Paul Freiberg]

Hi all,

IPPHONE <-SIP-> UCM <-SIP-> CUBE <-SIP-> ITSP

I try to enable interworking of KPML and INFO DTMF Methods.

Our ITSP sends INFOs to us and the CUBE sends fine KPML NOTIFYs to UCM.But if I send KPML NOTiFYs to the CUBE, it does not generate INFOs, NOTiFYs or KPML SUBSCRIBE/NOTIFYs (dtmf-relay sip-info, dtmf-relay sip-kpml, dtmf-relay sip-notify).

I am not allowed to look into that bug:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCse50733

I need it for Conference Now, here RFC2833 do not work for me.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw79671/?referring_site=bugquickviewclick

Did not helped me.

Do you have an idea?

Paul

[Paul Freiberg]

I asked my provider to set its trunk to "rfc2833 OR OOB".

Then I changed back my Dial-Peers to "dtmf-relay rtp-nte" and created two Dial-Peers for Conference Now Directory Number with incoming Dial-Peer set to "dtmf-relay sip-info" and outgoing Dial-Peer set to "dtmf-relay sip-kpml".

It works fine for me. :)

But CUBE does not detect the incoming dtmf-method:

Negotiated Dtmf-relay    : inband-voice

[Paul Freiberg]

Hi,

I have to revoke my statement, that it works completely.

It works partially.

Some participants are sending an high duration in the DTMF-INFO messages followed by Messages with Signal-Updates and more Duration (duration=2600 + signal-update duration), which states how long the keys are pressed. Our provider told me that he cannot/do not want to influence it, he just forwards that messages. 

As I captured the SIP messages I noticed that this DTMF-INFO Messages arrived shortly one by one within 2 seconds, but the CUBE forwards DTMF-KPML Messages exactly after that durations. So a four-digit PIN is transmitted within more than 8 seconds which always ended in an time out and the IVR output message: "invalid meeting ID".

I asked for a way to modify that durations on CUBE in a SIP-Profile:

https://supportforums.cisco.com/t5/ip-telephony/modify-non-standard-sip-header/m-p/3035753#M342971

But the "Duration" Header is not a SIP-Header it is payload and actually it cannot be modified.

Because of that behavior we do not use Conference Now anymore.

Our "workaround" is the Cisco Meeting Server which provides a dial-able IVR.

Paul

[kevin.vines]

Hi Paul,

with respect to the invalid meeting ID after 8 seconds, that timer value is apparently determined by the T302 timer (inter-digit) value in the Service Parameters for the Cisco CallManager service. The default value is 15 seconds but you may have reduced it as we have. Try ensuring it is at least 10 seconds.

[Paul Freiberg]

Hi @kevin.vines,

thanks for that tip. But we reduced that timer to 5 seconds. And because of CMS we do not need Conference Now anymore.