[OpenSIPS-Users] multi-leg accounting in case of redirect
Rosario Pingaro
rpingar at convergenze.it
Wed Aug 13 09:57:46 CEST 2008
maybe you can post this on the kamailio list,
then you should receive an answer.
Here seems nobody take care about it.
Regards
Ros
----- Original Message -----
From: Ruchir
To: Bogdan-Andrei Iancu
Cc: users at lists.opensips.org
Sent: Monday, August 11, 2008 1:03 PM
Subject: Re: [OpenSIPS-Users] multi-leg accounting in case of redirect
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
------------------------------------------------------------------------------
_______________________________________________
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/20080813/338e554f/attachment-0001.htm
More information about the Users
mailing list