[OpenSIPS-Users] multi-leg accounting in case of redirect
Ruchir
ruchir.lists at gmail.com
Mon Aug 11 13:03:51 CEST 2008
Here it is. route[1] is relay route.
failure_route[1]
{
xlog("------- failure_route[1] ----- \n ");
t_on_branch("1");
if(t_check_status("302"))
{
xlog("------- t_check_status(302) ----- \n ");
get_redirects("4:1","Redirected");
route(1);
}
if( t_check_status("486") && isbflagset(17))
{
xlog("------- t_check_status(486) -- isflagset(17) ----- \n ");
end_media_session();
#resetbflag(6);
append_hf("SRC-USER: $rU\r\n");
if(avp_pushto("$ruri","$avp(s:cfwdbusy)"))
{
append_hf("SRC-CALL-TYPE: cfwdbusy\r\n");
append_hf("CFWD: YES\r\n");
avp_delete("$avp(s:cfwdbusy)");
resetbflag(17);
append_branch();
append_hf("PREV_STATUS: $T_reply_code\r\n");
#route(5);
$avp(i:120) = $avp(s:inv_timeout);
route(1);
exit;
}
}
if( t_check_status("408") && isbflagset(18))
{
xlog("------- t_check_status(408) -- isflagset(18) ----- \n ");
end_media_session();
#resetbflag(6);
append_hf("SRC-USER: $rU\r\n");
if(avp_pushto("$ruri","$avp(s:cfwdnoanswer)"))
{
append_hf("SRC-CALL-TYPE: cfwdnoanswer\r\n");
append_hf("CFWD: YES\r\n");
avp_delete("$avp(s:cfwdnoanswer)");
resetbflag(18);
append_branch();
append_hf("PREV_STATUS: $T_reply_code\r\n");
route(5);
$avp(i:120) = $avp(s:inv_timeout);
route(1);
exit;
}
else if(isbflagset(4))
{
xlog("------- t_check_status(408) -- Voicemail ----- \n ");
if(!t_write_unix("/tmp/sems_sock","voicemail/voicemail_headers"))
{
xlog("----------------- Error--- not
communicating----------- \n ");
exit;
}
exit;
}
}
}
On Mon, Aug 11, 2008 at 2:07 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> Could you post your complete failure route (if not a secret;) ) ?
>
> Regards,
> Bogdan
>
>
> Ruchir wrote:
>
>> 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 <mailto: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>
>> <mailto: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>>
>> <mailto: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>>
>> <mailto: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>>
>> <mailto: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>
>> <mailto: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/20080811/50b769ad/attachment-0001.htm
More information about the Users
mailing list