]> git.ipfire.org Git - thirdparty/asterisk.git/commit
(closes issue #11849)
authorSteve Murphy <murf@digium.com>
Thu, 31 Jul 2008 19:23:42 +0000 (19:23 +0000)
committerSteve Murphy <murf@digium.com>
Thu, 31 Jul 2008 19:23:42 +0000 (19:23 +0000)
commit08450d1a93d56d944f04f5ee87dcde6db6e5b5af
treef0eb8807de0ce847f3c75efa2edaca32547de920
parentd90285f4f5815dceab2aa055d431965de21a9597
(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: https://origsvn.digium.com/svn/asterisk/branches/1.4@134883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res/res_features.c