Can anyone give me suggestion for storing and manipulating multi-leg accounting records?
On Thu, Jun 12, 2008 at 2:03 PM, Ruchir <[EMAIL PROTECTED]> wrote: > Any suggestions from experts? :) > > > On Thu, Jun 12, 2008 at 1:27 PM, Bogdan-Andrei Iancu < > [EMAIL PROTECTED]> wrote: > >> Hi Ruchir, >> >> with multi-leg accounting, you can match all the records belonging to the >> same call by using call_id, to_tag and from_tag. How you format and store >> the CDRS is your choice :). >> >> Regards, >> Bogdan >> >> Ruchir wrote: >> >>> Yeah I just noticed that INVITE & BYE time difference gives accurate >>> duration of the call. We can drop using ACK now :) >>> Are there any standards for storing records for multi-leg accounting? I >>> tried to find it but didn't get success. Can you please suggest which way we >>> should store CDR to identify the records properly? >>> >>> On Wed, Jun 11, 2008 at 8:10 PM, Bogdan-Andrei Iancu < >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> Well, depends of how you process the ACC infor for building CDRs - >>> that was more an opinion/recommendation than a must :). >>> >>> Regarding the ACK and call duration -- actually the media starts >>> to flow immediately after the 200OK (when the INVITE log is >>> generated) - most of the devices wait for ACK as confirmation that >>> everything is ok and not for starting the call. >>> >>> Regards, >>> Bogdan >>> >>> >>> Ruchir wrote: >>> >>> I was thinking it should generate 9 records so it'll show up >>> as 3 different calls so we can show CDR properly in web >>> interface as well as calculate billing for users as the user >>> who forwarded the call should be charged for the call. Also if >>> we get INVITE only then we may not get accurate duration of >>> call as actual duration starts when callee accepts the call >>> and ACK is received. Is this scenario wrong? >>> >>> On Wed, Jun 11, 2008 at 5:19 PM, Bogdan-Andrei Iancu >>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>> wrote: >>> >>> Perfect ! >>> >>> regarding multi-leg calls - first of all, there is no need to >>> enabled in for ACK and BYEs - make no sense. usually you >>> want to >>> see all the legs of the call for INVITE. >>> >>> Now, about how many records you get - depends on how many AVPs >>> (used of multi-leg acc) you set from the script. If you 3 >>> INVITEs, >>> means you add 3 values for at least of the AVPs . >>> >>> Regards, >>> Bogdan >>> >>> Ruchir wrote: >>> >>> I had put setflag after t_newtran() previously. Now I >>> moved it >>> before t_newtran() and got records for INVITE, ACK & >>> BYE for >>> normal call perfectly. :) >>> Then I tested for call forwarding scenario. In this case >>> forwarding is set as below: >>> 90004 -> 90001 -> 90003. >>> >>> I called 90004 from 90002 and I got 7 records in acc >>> table. 3 >>> INVITEs, 3 BYEs and only single ACK. Shouldn't it log 3 ACK >>> messages? >>> >>> >>> On Wed, Jun 11, 2008 at 4:32 PM, Bogdan-Andrei Iancu >>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>>> wrote: >>> >>> Be sure you set the accounting flag before any >>> t_relay() or >>> t_newtran() for the INVITE. To be sure, try to use >>> log/xlog >>> to put >>> some debugs in your script and check if the flag is >>> really set >>> before t_relay(). >>> >>> >>> Regards, >>> Bogdan >>> >>> Ruchir Lists wrote: >>> >>> I configured simple acc module to store records >>> in acc >>> table, >>> set proper flags. Then tried to call number >>> directly(not with >>> forwarding) but still I get only BYE record. Any >>> suggestion? >>> >>> On Wed, Jun 11, 2008 at 2:43 PM, Bogdan-Andrei Iancu >>> <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>>>> wrote: >>> >>> Hi Ruchir, >>> >>> There are two aspects here: >>> 1) making acc to work - setting the flags and >>> getting the ACC >>> records >>> 2) enabling multi-leg account and putting more >>> info into the >>> accounted info >>> >>> First you should to solve (1) - just getting a >>> simple ACC >>> record >>> for INVITEs and BYEs (no multi leg >>> accounting) - it this >>> working >>> for you or you get only BYE acc? >>> >>> Regards, >>> Bogdan >>> >>> Ruchir Lists wrote: >>> >>> Hi All, >>> >>> I'm trying to configure OpenSER with >>> multi-leg >>> accounting. I'm >>> using OpenSER 1.2 & radius. I'm using >>> acc_radius >>> table for >>> writing cdr records. I've searched through >>> several articles >>> and mailing list posts about configuring >>> multi-leg >>> accounting >>> and everywhere they talk about setting up >>> multi-leg-info >>> parameter of acc module to configure leg >>> source & >>> destination >>> and setting up accounting flag. But this >>> is not >>> working for >>> me. I get only BYE record in table if I >>> use this >>> way to >>> write >>> multiple records for one call in call >>> forwarding >>> scenario. I >>> managed to get multiple records by calling >>> acc_rad_request on >>> INVITE, ACK, BYE & CANCEL. For instance, >>> I have >>> 4 users; >>> 90001, 90002, 90003, 90004. The call >>> forwarding is >>> setup as below: >>> 90004 -> 90001 -> 90003. >>> >>> I dial 90004 from 90002 user and it >>> forwards the >>> call >>> to 90001 >>> & then 90003 and they're connected properlry. >>> However I >>> don't >>> get leg source/destination properly and >>> also I >>> get 7-8 bye >>> records for this call. Can anyone guide >>> me in right >>> direction >>> if I'm doing anything wrong. >>> >>> Regards, >>> Ruchir >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.openser.org >>> <mailto:Users@lists.openser.org> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org>> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org>>> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org>> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org> >>> <mailto:Users@lists.openser.org >>> <mailto:Users@lists.openser.org>>>> >>> >>> >>> >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
