Summary:	ASTERISK-13509: Calls coming in then out do not get recorded in CDR
Reporter:	Chilling_Silence (chilling_silence)	Labels:
Date Opened:	2009-02-03 20:55:11.000-0600	Date Closed:	2009-06-24 18:01:39
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	CDR/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk 1.4.21.2 2.6.18-53.1.19.el5 We've been noticing a few things with relation to calls and transfers. To help, we've put x before the internal extensions... Example: x205 -> x209 -> Cellphone We can see the call from 205 -> 209, but not when 209 transfers the call to the Cell (End result is x205 talking to Cellphone) x205 -> Cellphone This works fine, just a regular outbound call Incoming -> x205 -> x209 -> Cellphone We can see the call in the CDR log coming in, then being transferred to x205, then being transferred to x209, but then when x209 transfers it to a Cellphone, we cant seem to see that. Incoming -> x205 -> Cellphone Can see the incoming to x205, but not when x205 transfers it to Cellphone.
Comments:	By: Chilling_Silence (chilling_silence) 2009-02-03 21:35:46.000-0600 Have just been in #asterisk, they suggested I try the endbeforehexten=no as well as unanswered=yes. Unfortunately neither made a difference. All other logging is working fine though from what I can see, its only in this scenario that it doesnt. I have noticed that the "LastData" field contains the SIP trunk / destination number, but its not creating a call record for it. Thats the crucial part, as we'll be using that for billing customers for outbound calls... Am working at getting some hardware so I dont have to use a production box to test the latest version of asterisk with, just going through the asterisk changelog I can see there's been quite a few updates to CDR stuff :) By: Steve Murphy (murf) 2009-02-06 12:37:16.000-0600 How exactly do you dial the cellphone? What device do you use? Sip? dahdi? chan_mobile? By: Chilling_Silence (chilling_silence) 2009-02-08 14:03:51.000-0600 Tested with both a Linksys SPA942 as well as Zoiper Softphone. Everything is 100% SIP, both the inbound and outbound channels. By: Steve Murphy (murf) 2009-02-10 13:28:01.000-0600 Hmmm... how are you transferring to the cellphone? Are you using an asterisk feature or a SIP phone feature? To repro this, I'll need you dialplan (at least the parts that control things, and the 209/205 entries in sip.conf. I have a zoiper, but no spa942. If you put some option into a sip phone to do the xfer, beware that unless the cell phone reports this to asterisk (actually, uses asterisk to do it), then asterisk will not be able to record it. By: Chilling_Silence (chilling_silence) 2009-02-15 19:51:01.000-0600 Doesnt matter, we can use either the xfer button on a Linksys SPA942, pressing the Transfer in Zoiper Softphone, or using ## from a Cordless phone via an ATA. Happens regardless of it being a blind or attended transfer. Basically: Call from Inbound trunk connected with Ext Ext transfer to External party out any trunk and connects the two The call is still active between the first party that dialed in and the final destination, however the Ext has since hung up (transfer connected the two parties). Asterisk is still relaying the call between the two parties however, potentially incurring costs dependant upon your ITSP etc. Appears it may be related to this: http://bugs.digium.com/view.php?id=11849 By: Sverre G (sverre) 2009-03-18 19:58:27 I just tried this using 1.4.22 and didn't have this problem. Sure enough the LENGTH of one of the transferred calls was incorrect, as per http://bugs.digium.com/view.php?id=11849 but there were 2 CDRs created for each of the two calls in the scenario x205 -> x209 -> Cellphone. I tested it by using MizuPhone->Snom m3->mobile number in both a blind and attended transfer situation, and no dramas. By: Matthew Nicholson (mnicholson) 2009-05-19 12:56:13 Is this still a bug with the latest 1.4 SVN build? By: Sverre G (sverre) 2009-05-25 20:26:37 I've consistently found in my production system (1.4.22) and in my test system (SVN-branch-1.4-r196116), that there are 2 CDRs for A -> B, transfer to C, and any variant thereof. Like I said earlier, bug 11849 has noted incorrect DURATIONS of the call. I think this bug can be marked as fixed. I certainly can't manage to reproduce ending up with only one CDR from a transfer. By: Matthew Nicholson (mnicholson) 2009-05-26 17:07:42 Ok.  I'll check this out some more.