Fix incorrect jitter buffer overflow due to missed resynchronizations

Fix incorrect jitter buffer overflow due to missed resynchronizations

When a change in time occurs, such that the timestamps associated with frames
being placed into an adaptive jitter buffer (implemented in jitterbuf.c)
are significantly different then the previously inserted frames, the jitter
buffer checks to see if it needs to be resynched to the new time frame.  If
three consecutive packets break the threshold, the jitter buffer resynchs
itself to the new timestamps.  This currently only occurs when history is
calculated, and hence only on JB_TYPE_VOICE frames.

JB_TYPE_CONTROL frames, on the other hand, are never passed to the history
calculations.  Because of this, if the jump in time is greater then the
maximum allowed length of the jitter buffer, the JB_TYPE_CONTROL frames are
dropped and no resynchronization occurs.  Alterntively, if the overfill
logic is not triggered, the JB_TYPE_CONTROL frame will be placed into the
buffer, but with a time reference that is not applicable.  Subsequent
JB_TYPE_VOICE frames will quickly trigger the overflow logic until reads
from the jitter buffer reach the errant JB_TYPE_CONTROL frame.

This patch allows JB_TYPE_CONTROL frames to resynch the jitter buffer.  As
JB_TYPE_CONTROL frames are unlikely to occur in multiples, it perform the
resynchronization on any JB_TYPE_CONTROL frame that breaks the resynch
threshold.

Note that this only impacts chan_iax2, as other consumers of the adaptive
jitter buffer use the abstract jitter buffer API, which does not use
JB_TYPE_CONTROL frames.

Review: https://reviewboard.asterisk.org/r/1814/

(closes issue ASTERISK-18964)
Reported by: Kris Shaw
Tested by: Kris Shaw, Matt Jordan
Patches:
  jitterbuffer-2012-2-26.diff uploaded by Kris Shaw (license 5722)

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359356 65c4cc65-6c06-0410-ace0-fbb531ad65f3