[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug
From: Ross Beer <ross.beer () outlook ! com>
Date: 2015-10-09 14:23:06
Message-ID: SNT151-W8279D3CE205F4E5D2AD8EDFF340 () phx ! gbl
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@digium.com
> To: asterisk-dev@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@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
[Attachment #5 (text/html)]
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Matthew,<BR> <BR>Thank you for your \
reply.<BR> <BR>I have created issue ASTERISK-25458 regarding \
this. <BR> <BR>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.<BR> <BR>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.<BR> <BR>Kind \
regards,<BR> <BR>Ross<br> <BR><div>> Date: Fri, 9 Oct 2015 08:50:16 \
-0500<br>> From: mjordan@digium.com<br>> To: \
asterisk-dev@lists.digium.com<br>> Subject: Re: [asterisk-dev] Asterisk 13.6.0-rc2 \
Possible CDR Bug<br>> <br>> On Wed, Oct 7, 2015 at 2:06 PM, Ross Beer \
<ross.beer@outlook.com> wrote:<br>> > Hi,<br>> ><br>> > I am \
having an issue setting custom variables in a CDR record for a call<br>> > once \
it has hung up. Setting variables before a dial are inserted into the<br>> > \
CDR correctly. I am using the following hangup_handler as per previous<br>> > \
versions:<br>> ><br>> > [record-hangupcause]<br>> ><br>> > \
exten => s,1,Set(CDR(hangupcause)=${HANGUPCAUSE})<br>> > exten => \
s,n,Return()<br>> ><br>> ><br>> > Before the dial a hangup handler \
is registered:<br>> ><br>> > \
Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1)<br>> ><br>> \
><br>> > The routine is called and the variables are being set, however not \
on the<br>> > channel's CDR which made the call.<br>> ><br>> > By \
changing the cdr option 'endbeforehexten=no' this should keep the CDR<br>> > \
accessible, however all this does is cause another CDR to be created for the<br>> \
> 'h' extension.<br>> ><br>> > Is there currently a bug with accessing \
CDR data for a channel that has been<br>> > hung-up? It looks to me that the \
CDR is closed before the hangup_handler is<br>> > called. However this \
shouldn't be the case!<br>> > I would be grateful for any feedback you can \
offer!<br>> ><br>> > I am happy to open a bug report, but I would prefer \
to have this<br>> > acknowledged before doing so.<br>> > Ross<br>> \
><br>> <br>> Hey Ross -<br>> <br>> Sorry I didn't reply \
sooner.<br>> <br>> The short answer is that it is working as designed; the long \
answer is<br>> that I think the design is wrong. (As the guy responsible, I feel \
like<br>> I'm only throwing stones at myself.)<br>> <br>> Keeping a single \
CDR running after channels have left a bridge was one<br>> of those things that \
was relatively "easy" in 11 and earlier versions,<br>> and is a bit more \
challenging in 13. I think in this case that we<br>> probably should revisit the \
rules around it.<br>> <br>> I do know this has come up a few times on the \
mailing lists, but I<br>> don't think anyone has made an issue yet. Please do made \
one,<br>> referencing this discussion.<br>> <br>> Just to summarize what I \
think should happen:<br>> <br>> endbeforehexten=no should cause no new CDR to \
be created in the 'h'<br>> extension, and the 'end' time on the CDR should not be \
set. The CDR<br>> should allow manipulation of its properties via the CDR \
function.<br>> <br>> Does that sound right?<br>> <br>> -- <br>> \
Matthew Jordan<br>> Digium, Inc. | Director of Technology<br>> 445 Jan Davis \
Drive NW - Huntsville, AL 35806 - USA<br>> Check us out at: http://digium.com \
& http://asterisk.org<br>> <br>> -- <br>> \
_____________________________________________________________________<br>> -- \
Bandwidth and Colocation Provided by http://www.api-digital.com --<br>> <br>> \
asterisk-dev mailing list<br>> To UNSUBSCRIBE or update options visit:<br>> \
http://lists.digium.com/mailman/listinfo/asterisk-dev<br></div> \
</div></body> </html>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic