[OpenSIPS-Users] multi-leg accounting in case of redirect
Ruchir
ruchir.lists at gmail.com
Thu Aug 21 08:02:51 CEST 2008
I'm populating it from onreply route. Below is my onreply route.
if($hdr(Diversion)!=null)
{
avp_delete("$avp(s:src_user_reply)");
$avp(s:src_user_reply) = $hdr(Diversion);
xlog("Client call forwarding to $avp(s:src_user_reply)\n ");
avp_subst("$avp(s:src_user_reply)",
"/(.*)<sip:(.*)@(.*)>;reason=(.*)/\4/");
$avp(s:src) = $rU;
switch($avp(s:src_user_reply))
{
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");
}
xlog("FORWARDING REASON: $avp(s:call_type) \n ");
}
On Tue, Aug 19, 2008 at 5:49 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> Hi Ruchir,
>
> I see in failure route you are using route[1] to do the job if a redirect
> happens. How exactly are you populating in the second set of caller/callee
> in route[1] ?
>
> Regards,
> Bogdan
>
> Ruchir wrote:
>
>> 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 <mailto: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>
>> <mailto: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>>
>> <mailto: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>>>
>> <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
>> <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>>>
>> <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
>> <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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080821/d73fadb0/attachment-0001.htm
More information about the Users
mailing list