I am wondering if we can ever achieve nano second precision for accounting. Can 
we?

Adrian

On 27 Apr 2014, at 13:17, Maciej Bylica <mb...@gazeta.pl> wrote:

> Hello,
> 
> ad1) I am just wondering why get_timestamp must be fired before has_totag 
> part of the script?
> I've found some threads on discussion group describing the same thing, but 
> without explaination.
> ad2) i have set following rule:
>         if (is_method("INVITE") && t_check_status("200") ) {
>                 xlog("L_INFO","[INFO] Inside.... okay -> $var(okay)");
>                 get_timestamp($avp(sec),$avp(usec));
>         }
> 
> then i think reINVITE/OK/ transaction will generate new timestamps, which is 
> wrong.
> Is there any dialog variable that could be checked and then set inside the { 
> } to last more than just one transaction.
> Possible usage inside onreply_route...
> 
> 
>         if (is_method("INVITE") && (t_check_status("200")) && 
> ($var(okay)==NULL)) {
>                 $var(okay)=1;
>                 xlog("L_INFO","[INFO] Inside .... okay -> $var(okay)");
>                 get_timestamp($avp(sec),$avp(usec));
>         }
> 
> Thanks
> Mac. 
> 
> 
> 
> 
> 2014-04-15 17:04 GMT+02:00 Maciej Bylica <mb...@gazeta.pl>:
> Hello,
> 
> It works, but:
> 1) get_timestamp doesnt work inside has_totag section           
>  if (has_totag()) {   
>     if (loose_route()) {
>           if (is_method("BYE")) {
>               get_timestamp($avp(secbye),$avp(usecbye));
>               .....
>               .....
> but works if called before that section
> 
> 2) because i need to count duration, i should rather place it inside 
> onreply_route
>          if (t_check_status("200")) {
>                 get_timestamp($avp(sec),$avp(usec));
>         }
>  but the question is how it will behave in case of reINVITE is triggered from 
> the originating side.
> I think $avp(sec),$avp(usec) will be overwritten.
> So maybe wise idea will be to set some flag in first 200 message and make 
> another statement like if ((t_check_status("200")) && !(isflagset(XX))) 
> 
> What do you think about p1 and p2?
> 
> Thanks
> Mac
> 
> 
> 
> 2014-04-14 12:56 GMT+02:00 Maciej Bylica <mb...@gazeta.pl>:
> 
> Hi Vlad,
> 
> Thanks for reply.
> I am using OpenSIPS (1.9.1-notls (x86_64/linux)) so get_timestamp is 
> available there.
> Let me check this.
> 
> Regards,
> Mac
> 
> 
> 2014-04-14 10:57 GMT+02:00 Vlad Paiu <vladp...@opensips.org>:
> 
> Hello,
> 
> Which OpenSIPS version are you using ?
> You could use get_timestamp [1] from the Core to get the current second and 
> microsecond,
> and set the two variables at INVITE time, and set them as db_extra [2] .
> 
> Then, at BYE time call again the get_timestamp function, store them in some 
> AVPs and set those AVPs in [3]. This way you should get both the INVITE and 
> BYE timestamps with microseconds precision in the CDR record.
> 
> [1] http://www.opensips.org/Documentation/Script-CoreFunctions-1-10#toc18
> [2] http://www.opensips.org/html/docs/modules/1.10.x/acc.html#id295028
> [3] http://www.opensips.org/html/docs/modules/1.10.x/acc.html#id295056
> 
> Best Regards,
> Vlad Paiu
> OpenSIPS Developer
> http://www.opensips-solutions.com 
> On 12.04.2014 23:44, Maciej Bylica wrote:
>> Hello Ryan,
>> 
>> I am using dialog accounting, so each row is fully qualified cdr record, not 
>> only single transaction of a call.
>> Couldn't i just use two extra db variables which will gather the $time 
>> inside INVITE {} and BYE {}?
>> 
>> Thanks,
>> Mac
>> 
>> 
>> 2014-04-12 6:39 GMT+02:00 Ryan Mitchell <r...@tcl.net>:
>> Hello Mac,
>> 
>> Each row in the acc table is for a transaction.  To make a proper CDR out of 
>> the data, you have to combine rows to find the start and end of the call.  
>> That can be harder than it sounds, especially with forking (parallel, or the 
>> more common case of serial forking when you are LCR routing or simply 
>> sending calls to alt destinations after a timeout).  I wrote scripts that 
>> implement a simple dialog state machine to make sense of all the distinct 
>> legs of a call, though there should be an easier way with the auto-cdr / 
>> multi call-legs accounting feature of the acc module (anyone comment on this 
>> please?).
>> 
>> The time field in the acc table will be the timestamp of the response for 
>> the given transaction.  If you assign an extra field for another timestamp, 
>> it will depend on where you assign that var in your script.  In my case I 
>> assign it in the main routing section so the timestamp indicates the start 
>> of the transaction.
>> 
>> best regards,
>> Ryan
>> 
>> 
>> 
>> On Fri, Apr 11, 2014 at 10:06 AM, Maciej Bylica <mb...@gazeta.pl> wrote:
>> Ryan,
>> 
>> One more question.
>> Currently i have some db extra attrs setup. My acc table looks like 
>> following:
>> +------------+------------------+------+-----+---------+----------------+
>> | Field      | Type             | Null | Key | Default | Extra          |
>> +------------+------------------+------+-----+---------+----------------+
>> | id         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
>> | method     | char(16)         | NO   |     |         |                |
>> | from_tag   | char(64)         | NO   |     |         |                |
>> | to_tag     | char(64)         | NO   |     |         |                |
>> | callid     | char(64)         | NO   | MUL |         |                |
>> | sip_code   | char(3)          | NO   |     |         |                |
>> | sip_reason | char(32)         | NO   |     |         |                |
>> | time       | datetime         | NO   |     | NULL    |                |
>> | duration   | int(11) unsigned | NO   |     | 0       |                |
>> | setuptime  | int(11) unsigned | NO   |     | 0       |                |
>> | SourceAddr | char(30)         | NO   |     | NULL    |                |
>> | DestAddr   | char(30)         | NO   |     | NULL    |                |
>> | Anum       | char(30)         | NO   |     | NULL    |                |
>> | Bnum_rU    | char(30)         | NO   |     | NULL    |                |
>> | Bnum_tU    | char(30)         | NO   |     | NULL    |                |
>> | created    | datetime         | YES  |     | NULL    |                |
>> +------------+------------------+------+-----+---------+----------------+
>> 
>> modparam("acc", "db_extra", "SourceAddr=$si; DestAddr=$rd; Anum=$fU; 
>> Bnum_rU=$rU; Bnum_tU=$tU")
>> 
>> Now using additional data like $time will give me the exact moment the call 
>> is ended, nothing more, am i right?
>> To have detailed call duration i need to know exact answer and disconnect 
>> timestamps.
>> 
>> Btw: i am using OpenSIPS (1.9.1-notls (x86_64/linux))
>> 
>> Thanks,
>> Mac
>> 
>> 
>> 2014-04-10 22:03 GMT+02:00 Ryan Mitchell <r...@tcl.net>:
>> Using db_extra to stuff custom data into your acc table, use the $time var 
>> with a format such as "%s.%N" or similar.
>> 
>> Or, as you suggested, do it on the database level with a trigger or 
>> auto-update column.
>> 
>> 
>> 
>> On Thu, Apr 10, 2014 at 10:01 AM, Maciej Bylica <mb...@gazeta.pl> wrote:
>> Hello
>> 
>> I just want to know how to achieve miliseconds precision for accounting 
>> module.
>> This is quite important while trying to sum up total traffic duration with 
>> the accuracy of hundred of ms.
>> 
>> As i see there is no rounding feature implemented as well, but heaving ms 
>> precision it could be done directly on DB level.
>> 
>> Could somebody give me a hand.
>> 
>> Thanks in advanced
>> Mac
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> 
>> -- 
>> Ryan Mitchell <r...@tcl.net>
>> Telecom Logic, LLC
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> 
>> -- 
>> Ryan Mitchell <r...@tcl.net>
>> Telecom Logic, LLC
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to