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
Prior to this change, a spiraled INVITE would cause a 482
Loop Detected to be sent to the caller. With this change,
if a potential loop is detected, the Request-URI is inspected
to see if it has changed from what was originally received. If
pedantic mode is on, then this inspection is fully RFC 3261
compliant. If pedantic mode is not on, then a string comparison
is used to test the equality of the two R-URIs.
This has been tested by using OpenSER to rewrite the R-URI
and send the INVITE back to Asterisk.
(closes issue #7403)
Reported by: stephen_dredge
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132790 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
seems to be in regards to an error message when retransmit fails. This
is frequently misunderstood as a failure of Asterisk, not a failure of
the network to reach the other party.
This document tries to assist the Asterisk user in sorting out these
issues by explaining the logic and pointing at some possible
causes. Hopefully, we will get other questions now :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Russell Bryant
Michiel van Baak
Kevin P. Fleming
Steve Murphy
Mark Michelson
Jason Parker
Christian Richter
Olle Johansson