[OpenSIPS-Users] multi-leg accounting in case of redirect
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Aug 21 12:20:01 CEST 2008
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.
>
>
>
More information about the Users
mailing list