The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@135841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@135799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@133169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
correct registration of AMI actions in chan_dahdi; in zap-only mode, only register the Zap flavors of the actions (and use Zap prefixes for headers and acks), but in dahdi+zap mode, register both Zap and DAHDI flavors of actions
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
added a very obvious runtime warning if this condition reoccurs, so the developer who broke it can be chastised into fixing it :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
core instead of being P2P bridged. When the core regenerated
the rfc2833 packet for the outbound leg, the SSRC would be different
than the RTP audio on the call leg causing DTMF detection issues on
the far end.
(closes issue #12955)
Reported by: tonyredstone
Patches:
dynamic_rtp.patch uploaded by tsearle (license 373)
Tested by: tonyredstone
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we continued, then the result would be calling poll() with a NULL
pollfd array. While this is fine with POSIX's poll(2) system call, those
who use Asterisk's internal poll mechanism (Darwin systems) would have
a failed assertion occur when poll is called.
(related to issue #10342)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
