[Home]

Summary:ASTERISK-07554: [bounty] RTP RFC2833 DTMF Events Out of Sequence = Duplicate Digits
Reporter:Max Glucksmann (mglucksmann)Labels:
Date Opened:2006-08-19 00:25:28Date Closed:2006-08-19 14:03:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Event_Between_End_Events_Causes_Duplicate_Digit.cap
Description:Description:

When a DTMF RTP Event is received "after" an End Event for the same Digit, meaning that it has a previous sequence number and duration but it is received after the End Event, Asterisk reproduces 2 digits instead of the original single digit sent.

In our case, we are receiving only one isolated Digit Event between the End Ones, which are always 3.

We are offering a bounty of $200 in order to make a patch that does either one of the following proposed solutions, which we'd like the volunteers to analyze:

1) Discard the first isolated End Event by seeing that an Event with previous duration and sequence number is received afterwards.

2) Discard the isolated Digit Event that results between two End Events, by recognizing that it has a previous duration and sequence number than the the End Event received before it.

3) Don't discard Events, but make an array and arrange them by sequence number and duration. In this case, timing must be considered when the same digit is actually pressed twice. We'd suggest that a re-arranging array would allow only events within a configurable period of time.


****** ADDITIONAL INFORMATION ******

A detailed capture is provided where the error is clearly shown.

We appreciate opportune response as this issue started affecting our calling cards' service since 3 days ago when our SIP DID Provider started sending digit events in an altered order, after we had offered a reliable service for more than 3 continuous months.

Thank you in advance.

With best regards,
Max
Comments:By: Jason Parker (jparker) 2006-08-19 00:44:22

Please test the vldtmf branch in bug:5970, with the rfc2833compensate option turned on.

Also, please do not post bounties to the bug tracker.  This is often not the appropriate place for it.
By: Max Glucksmann (mglucksmann) 2006-08-19 12:19:36

I tested the branch in 005970 but received many errors such as my old CODECs not loading, Realtime CDR not being stored and no account codes being read through the dial plan with ${ACCOUNTCODE}.

I openned then rtp.c in the vldtmf branch and was able to see that the only difference between the RFC2833 process trigger clause was the following:

rtp->resp == 0

in:

if ( rtp->lasteventseqn <= seqno
  || rtp->resp == 0
  ||(rtp->lasteventseqn >= 65530 && seqno <= 6)) {
         f = process_rfc2833(
                 rtp,
                 rtp->rawdata + AST_FRIENDLY_OFFSET + hdrlen,
                 res - hdrlen, seqno);
                 rtp->lasteventseqn = seqno;
}

So I removed it, re-compiled and thanks to God and all of you the problem is gone.

I really want to thank you, please let me know where I can send the bounty to the community.

Contact me at mglucksmann at comtel-networks.com

You might as well want to remove that clause from the 1.2 branch version, it really gave me a hard time and may be doing it to other people too.

BTW, it is a great relief to see people being able to enter their cards' PINs at the first attempt and dial out correctly once more, thank you again.


By: Jason Parker (jparker) 2006-08-19 14:03:05

Since your problem is fixed, I'm closing this bug.  As far as the bounty goes...

Digium employees cannot accept this bounty.

You could either buy Digium hardware, or there are other charitable causes that could use your support.

http://www.voip-info.org - A great VoIP documentation resource
http://www.eff.org/ - The Electronic Frontier Foundation
http://www.fsf.org/ - The Free Software Foundation