<div dir="ltr"><div><div><div><div><div>As a complement to my previous post, may I add that I observed the following behaviours:<br><br></div>1. On one system (Debian Stretch/asterisk 13.19 compiled from source), hangup causes are correctly saved in a custom CDR column.<br><br></div>2. On an other system (Debian Stretch/packaged asterisk), some rtcp stats are not-correctly saved in a custom CDR column (I also tried unsuccessfully with userfield column).<br><br></div>In both cases:<br>- CDR updates are triggered by a hangup handler pushed with CHANNEL(hangup-handler-push).<br></div>- CDR are saved through ODBC i, aMariaDB or Postgres database.<br><br></div>Toughts ?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-21 0:07 GMT+01:00 Olivier <span dir="ltr"><<a href="mailto:oza.4h07@gmail.com" target="_blank">oza.4h07@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Reading this old thread, may I ask if keeping hangup handlers from updating CDR values still enforced in Asterisk 15 ?</div><div>If positive, would it be very complex to add in Asterisk, a configuration option allowing a system administrator to list in cdr.conf, the CDR fields allowed to be updated in hangup handlers ?</div><div><br></div><div>I'm planning to store some RTCP stats.</div><div>Saving them in CDR(userfield) would be perfect.</div><div><br></div><div>Cheers</div><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-08-10 15:05 GMT+02:00 Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Aug 4, 2015 at 9:16 AM, Filip Jenicek <span dir="ltr"><<a href="mailto:fjenicek@kerio.com" target="_blank">fjenicek@kerio.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    With endbeforehexten=no I actually get two CDR entries. One for the
    call and a second one for the "h" extension.<br>
    <tt>"","13","10","sip-locals","""1<wbr>3""
      <13>","SIP/13-00000006","SIP/1<wbr>0-00000007","Dial","SIP/10","2<wbr>015-08-04

      06:28:44","2015-08-04 06:28:45","2015-08-04
      06:28:47",3,1,"ANSWERED","DOCU<wbr>MENTATION","1438669724.6","<wbr>empty"</tt><tt><br>
    </tt><tt>"","13","h","sip-locals","""13<wbr>""
      <13>","SIP/13-00000006","","No<wbr>Op","changed","2015-08-04
      06:28:47","2015-08-04 06:28:47","2015-08-04
      06:28:47",0,0,"ANSWERED","DOCU<wbr>MENTATION","1438669724.6","<wbr>changed"</tt><br>
    The first one contains the call itself. There are durations, CDR
    variables set during the call, etc.<br>
    The second one contains only things configured in the "h" extension.<br>
    <br>
    With endbeforehexten=yes, the cdr contains:<br>
    <tt>"","13","10","sip-locals","""1<wbr>3""
      <13>","SIP/13-00000006","SIP/1<wbr>0-00000007","Dial","SIP/10","2<wbr>015-08-04

      06:28:44","2015-08-04 06:28:45","2015-08-04
      06:28:47",3,1,"ANSWERED","DOCU<wbr>MENTATION","1438669724.6","<wbr>empty"</tt><br>
    There is only the call, nothing from the "h" extension.<br>
    <br>
    I forgot to mention that I'm using Asterisk 13.1-cert2. Modifying
    CDR records in the "h" extension used to work fine with Asterisk
    1.8.<br>
    <br>
    By analyzing the code I must confirm that the endbeforehexten option
    behaves exactly according to its description: <br>
    <tt> As each CDR for a channel is finished, its end time is updated</tt><tt><br>
    </tt><tt> and the CDR is finalized. When a channel is hung up and
      hangup</tt><tt><br>
    </tt><tt> logic is present (in the form of a hangup handler or the</tt><tt><br>
    </tt><tt> <literal>h</literal> extension), a new CDR is
      generated for the</tt><tt><br>
    </tt><tt> channel. Any statistics are gathered from this new CDR. By
      enabling</tt><tt><br>
    </tt><tt> this option, no new CDR is created for the dialplan logic
      that is</tt><tt><br>
    </tt><tt> executed in <literal>h</literal> extensions or
      attached hangup handler</tt><tt><br>
    </tt><tt> subroutines. The default value is
      <literal>yes</literal>, indicating</tt><tt><br>
    </tt><tt> that a CDR will be generated during hangup
      logic.</para></tt><br>
    <br>
    I tried to delay the "h" extension by several seconds and I found
    out, that the CDR record is sent to the cdr backend later.
    Unfortunately, it is not modifiable from the "h" extension, because
    the cdr_object is already in the finalized table.<br>
    <br>
    Is there a way how to modify the CDR without hacking the code?<br>
    <br></div></blockquote><div><br></div></span><div>Unfortunately, no.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    How bad idea is it to comment the (it_cdr->fn_table ==
    &finalized_state_fn_table) tests in ast_cdr_setuserfield and
    ast_cdr_setvar and thus allow the "h" extension write to a finalized
    CDR?<br>
    <br></div></blockquote><div><br></div></span><div>Well... I'm not sure :-)<br><br></div><div>As the guy who signed himself up for the dubious honour of porting the CDR code to Asterisk 13 - and trying to figure out a consistent way to make it work - I err'd on the side of extreme caution. That is, if someone could make a mess of things, I should probably try to keep it from happening.<br><br></div><div>A CDR can be finalized in a variety of ways:<br></div><div> - Due to someone leaving a bridge<br></div><div> - Due to a channel being hung up<br></div><div> - Due to the CDR being forked<br><br></div><div>Of those, modifying values is generally dangerous only in the "fork" scenario, as it may result in a CDR that a user 'ended' being modified. This is a concern when, as updating a value on a CDR walks the entire chain of CDRs, for all CDRs related to the channel:<br><span style="font-family:monospace,monospace"><br>    for (; (cdr = ao2_iterator_next(it_cdrs)); ao2_unlock(cdr), ao2_cleanup(cdr)) {<br>        ao2_lock(cdr);<br>        for (it_cdr = cdr; it_cdr; it_cdr = it_cdr->next) {<br>            struct varshead *headp = NULL;<br><br>            if (it_cdr->fn_table == &finalized_state_fn_table) {<br>                continue;<br>            }<br>            if (!strcasecmp(channel_name, it_cdr->party_a.snapshot->name<wbr>)) {<br>                headp = &it_cdr->party_a.variables;<br>            } else if (it_cdr->party_b.snapshot<br>                && !strcasecmp(channel_name, it_cdr->party_b.snapshot->name<wbr>)) {<br>                headp = &it_cdr->party_b.variables;<br>            }<br>            if (headp) {<br>                set_variable(headp, name, value);<br>            }<br>        }<br>    }<br>    ao2_iterator_destroy(it_cdrs);</span><br><br></div><div>Currently, the fact that the CDR is in the finalized state is what prevents that value from being updated on CDRs that are effectively "closed."<br></div><div><br></div><div>Now, all of that being said: this is one of those cases where the current behaviour - which is handling an extreme edge case - feels worse than ignoring that edge case. It's not like we let folks update "core" CDR values in any case, so you aren't in any danger of changing the billsec on a forked CDR. The worst that happens is you update the userfield on forked & closed CDRs when you didn't think it would update, in which case I suppose you could just use another field. Or read it first and append it from the dialplan.<br><br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Is there any chance the feature was left out by an accident and if
    so, is there a plan to add it again?<br>
    <br>
    <br>
    My extensions.conf: <br><span>
    <tt>exten => h,1,NoOp(${CDR(userfield)})</tt><tt><br>
    </tt><tt>exten => h,n,Set(CDR(userfield)=changed<wbr>)</tt><tt><br>
    </tt><tt>exten => h,n,NoOp(${CDR(userfield)})</tt><tt><br>
    </tt></span><tt>exten => h,n,System(sleep 5)</tt><span><tt><br>
    </tt><tt>exten => h,n,NoOp(${CDR(userfield)})</tt><tt><br>
    </tt></span><span><tt>exten => 10,1,Set(CDR(userfield)=empty) </tt><tt><br>
    </tt><tt>exten => 10,n,Dial(SIP/10)</tt><br>
    <br></span>
    Detailed log:<br>
    <a href="http://pastebin.com/fZ9RAhL4" target="_blank">http://pastebin.com/fZ9RAhL4</a><div><div class="m_783630902595859166m_5885096454901765061h5"><br>
    <br></div></div></div></blockquote><div><br></div></span><div>I'd be fine if you'd like to open an issue for it. If you have a patch ready that modifies the behaviour, feel free to post it for review on Gerrit as well [1].<br><br>[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Code+Review" target="_blank">https://wiki.asterisk.org/wiki<wbr>/display/AST/Code+Review</a><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_783630902595859166h5"><div bgcolor="#FFFFFF" text="#000000"><div><div class="m_783630902595859166m_5885096454901765061h5">
    <br>
    <div>On 08/03/2015 04:36 PM, jg wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div><br>
      </div>
      <blockquote type="cite">I'm
        trying to migrate from Asterisk 1.8 to Asterisk 13 and can't
        figure this one out. I'm pretty sure the question has been
        already asked, but I failed to find a solution. <br>
        <br>
        Can you modify CDR values in an h-extension? <br>
        <br>
        My cdr.conf contains: <br>
        [general] <br>
        enable=yes <br>
        unanswered=yes <br>
        endbeforehexten=yes <br>
        initiatedseconds=no <br>
        batch=no <br>
        <br>
        The diaplan contains a simple "h" extension <br>
        exten => h,1,NoOp(${CDR(userfield)}) <br>
        exten => h,n,Set(CDR(userfield)=changed<wbr>) <br>
        exten => h,n,NoOp(${CDR(userfield)}) <br>
        <br>
        In the same context I execute: <br>
        exten => 10,1,Set(CDR(userfield)=empty) <br>
        exten => 10,n,Dial(SIP/10) <br>
        <br>
        The "h" extension outputs two lines with userfield set to
        "empty". I would expect the second one to be "changed". It seems
        that I can read the CDR values, but I can't change them. Is it a
        bug or a design thing? Am I missing something? <br>
      </blockquote>
      I am not working with h-extensions myself, but the docs (<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_cdr" target="_blank"></a><a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_cdr" target="_blank">https://wiki.asterisk.org/wik<wbr>i/display/AST/Asterisk+13+Conf<wbr>iguration_cdr</a>)
      say something like this:<br>
      <br>
      <table style="color:rgb(51,51,51);border-collapse:collapse;margin:0px;overflow-x:auto;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:20px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
        <tbody>
          <tr style="color:rgb(51,51,51)">
            <td style="color:rgb(51,51,51);border:1px solid rgb(221,221,221);padding:7px 10px;vertical-align:top;text-align:left">
              <p style="margin:0px;padding:0px;color:rgb(51,51,51);background-color:transparent"><a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_cdr#Asterisk13Configuration_cdr-general_endbeforehexten" style="color:rgb(25,46,132);text-decoration:none" target="_blank"><code style="font-family:monospace">endbeforehexten</code></a></p>
            </td>
            <td style="color:rgb(51,51,51);border:1px solid rgb(221,221,221);padding:7px 10px;vertical-align:top;text-align:left">
              <p style="margin:0px;padding:0px;color:rgb(51,51,51);background-color:transparent"><code style="font-family:monospace">Boolean</code></p>
            </td>
            <td style="color:rgb(51,51,51);border:1px solid rgb(221,221,221);padding:7px 10px;vertical-align:top;text-align:left">
              <p style="margin:0px;padding:0px;color:rgb(51,51,51);background-color:transparent"><code style="font-family:monospace">1</code></p>
            </td>
            <td style="color:rgb(51,51,51);border:1px solid rgb(221,221,221);padding:7px 10px;vertical-align:top;text-align:left">
              <p style="margin:0px;padding:0px;color:rgb(51,51,51);background-color:transparent"><code style="font-family:monospace">false</code></p>
            </td>
            <td style="color:rgb(51,51,51);border:1px solid rgb(221,221,221);padding:7px 10px;vertical-align:top;text-align:left">
              <p style="margin:0px;padding:0px;color:rgb(51,51,51);background-color:transparent">Don't produce CDRs
                while executing hangup logic</p>
            </td>
          </tr>
        </tbody>
      </table>
      <br>
      This would indicate that at least writing is disabled.<br>
      <br>
      jg<br>
      <br>
      <fieldset></fieldset>
      <br>
    </blockquote>
    <br>
  </div></div></div>

<br></div></div><span>--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
               <a href="http://www.asterisk.org/hello" rel="noreferrer" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailm<wbr>an/listinfo/asterisk-users</a><br></span></blockquote></div><span class="m_783630902595859166HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_783630902595859166m_5885096454901765061gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</font></span></div></div>
<br>--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
               <a href="http://www.asterisk.org/hello" rel="noreferrer" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailm<wbr>an/listinfo/asterisk-users</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>