[asterisk-bugs] [Asterisk 0014660]: [patch] Lost info in CDR when transfering call via AMI's Redirect
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Aug 13 20:41:33 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-13 20:41 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?
======================================================================
----------------------------------------------------------------------
(0109026) escape2mtns (reporter) - 2009-08-13 20:41
https://issues.asterisk.org/view.php?id=14660#c109026
----------------------------------------------------------------------
After application of all patches, some things work and some still don't
seem right but I have to study some more to make sure unrelated issues
aren't clouding the picture.
This test is identical to the one above, with the exception that the queue
777 also rings SIP/111 (but it doesn't answer). The records seemed out of
order so I sorted them by calldate before exporting from MySQL.
Roughly 23 seconds after answering the call I put the caller and agent on
"hold" (redirect to music on hold context). I left that until around 34
seconds into the call when the agent was placed in a meetme (qvpickup) with
the originated outbound call (qvcallpickup). 40 seconds into the call the
original inbound channel was redirected into the meetme with the outbound
call and the agent was disconnected.
Notes/Points of concern:
* Item https://issues.asterisk.org/view.php?id=2 is one I can't explain
1) The second cdr entry is the event where the call is answered by
extension 170 and the 3rd entry is when that extension goes to "hold" with
the inbound caller.
2) The 4th cdr entry is the inbound call being answered but it's
duplicated entirely in the 5th cdr entry.
3) The outbound call sent originated to 3333333333 at from-internal from
Local/<meetme #>@qvcallpickup shows a duration of 8 seconds when that
channel was in the meetme for 30+ seconds. I might know what's causing
this though. We originate from the meetme but then when we patch the
inbound caller with the outbound call, we do another redirect for both the
inbound channel and the outbound channel into the same meetme (this was
done so we don't have to check logic on who was in the meetme beforehand..
the agent could have had either leg on hold and be speaking with the other
when the patch command was sent). The 8 seconds does correlate with the
duration of the originate before that leg is redirected back to the same
meetme conference.
"calldate";"clid";"src";"dst";"dcontext";"channel";"dstchannel";"lastapp";"lastdata";"duration";"billsec";"disposition";"amaflags";"accountcode";"uniqueid";"userfield";"agent"
"2009-08-13 20:07:09";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7610870";"SIP/111-09f531d8";"Queue";"777|tr||custom/Txfr-From-Auto-Att";"2";"0";"NO
ANSWER";"3";"2222222222";"1250208429.589";;
"2009-08-13 20:07:09";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7610870";"SIP/170-09e798f0";"Queue";"777|tr||custom/Txfr-From-Auto-Att";"24";"0";"NO
ANSWER";"3";"2222222222";"1250208429.588";;
"2009-08-13 20:07:09";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7610870";"SIP/170-09e798f0";"MusicOnHold";;"33";"0";"NO
ANSWER";"3";"2222222222";"1250208429.588";;
"2009-08-13 20:07:09";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7610870";"SIP/170-09e798f0";"Queue";"777|tr||custom/Txfr-From-Auto-Att";"24";"24";"ANSWERED";"3";"2222222222";"1250208429.587";;
"2009-08-13 20:07:09";"\"CALLER NAME \"
<1111111111>";"1111111111";"777";"ext-queues";"SIP/SIP1-b7610870";"SIP/170-09e798f0";"Queue";"777|tr||custom/Txfr-From-Auto-Att";"24";"24";"ANSWERED";"3";"2222222222";"1250208429.587";;
"2009-08-13 20:07:33";"\"CALLER NAME \"
<1111111111>";"1111111111";"1250208429587";"qvmeetme";"SIP/SIP1-b7610870";"SIP/170-09e798f0";"MeetMe";"1250208429587|1dFqAx";"17";"17";"ANSWERED";"2";"2222222222";"1250208429.587";;
"2009-08-13
20:07:42";"2222222222";"2222222222";"3333333333";"from-internal";"Local/1250208429587 at qvcallpickup-e2b9,1";"SIP/SIP1-09f03ed0";"ResetCDR";"vw";"8";"6";"ANSWERED";"3";"2222222222";"1250208462.591";"3";
"2009-08-13 20:07:42";"\"CALLER NAME \"
<1111111111>";"1111111111";"1250208429587";"qvpickup";"SIP/170-09e798f0";"SIP/170-09e798f0";"MeetMe";"1250208429587|1dFqAx";"8";"0";"FAILED";"2";;"1250208453.590";;
"2009-08-13
20:07:42";"2222222222";"2222222222";"1250208429587";"qvcallpickup";"Local/1250208429587 at qvcallpickup-e2b9,2";;"MeetMe";"1250208429587|1dFqx";"8";"8";"ANSWERED";"3";"2222222222";"1250208462.592";;
Issue History
Date Modified Username Field Change
======================================================================
2009-08-13 20:41 escape2mtns Note Added: 0109026
======================================================================
More information about the asterisk-bugs
mailing list