While endpoints should not be changing the source timestamp between DTMF event
packets, the fact is there exists those endpoints that do exactly that. To
work around this, we absorb timestamps within the expected re-transmit period.
Note that this period only affects End of Event packets, so it should not
prevent the detection of new DTMF digits that happen to arrive right on top
of each other.
(closes issue ASTERISK-20424)
Reported by: Vladimir Mikhelson
Tested by: mjordan, Vladimir Mikhelson
Review: https://reviewboard.asterisk.org/r/2124
........
Merged revisions 373236 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373237 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373238
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
new_duration = (new_duration & ~0xFFFF) | samples;
if (event_end & 0x80) {
- /* End event */
- if ((rtp->last_seqno != seqno) && (timestamp > rtp->last_end_timestamp)) {
+ /* End event. Absorb re-transmits, and account for some endpoints
+ * that erroneously increment the timestamp during re-transmissions */
+ if ((seqno != rtp->last_seqno) && (timestamp > rtp->last_end_timestamp + 320)) {
rtp->last_end_timestamp = timestamp;
rtp->dtmf_duration = new_duration;
rtp->resp = resp;
rtp->dtmf_duration = rtp->dtmf_timeout = 0;
AST_LIST_INSERT_TAIL(frames, f, frame_list);
} else if (rtpdebug) {
- ast_debug(1, "Dropping duplicate or out of order DTMF END frame (seqno: %d, ts %d, digit %c)\n",
+ ast_debug(1, "Dropping re-transmitted, duplicate, or out of order DTMF END frame (seqno: %d, ts %d, digit %c)\n",
seqno, timestamp, resp);
}
} else {