[asterisk-bugs] [Asterisk 0014660]: [patch] Lost info in CDR when transfering call via AMI's Redirect
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Aug 17 11:39:26 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=14660
======================================================================
Reported By: caspy
Assigned To: mnicholson
======================================================================
Project: Asterisk
Issue ID: 14660
Category: CDR/General
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.6.0.6
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-03-13 09:11 CDT
Last Modified: 2009-08-17 11:39 CDT
======================================================================
Summary: [patch] Lost info in CDR when transfering call via
AMI's Redirect
Description:
- SIP/1344 call SIP/1340
- SIP/1340 answers, and they are speaking
- man-in-a-middle do a Redirect of SIP/1344 leg of this call to SIP/1341
- SIP/1341 answers, and 1344 speaks with 1341 successfuly.
The probles is in CDR.
For the first call (1344 to 1340) asterisk lost just all important
fields:
"","","s","fromoffice","","SIP/1340-08c6dce8","","","","2009-03-13
16:37:44","2009-03-13 16:37:47","2009-03-13
16:37:54",10,7,"ANSWERED","DOCUMENTATION","1236951464.550476",""
"","1344","1341","fromoffice","""Akzhan Test""
<1344>","SIP/1344-b4b3e758","SIP/1341-b51deec0","Dial","SIP/1341,60,twTWL(5400000)","2009-03-13
16:37:44","2009-03-13 16:38:00","2009-03-13
16:38:05",21,5,"ANSWERED","DOCUMENTATION","1236951464.550474",""
Also, mention that uniqueid is very strange: first part (time) is the
same, but second is decreesed for two. Why?
======================================================================
----------------------------------------------------------------------
(0109136) escape2mtns (reporter) - 2009-08-17 11:39
https://issues.asterisk.org/view.php?id=14660#c109136
----------------------------------------------------------------------
There were positive effects in each of the two patches. Maybe we need a
combination of the two like:
if (chan->pbx) {
struct ast_cdr *cdr;
/* Create a new cdr record. The reasoning here is as
follows:
* because the channel with the PBX on it generally stores
the
* CDR record, we fork the CDR so that the information
from the
* original call is not lost.
*/
if (!chan->cdr) {
if (!(cdr = ast_cdr_alloc())) {
astman_send_error(s, m, "Redirect failed,
error allocating CDR.");
ast_channel_unlock(chan);
if (chan2) {
ast_channel_unlock(chan2);
}
return 0;
}
ast_cdr_init(cdr, chan);
ast_cdr_start(cdr);
ast_cdr_end(chan->cdr);
}
else {
if (!(cdr = ast_cdr_dup(chan->cdr))) {
astman_send_error(s, m, "Redirect failed,
error allocating CDR.");
ast_channel_unlock(chan);
if (chan2) {
ast_channel_unlock(chan2);
}
return 0;
}
ast_cdr_reset(cdr, NULL);
ast_cdr_init(cdr, chan);
ast_cdr_end(chan->cdr);
}
ast_set_flag(chan->cdr, AST_CDR_FLAG_DONT_TOUCH |
AST_CDR_FLAG_LOCKED);
ast_cdr_append(chan->cdr, cdr);
/* don't let the after-bridge code run the h-exten */
ast_set_flag(chan, AST_FLAG_BRIDGE_HANGUP_DONT);
}
Issue History
Date Modified Username Field Change
======================================================================
2009-08-17 11:39 escape2mtns Note Added: 0109136
======================================================================
More information about the asterisk-bugs
mailing list