[OpenSIPS-Users] multi-leg accounting in case of redirect

[Ruchir]

Yes. I've used uac_redirect module and I'm using  get_redirects function to
load the contacts to redirect to.

On Sun, Aug 10, 2008 at 4:02 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi Ruchir,
>
> Are you using uac_redirect module to process the 3xx replies on server?
>
> Regards,
> Bogdan
>
> Ruchir wrote:
>
>> Yes. I've set unconditional forwarding in linksys pap2. So it sends "302
>> temporarily moved".
>>
>> On Sat, Aug 9, 2008 at 4:36 PM, Bogdan-Andrei Iancu <
>> bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>>
>>    Hi Ruchir,
>>
>>    The redirect on the phone is done via the 3xx replies?
>>
>>    Regards,
>>    Bogdan
>>
>>    Ruchir wrote:
>>
>>        I've set avp and radius_extra param properly. If I handle call
>>        forwarding from server side, everything works fine. I get leg
>>        source, destination, forward reason, etc. perfectly. The
>>        problem is there only when I do call forwarding from phone.
>>
>>        On Fri, Aug 8, 2008 at 8:08 PM, Pablo Hernan Saro
>>        <pablosaro at gmail.com <mailto:pablosaro at gmail.com>
>>        <mailto:pablosaro at gmail.com <mailto:pablosaro at gmail.com>>> wrote:
>>
>>           I believe that it's not about how OpenSER or OpenSIPS
>>        implements
>>           multi-leg accounting, it's about how you do.
>>           Particularly how you set up two important parameters for
>>        the acc
>>           module: multi_leg_info and db_extra. In my case, I set up
>>        one avp
>>           for source leg, another for destination leg and two avps
>>        for extra
>>           information: the state of the call and a classification of
>>        the dst.
>>           The "state of the call", for me, means when it's a call, a
>>        fw or
>>           whatever; while the "classification of the dst" means if dst is
>>           national, long distance, international.
>>           So, you have to set up avps as the information you need and
>>        make
>>           sure to set it to proper values before the acc module
>>        writes the
>>           row in your db.
>>           BTW, take care of using Diversion header... It's a draft
>>        from 2004
>>           and it's expired. Not all UAC/UAS has this implemented.
>>           I hope it helps.
>>           Cheers
>>
>>           Pablo
>>
>>
>>           On Fri, Aug 8, 2008 at 4:05 AM, Ruchir
>>        <ruchir.lists at gmail.com <mailto:ruchir.lists at gmail.com>
>>           <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>> wrote:
>>
>>               I'm using uac_redirect module to handle redirect from
>>        UA and
>>               doing accounting from openser. Redirect works fine so
>>        as cdr
>>               but I'm not able to store CDR records for multi-leg
>>        accounting
>>               properly.
>>
>>               I have set onreply avp by
>>
>>                   modparam("tm", "onreply_avp_mode", 1)
>>
>>
>>               I've set following in onreply route
>>
>>
>>                   if($hdr(Diversion)!=null)
>>                   {
>>                   avp_delete("$avp(s:src_call_type)");
>>                   $avp(s:src_call_type) = $hdr(Diversion);
>>
>>                   xlog("Client call forwarding to
>>        $avp(s:src_user_reply)\n ");
>>
>>                   avp_subst("$avp(s:src_user_reply)",
>>                   "/(.*)<sip:(.*)@(.*)>;reason=(.*)/\4/");
>>
>>
>>
>>                   switch($avp(s:src_call_type))
>>                   {
>>                   case "unconditional":
>>                   $avp(s:call_type) = "cwfd";
>>                   break;
>>                   case "user-busy":
>>                   $avp(s:call_type) = "cwfdbusy";
>>                   break;
>>                   case "no-answer":
>>                   $avp(s:call_type) = "cwfdnoanswer";
>>                   break;
>>                   default:
>>                   log("no forwarding\n");
>>                   }
>>
>>                   }
>>
>>               But the problem is that records are not generated the
>>        way we
>>               expect and the way it works in normal forwarding using
>>               usr_preferences. For example call is forwarded from one
>>        user
>>               to another, the first leg of the call should be logged
>>        as it
>>               should normally be($fU in leg source, $rU in leg
>>        destination &
>>               calltype=call) and in next cdr log, it should log with
>>               forwarding details(Forwarding user in leg source, forwarded
>>               user in leg destination & calltype=cfwd). But it actually
>>               generates 5 records(1 failed invite, 2 ok invites & 2 byes,
>>               instead of 2 invites & 2 byes) of the call. Also as we set
>>               calltype and leg source in onreply route, it'll store that
>>               date for the first leg of the CDR which should not happen.
>>
>>               Is the same limitation is there in OpenSIPS or it has
>>        better
>>               uac_redirect module?
>>
>>               I'll consider switching to OpenSIPS if it solves this
>>        issue.
>>
>>               _______________________________________________
>>               Users mailing list
>>               Users at lists.opensips.org
>>        <mailto:Users at lists.opensips.org>
>>        <mailto:Users at lists.opensips.org
>>        <mailto:Users at lists.opensips.org>>
>>
>>               http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>
>>
>>        _______________________________________________
>>        Users mailing list
>>        Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>        http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080810/d2ece75d/attachment-0001.htm