[asterisk-commits] murf: branch 1.6.0 r134923 - in /branches/1.6.0: ./ main/features.c
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Thu Jul 31 14:54:58 CDT 2008
Author: murf
Date: Thu Jul 31 14:54:58 2008
New Revision: 134923
URL: http://svn.digium.com/view/asterisk?view=rev&rev=134923
Log:
Merged revisions 134922 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r134922 | murf | 2008-07-31 13:48:08 -0600 (Thu, 31 Jul 2008) | 63 lines
Merged revisions 134883 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(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.
........
................
Modified:
branches/1.6.0/ (props changed)
branches/1.6.0/main/features.c
Propchange: branches/1.6.0/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.
Modified: branches/1.6.0/main/features.c
URL: http://svn.digium.com/view/asterisk/branches/1.6.0/main/features.c?view=diff&rev=134923&r1=134922&r2=134923
==============================================================================
--- branches/1.6.0/main/features.c (original)
+++ branches/1.6.0/main/features.c Thu Jul 31 14:54:58 2008
@@ -1887,6 +1887,7 @@
struct ast_option_header *aoh;
struct ast_bridge_config backup_config;
struct ast_cdr *bridge_cdr = NULL;
+ struct ast_cdr *orig_peer_cdr = NULL;
memset(&backup_config, 0, sizeof(backup_config));
@@ -1924,6 +1925,7 @@
ast_copy_string(orig_channame,chan->name,sizeof(orig_channame));
ast_copy_string(orig_peername,peer->name,sizeof(orig_peername));
+ orig_peer_cdr = peer->cdr;
if (!chan->cdr || (chan->cdr && !ast_test_flag(chan->cdr, AST_CDR_FLAG_POST_DISABLED))) {
@@ -1958,8 +1960,9 @@
ast_cdr_answer(bridge_cdr);
ast_cdr_answer(chan->cdr); /* for the sake of cli status checks */
ast_set_flag(chan->cdr, AST_CDR_FLAG_BRIDGED);
- if (peer->cdr)
+ if (peer->cdr) {
ast_set_flag(peer->cdr, AST_CDR_FLAG_BRIDGED);
+ }
}
for (;;) {
struct ast_channel *other; /* used later */
@@ -2130,10 +2133,17 @@
ast_cdr_detach(bridge_cdr);
/* just in case, these channels get bridged again before hangup */
- if (chan->cdr)
+ if (chan->cdr) {
ast_cdr_specialized_reset(chan->cdr,0);
- if (peer->cdr)
- ast_cdr_specialized_reset(peer->cdr,0);
+ }
+ if (peer->cdr) {
+ if (orig_peer_cdr && peer->cdr != orig_peer_cdr) {
+ /* this can only happen if there was a transfer, methinks */
+ ast_cdr_specialized_reset(orig_peer_cdr,0);
+ } else {
+ ast_cdr_specialized_reset(peer->cdr,0);
+ }
+ }
}
return res;
}
More information about the asterisk-commits
mailing list