Summary:	ASTERISK-20747: [patch] SLA outbound calls do not record accurate CDR record.
Reporter:	dkerr (dkerr)	Labels:	patch
Date Opened:	2012-11-27 18:35:46.000-0600	Date Closed:
Priority:	Major	Regression?	No
Status:	Open/New	Components:	Applications/app_meetme Applications/SLA
Versions:	1.8.18.0 11.0.1 13.18.4	Frequency of Occurrence
Related Issues:
Environment:	Astlinux	Attachments:	( 0) asterisk-1.8-bugid20747.patch ( 1) asterisk-11-bugid20747.patch
Description:	In further pursuit of SLA happiness I have found that outbound calls from an SLAStation to a SIP trunk do not record an accurate CDR.  This is a problem for any environment where billsec is required for billing purposes. This occurs 100% of the time, but understanding what is going on is fairly complex.  Consider first what happens in a non-SLA environment... A SIP extension places a call through Asterisk, asterisk uses Dial() command to connect the call to an outbound SIP trunk.  There is an inbound SIP channel from the telephone to asterisk, and an outbound SIP channel from asterisk to the VoIP provider. Asterisk bridges these and records in a single CDR record the start time, answer time and end time and the source and destination SIP channels, et al. Nice. Now consider a scenario where a SLAStation makes an outbound call. In this case there is a channel into asterisk from the telephone that is placed into a Meetme conference. Then the SLA code triggers a Dial() to the requested destination, say a SIP VoIP provider trunk and when it answers it is also placed into the Meetme conference.  Any other SLAStation can also join this meetme conference. In this scenario Asterisk generates two CDR records. One for the telephone connecting into the conference. Another for the channel connecting to the VoIP provider.  If another extension also joins the call by connecting into the same SLA trunk (joining the same call) then it generates its own CDR record.  So far so good. The problem is that the CDR record for the connection out from asterisk to the VoIP provider shows a billsec of zero.  In fact the CDR is "ended" when the destination party answers, instead of when they hangup.
Comments:	By: dkerr (dkerr) 2012-11-27 18:45:06.431-0600 So, I've spent several days figuring out what is going on, and its not nice.  For starters the CDR data (specifically billsec) on the inbound channel from a telephone will vary.  If the call is directly connected by the dialplan then "answer time" is accurately recorded as the time the eventual destination picks up.  However if the dialplan answers, say by going into DISA() like all the SLA examples propose, then the answer time is time DISA generates a dialtone... essentially the same as start time.  But this is not what is desired as that is not billable... it only becomes billable when the destination picks up.  Further, if two local extensions connect into the Meetme conference then the second line has a start/answer/end time based on when they join/leave the "conference". So, billsec's associated with the inbound channels from telephones cannot be used for billing purposes. What is needed is a CDR record for the channel that goes out from the Meetme conference to the VoIP trunk. By: dkerr (dkerr) 2012-11-27 18:52:45.872-0600 I have been looking at the source code to figure out how to fix this and my analysis implicates channel bridging (in features.c) and channel masquerading (in channel.c) it is actions that take place in these that cause the problem.  Specifically, when the outbound VoIP channel is answered at the destination, the bridge code attempts to "connect" it to the "Local" channel that performed the Dial(). In doing so a masquerade is performed to move the newly answered "SIP" channel into the structure of the existing "Local" channel. This screws up CDR records and in recognition of this a ast_cdr_specialized_reset() is performed by the bridge code which has the effect of marking the record(s) as AST_CDR_NULL and this then blocks all future logging of the CDR. By: dkerr (dkerr) 2012-11-27 18:56:44.565-0600 With the background I have just described, please take a look at the patch that I attach inside of which are further comments.  My "fix" is implemented entirely within the app_meetme.c code but as I am no asterisk expert this needs thorough review.  I'm not even convinced myself that I have got this right.  I am, for example, maybe re-purposing the SLA "attemptcallerid" conf file setting.  Also it needs thorough testing across channel types.  I believe what I have here is an improvement on current situation, but probably not perfect. By: dkerr (dkerr) 2012-11-27 19:00:40.861-0600 This is 1.8 version of patch.  Working on similar one for trunk/11 version. By: Rusty Newton (rnewton) 2012-11-28 17:33:25.024-0600 https://wiki.asterisk.org/wiki/display/AST/Reviewboard+Usage   You'll want to post those patches on reviewboard. If you don't have access, you'll want to request it from " mjordan at digium dot com ". By: dkerr (dkerr) 2012-11-28 18:22:41.525-0600 Rusty,  Thanks and yes when its ready I'll see how to get a trunk-level version of the patch onto reviewboard.  For now I'm still looking into what is going on in various situations.  For example when you Dial() to a context/exten that becomes a "Local" channel which has both a ;1 and ;2 side to the channel. My patch is not currently emulating what might be considered expected behavior if that same Dial() had taken place in a non-SLA configuration (CDRs on both sides of the channel should be fixed). The purpose of opening this bug now was to give visibility to the problem I am working on. Thanks. By: David Woolley (davidw) 2012-11-29 10:35:19.807-0600 My understanding is that CDRs are no longer being maintained because they don't handle all but the simplest cases well and attempting to change them to fix one case tens to break another.  Call Event Logging was introduced to get round the limitations of CDRs. Also, your point about answer times only reflecting the outgoing answer time when the incoming side isn't answered earlier reflects intended behaviour.  If you don't want that behaviour, you need to answer the incoming call and then reset the CDR. By: dkerr (dkerr) 2012-12-01 20:18:17.980-0600 Versions of patch for both Asterisk 1.8 and Asterisk 11