there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
was perverted. This change reverts IAX2 to the original meaning, which was,
that the callerid set on the client should be overridden on the server, even if
that means the resulting callerid is blank. In other words, if you set
"callerid=" in the IAX config, then the callerid should be overridden to blank,
even if set on the client. Note that there's a distinction, even on realtime,
between the field not existing (NULL in databases) and the field existing, but
set to blank (override callerid to blank).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@135747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
targeting areas where an unknown and potentially
long time has just elapsed. Also added a check
to try_calling() to return early if the timeout
has elapsed instead of potentially setting a negative
timeout for the call (thus making it have *no* timeout
at all).
(closes issue #13186)
Reported by: miquel_cabrespina
Patches:
13186.diff uploaded by putnopvut (license 60)
Tested by: miquel_cabrespina
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pj
(closes issue #13051)
Reported by: pj
This patch substitutes commas in the expr
supplied to the if () statement, as in
if ( expr ) ...
This solves both the bugs above, and makes
the source symmetric with switch statements,
which were earlier reported to need this sort
of treatment.
I tested this using the examples, both for
the compiler and at run time. Looks good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main aim of this branch was to make the IMAP
code function in the same manner as the ODBC code
does, eliminating the need for so many IMAP-specific
code chunks. The focal point of all of this work was
to make the various macros (e.g. RETRIEVE, DISPOSE)
functionally equivalent.
While doing the above work, I also fixed a few bugs
that I came across in my testing. Among these were
1. Fixed message forwarding. This was completely
broken when using IMAP.
2. Fixed the inability to save new messages as old
and vice versa.
3. Fixed the "delete" options in voicemail.conf when
using IMAP storage.
Even though a few bugs were fixed and the code is
a lot more consistent, the one thing that was *not*
improved in this branch was performance.
The merge of this to trunk may not come immediately
due to the amount of work it will probably involve.
(closes issue #12764)
Reported by: balsamcn
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134223 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
variable to the block where it is used. This allows one
less #ifdef HAVE_PRI to clutter things up.
Thanks to Tzafrir for pointing this out on #asterisk-dev
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@133038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
