Recorded merge of revisions 254452 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Thu, 25 Mar 2010 16:04:48 +0000 (16:04 +0000)
committerMark Michelson <mmichelson@digium.com>
Thu, 25 Mar 2010 16:04:48 +0000 (16:04 +0000)
commitbd716c50fd3fea127a8a586495c645ed04efeb71
tree4b118908bf3396709e838a6c22da43c422399e0e
parent408ba24fad6d176690fa021cd31223606f6fc37a
Recorded merge of revisions 254452 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines

  Several fixes regarding RFC2833 DTMF detection.

  Here is a copy and paste of the details from my request on
  reviewboard that dealt with these changes:

  Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:

  seqno 1: DTMF 1
  seqno 2: DTMF 1
  seqno 3: DTMF 1
  seqno 4: DTMF 1
  seqno 6: DTMF 1 (end)
  seqno 5: DTMF 1
  seqno 7: DTMF 1 (end)
  seqno 8: DTMF 1 (end)

  Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:

  seqno  9: DTMF 1
  seqno 10: DTMF 1 (end)
  seqno 11: DTMF 1 (end)
  seqno 13: DTMF 2
  seqno 12: DTMF 1 (end)
  seqno 14: DTMF 2
  seqno 15: DTMF 2 (end)
  seqno 16: DTMF 2 (end)
  seqno 17: DTMF 2 (end)

  In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.

  Fix 2. The second change in place is to fix an issue like the following:

  seqno 1: DTMF 1
  seqno 2: DTMF 1
  seqno 3: DTMF 1 (end) *packet lost*
  seqno 4: DTMF 1 (end) *packet lost*
  seqno 5: DTMF 1 (end) *packet lost*
  seqno 6: DTMF 2

  When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.

  Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res/res_rtp_asterisk.c