Quantcast
Channel: Dialogic PowerMedia HMP GlobalCall and R4 API - Recent Threads
Viewing all articles
Browse latest Browse all 1151

RE: Not receiving GCEV_EXTENSIO events for incoming DTMF (HMP)

$
0
0

Hi there,

Getting GCEV_EXTENSION for RFC2833 digits is deprecated method. I'd recommend to use GCEV_TELEPHONY_EVENT instead, as it described in ch. 1.77 at www.dialogic.com/.../release_update.pdf

However, your description makes me thing that the digits are not provided in RFC2833 mode; the fact you get GCEV_CALLINFO may imply that the digitsd are provided as a payload of SIP INFO request (at least, the first one), and all the rest are sent in-band. Best way to find it out is to capture wireshark trace on HMP server and analyze RTP streams from the calling party.

Your app can also receive DTMF notification on a voice resource, even during a playback. The usual scenario is to use MAXDTMF=1 in DV_TPT (termination parameters table) in dx_play, and when dx_play stops due to DTMF, the app can use dx_getdig to capture all what the caller dialed, including the digit what terminated the playback.

If you don't want the playback to be stopped with DTMFs, you still can get DTMF notification via TDX_CST event. You have to enable this event on per-channel level like this:

dx_setevtmsk(m_hDevHandle, DM_DIGITS);

 Then, when DTMF is detected (in any call state and during any I/O operations on that channel), the app receives TDX_CST event which contains DTMF value:

case TDX_CST:

         {

DX_CST * cst  = (DX_CST *) sr_getevtdatap();
sprintf(m_devTxt,"TDX_CST, cst.event = 0x%x, data = 0x%x", cst->cst_event,
cst->cst_data);
// process digit

}
break;

where cst_event is set to DE_DIGITS (0x8) if the event caused by DTMF, and cst_data is ACII representation of the digit received (0x31 = "1", 0x32 = "2" etc).

Hope this helps.


Viewing all articles
Browse latest Browse all 1151

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>