hmp3.0 su202 missing dtmf when using RFC2833


Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic Global Call and R4 APIs

hmp3.0 su202 missing dtmf when using RFC2833

  • Hi,

    I am working with a customer who reported they are missing digits when they typed 9011890417, they only got 901890417, where a 1 was missing. I did some research on the wireshark they collected, and found the 1s are received with 0.2 sec. see below.

    our application only received one event for the "1". So I am sure it is hmp not reporting it. Not sure what is the next step to chase it.

    Any suggestion?



    17575    2009-11-23 03:28:37.315822         RTP EVENT          Payload type=RTP Event, DTMF Zero 0

    18050    2009-11-23 03:28:39.215840         RTP EVENT          Payload type=RTP Event, DTMF One 1

    18104    2009-11-23 03:28:39.415836         RTP EVENT          Payload type=RTP Event, DTMF One 1

    18211    2009-11-23 03:28:39.875863         RTP EVENT          Payload type=RTP Event, DTMF Eight 8



  • For like digits, in this case 11, it is necessary to have an interdigit delay of 50ms in order to recognize both digits as separate DTMFs.

    The detection is actually done via audio, as opposed to using the RTP events.  The ipm device recreates the tone onto the bus for the voice resource to detect the DTMF.

    The two most common ways that 2 DTMFs can be reported just once:
    1) The inter-digit delay is too short (time from the DTMF END packet to start of new DTMF).  Again, this needs to be at least 50ms.
    2) There is some portion of the DTMF audio still inband.  This should be eliminated by the sending device, but sometimes a little bit of DTMF audio appears.  Analysis of the RTP stream in Wireshark will show whether any of the DTMF is still there.  If it's there, it may be received by the voice resource during the time when the inter-digit delay should be, thus preventing it from separating the two tones.

    In either of these cases, the solution usually lies outside the HMP machine.


  • Thanks Joe,

    I revisited the wireshark again, and found the time between the last packet of the first 1 and the first packet of the second 1 is very short (120ms), but is still longer than the (50ms). Well, I have to agree, this is the wireshark captured timestamp, when hmp received it and processed it, could have some variation.

      18060 2009-11-23 03:28:39.235794            RTP EVENT Payload type=RTP Event, DTMF One 1 (end)
      18061 2009-11-23 03:28:39.235798            RTP EVENT Payload type=RTP Event, DTMF One 1 (end)
      18086 2009-11-23 03:28:39.355812            RTP EVENT Payload type=RTP Event, DTMF One 1
      18087 2009-11-23 03:28:39.355817            RTP EVENT Payload type=RTP Event, DTMF One 1
      18092 2009-11-23 03:28:39.375874            RTP EVENT Payload type=RTP Event, DTMF One 1

    I think your second point might be the root cause, I did see audio between the two dtmf packet, which could well be the inband dtmf. unfortunatly, the wireshark raw data is hard to identify what audio are they, but does not looks like  silence to me. (the wireshark player might encoded the raw data, so can't tell me much)

    I will see if they can modify their device so only RFC2833 events are sent.

    Thanks a lot,



  • Joe,

    the 50ms setting, is it configurable?

    I asked them to do a test, so we only detect inband dtmf and ignore the 2833 event. Now they said they got extra digit, a 0 being recognized as 00. I wonder if we can increase the 50ms to 80ms or 100ms, and see if still have that extra digit.


  • Hello,

    I am having the same problem. The wireshark log shows all the digits typed by the user, but the app gets 1 or 2 digits less that it should.

    The HMP (SU 267) system is getting the digits either from an Asterisk box or from SJ softphones, but the result is the same: there are always missing digits.

    Appreciate a hint

    Thanks and best regards




  • Same problem Here,

    digits get lost all the time,  when you dial fast.

    As a clue, it appears to us than on slower machines,  it doesn't fail,  or fails less,   while on faster or newer machines,  it tends to fail a lot more.

    We have one PIII with Win2003Server,   all digits are collected fine,  despite of the speed of dialing.

    on a PIV 2.4 GHz,   all digits are collected fine.

    on a Core2Duo,  some digits are missing

    on a Core2Quad,   many digits are missing.

    don't know if whether it is related to speed of processor or some new feature they might have.