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

[Ruchir]

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>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>> 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>> 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>
>>        http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> 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/4cc8bc43/attachment.htm