Review Board 1.7.16

Fix CDR records for outbound SLA calls.

Review Request #2326 - Created Feb. 11, 2013 and updated

Calls routed to a external trunk through SLAStation() do not maintain a CDR record for the outbound channel.  Normally when an asterisk extension dials another extension (or trunk) two CDR records are maintained, one attached to each channel. However when the call is routed through SLAStation() then there is an intermediary "local" channel which initiates the Dial() to the called extension (or trunk).  When it answers the originating channel and the called channel are bridged together with some do_masquerade() magic and the "local" channels go away.  This occurs within a MeetMe conference and the process of bridging and masquerading messes up the CDR and in fact causes the outbound channel CDR to be marked AST_CDR_NULL which effectively neuters it.

This patch does two things...
1) When a masquerade is detected inside the conf_run() function it fixes up the CDR for the newly masqueraded channel so that it is correct.
2) When a SLA call ends in the dial_trunk() function and if the "attemptcallerid=yes" is set in sla.conf then the CDR record for the outbound channel is fixed up such that originating channel name, number, callerid, etc. is set to that of the channel that originated the SLAStation() dial request.

This ensures that accurate call duration and billing seconds can be determined from CDR records when SLA feature is used.  Behavior of fixing up the outbound channels originating information can be suppressed by setting attemptcallerid=no in the sla.conf file.  This configuration statement already exists, this patch expands its use.

Please also see comments in the code.
Have been running this patch successfully for a couple of months on my asterisk server and routed outbound calls through both SIP and GTalk/Motif. The attached patch is for trunk, but I have tested 1.8 version and 11 versions. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to