[asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug

[Ross Beer]

Hi Matthew,
 
Thank you for your reply.
 
I have created issue ASTERISK-25458 regarding this. 
 
I agree with your summary, basically this would be really useful in a failover situation. For example if one route was tried and failed, the hang-up cause could be stored for the first call. At present the hang-up cause will be set in the next call attempt and therefore not relate to the actual call that had the issue. Another situation would be where you wish to store call stats to calculate a MOS score for a given call, etc, etc.
 
I've raise another issue today with regards to chan_pjsip  and MOH (ASTERISK-25457), where by Asterisk 13 isn't placing a call on hold when receiving an invite with 'a=sendonly'. I expected to see an invite with the IP address of 0.0.0.0, however both SNOM and Cisco SPA phones use the same method of placing a call on hold. I initially thought this was an issue with MOH, however I believe the issue relates to chan_pjsip and how it identifies a call hold situation. Any feedback on this issue would be appreciated.
 
Kind regards,
 
Ross
 
> Date: Fri, 9 Oct 2015 08:50:16 -0500
> From: mjordan at digium.com
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug
> 
> On Wed, Oct 7, 2015 at 2:06 PM, Ross Beer <ross.beer at outlook.com> wrote:
> > Hi,
> >
> > I am having an issue setting custom variables in a CDR record for a call
> > once it has hung up. Setting variables before a dial are inserted into the
> > CDR correctly. I am using the following hangup_handler as per previous
> > versions:
> >
> > [record-hangupcause]
> >
> > exten => s,1,Set(CDR(hangupcause)=${HANGUPCAUSE})
> > exten => s,n,Return()
> >
> >
> > Before the dial a hangup handler is registered:
> >
> > Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1)
> >
> >
> > The routine is called and the variables are being set, however not on the
> > channel's CDR which made the call.
> >
> > By changing the cdr option 'endbeforehexten=no' this should keep the CDR
> > accessible, however all this does is cause another CDR to be created for the
> > 'h' extension.
> >
> > Is there currently a bug with accessing CDR data for a channel that has been
> > hung-up? It looks to me that the CDR is closed before the hangup_handler is
> > called. However this shouldn't be the case!
> > I would be grateful for any feedback you can offer!
> >
> > I am happy to open a bug report, but I would prefer to have this
> > acknowledged before doing so.
> > Ross
> >
> 
> Hey Ross -
> 
> Sorry I didn't reply sooner.
> 
> The short answer is that it is working as designed; the long answer is
> that I think the design is wrong. (As the guy responsible, I feel like
> I'm only throwing stones at myself.)
> 
> Keeping a single CDR running after channels have left a bridge was one
> of those things that was relatively "easy" in 11 and earlier versions,
> and is a bit more challenging in 13. I think in this case that we
> probably should revisit the rules around it.
> 
> I do know this has come up a few times on the mailing lists, but I
> don't think anyone has made an issue yet. Please do made one,
> referencing this discussion.
> 
> Just to summarize what I think should happen:
> 
> endbeforehexten=no should cause no new CDR to be created in the 'h'
> extension, and the 'end' time on the CDR should not be set. The CDR
> should allow manipulation of its properties via the CDR function.
> 
> Does that sound right?
> 
> -- 
> Matthew Jordan
> Digium, Inc. | Director of Technology
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151009/5d37c253/attachment-0001.html>