diff options
author | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-07-31 19:23:42 +0000 |
---|---|---|
committer | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-07-31 19:23:42 +0000 |
commit | 8be3958fd483c8238acbb5248444f2d51a7ec57f (patch) | |
tree | f0eb8807de0ce847f3c75efa2edaca32547de920 /apps/app_ices.c | |
parent | 35407ccc2eab0412fbf5356a6091d3f1627c4a79 (diff) |
(closes issue #11849)
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: http://svn.digium.com/svn/asterisk/branches/1.4@134883 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'apps/app_ices.c')
0 files changed, 0 insertions, 0 deletions