[OpenSIPS-Users] multi-leg accounting in case of redirect
Ruchir
ruchir.lists at gmail.com
Thu Aug 21 13:29:58 CEST 2008
Oh I see. Then how we can get correct leg source, leg destination &
forwarding reason?
On Thu, Aug 21, 2008 at 3:50 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> Hi Ruchir,
>
> I see in the onreply_route you get the diversion type (src_user_reply).
> Also you try to populate the src avp, but as in onreply_route a reply is
> processed, the $rU will not work - there is no RURI in a reply.
>
> Regards,
> Bogdan
>
> Ruchir wrote:
>
>> 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 <mailto: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>
>> <mailto: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>>
>> <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,
>>
>> 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>>>
>> <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
>> <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>>>>
>> <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
>> <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>>>>
>> <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
>> <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/8edde6e3/attachment-0001.htm
More information about the Users
mailing list