<div dir="ltr">Here it is. route[1] is relay route.<br><br><blockquote>failure_route[1]<br>{<br> xlog("------- failure_route[1] ----- \n ");<br> t_on_branch("1"); <br><br> if(t_check_status("302"))<br>
{<br> xlog("------- t_check_status(302) ----- \n ");<br> <br> get_redirects("4:1","Redirected");<br> route(1);<br> } <br><br> if( t_check_status("486") && isbflagset(17))<br>
{<br> xlog("------- t_check_status(486) -- isflagset(17) ----- \n ");<br> end_media_session();<br> #resetbflag(6);<br> append_hf("SRC-USER: $rU\r\n");<br> if(avp_pushto("$ruri","$avp(s:cfwdbusy)"))<br>
{<br> append_hf("SRC-CALL-TYPE: cfwdbusy\r\n");<br> append_hf("CFWD: YES\r\n");<br> avp_delete("$avp(s:cfwdbusy)");<br> resetbflag(17);<br>
append_branch();<br> append_hf("PREV_STATUS: $T_reply_code\r\n");<br> #route(5);<br> $avp(i:120) = $avp(s:inv_timeout);<br> route(1);<br> exit;<br>
}<br> } <br> <br> if( t_check_status("408") && isbflagset(18))<br> {<br> xlog("------- t_check_status(408) -- isflagset(18) ----- \n ");<br><br> end_media_session();<br>
#resetbflag(6);<br> append_hf("SRC-USER: $rU\r\n");<br><br> if(avp_pushto("$ruri","$avp(s:cfwdnoanswer)"))<br> {<br> append_hf("SRC-CALL-TYPE: cfwdnoanswer\r\n");<br>
append_hf("CFWD: YES\r\n");<br> avp_delete("$avp(s:cfwdnoanswer)");<br> resetbflag(18);<br> append_branch();<br> append_hf("PREV_STATUS: $T_reply_code\r\n");<br>
route(5);<br> $avp(i:120) = $avp(s:inv_timeout);<br> route(1);<br> exit;<br><br> }<br> else if(isbflagset(4))<br> {<br> xlog("------- t_check_status(408) -- Voicemail ----- \n ");<br>
if(!t_write_unix("/tmp/sems_sock","voicemail/voicemail_headers"))<br> {<br> xlog("----------------- Error--- not communicating----------- \n ");<br>
exit;<br> }<br> exit;<br> }<br> }<br><br> <br><br>}<br></blockquote><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 2:07 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Could you post your complete failure route (if not a secret;) ) ?<br>
<br>
Regards,<br>
Bogdan<br>
<br>
<br>
Ruchir wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
Yes. I've used uac_redirect module and I'm using get_redirects function to load the contacts to redirect to.<br>
<br></div><div><div></div><div class="Wj3C7c">
On Sun, Aug 10, 2008 at 4:02 PM, Bogdan-Andrei Iancu <<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> <mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>>> wrote:<br>
<br>
Hi Ruchir,<br>
<br>
Are you using uac_redirect module to process the 3xx replies on<br>
server?<br>
<br>
Regards,<br>
Bogdan<br>
<br>
Ruchir wrote:<br>
<br>
Yes. I've set unconditional forwarding in linksys pap2. So it<br>
sends "302 temporarily moved".<br>
<br>
On Sat, Aug 9, 2008 at 4:36 PM, Bogdan-Andrei Iancu<br>
<<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> <mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>><br>
<mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a><br>
<mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>>>> wrote:<br>
<br>
Hi Ruchir,<br>
<br>
The redirect on the phone is done via the 3xx replies?<br>
<br>
Regards,<br>
Bogdan<br>
<br>
Ruchir wrote:<br>
<br>
I've set avp and radius_extra param properly. If I<br>
handle call<br>
forwarding from server side, everything works fine. I<br>
get leg<br>
source, destination, forward reason, etc. perfectly. The<br>
problem is there only when I do call forwarding from phone.<br>
<br>
On Fri, Aug 8, 2008 at 8:08 PM, Pablo Hernan Saro<br>
<<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a> <mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a>><br>
<mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a> <mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a>>><br>
<mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a><br>
<mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a>> <mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a><br>
<mailto:<a href="mailto:pablosaro@gmail.com" target="_blank">pablosaro@gmail.com</a>>>>> wrote:<br>
<br>
I believe that it's not about how OpenSER or OpenSIPS<br>
implements<br>
multi-leg accounting, it's about how you do.<br>
Particularly how you set up two important parameters for<br>
the acc<br>
module: multi_leg_info and db_extra. In my case, I<br>
set up<br>
one avp<br>
for source leg, another for destination leg and two avps<br>
for extra<br>
information: the state of the call and a<br>
classification of<br>
the dst.<br>
The "state of the call", for me, means when it's a<br>
call, a<br>
fw or<br>
whatever; while the "classification of the dst"<br>
means if dst is<br>
national, long distance, international.<br>
So, you have to set up avps as the information you<br>
need and<br>
make<br>
sure to set it to proper values before the acc module<br>
writes the<br>
row in your db.<br>
BTW, take care of using Diversion header... It's a draft<br>
from 2004<br>
and it's expired. Not all UAC/UAS has this implemented.<br>
I hope it helps.<br>
Cheers<br>
<br>
Pablo<br>
<br>
<br>
On Fri, Aug 8, 2008 at 4:05 AM, Ruchir<br>
<<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a> <mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a>><br>
<mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a> <mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a>>><br>
<mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a><br>
<mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a>><br>
<mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a><br>
<mailto:<a href="mailto:ruchir.lists@gmail.com" target="_blank">ruchir.lists@gmail.com</a>>>>> wrote:<br>
<br>
I'm using uac_redirect module to handle redirect<br>
from<br>
UA and<br>
doing accounting from openser. Redirect works<br>
fine so<br>
as cdr<br>
but I'm not able to store CDR records for multi-leg<br>
accounting<br>
properly.<br>
<br>
I have set onreply avp by<br>
<br>
modparam("tm", "onreply_avp_mode", 1)<br>
<br>
<br>
I've set following in onreply route<br>
<br>
<br>
if($hdr(Diversion)!=null)<br>
{<br>
avp_delete("$avp(s:src_call_type)");<br>
$avp(s:src_call_type) = $hdr(Diversion);<br>
<br>
xlog("Client call forwarding to<br>
$avp(s:src_user_reply)\n ");<br>
<br>
avp_subst("$avp(s:src_user_reply)",<br>
"/(.*)<sip:(.*)@(.*)>;reason=(.*)/\4/");<br>
<br>
<br>
<br>
switch($avp(s:src_call_type))<br>
{<br>
case "unconditional":<br>
$avp(s:call_type) = "cwfd";<br>
break;<br>
case "user-busy":<br>
$avp(s:call_type) = "cwfdbusy";<br>
break;<br>
case "no-answer":<br>
$avp(s:call_type) = "cwfdnoanswer";<br>
break;<br>
default:<br>
log("no forwarding\n");<br>
}<br>
<br>
}<br>
<br>
But the problem is that records are not<br>
generated the<br>
way we<br>
expect and the way it works in normal forwarding<br>
using<br>
usr_preferences. For example call is forwarded<br>
from one<br>
user<br>
to another, the first leg of the call should be<br>
logged<br>
as it<br>
should normally be($fU in leg source, $rU in leg<br>
destination &<br>
calltype=call) and in next cdr log, it should<br>
log with<br>
forwarding details(Forwarding user in leg<br>
source, forwarded<br>
user in leg destination & calltype=cfwd). But it<br>
actually<br>
generates 5 records(1 failed invite, 2 ok<br>
invites & 2 byes,<br>
instead of 2 invites & 2 byes) of the call. Also<br>
as we set<br>
calltype and leg source in onreply route, it'll<br>
store that<br>
date for the first leg of the CDR which should<br>
not happen.<br>
<br>
Is the same limitation is there in OpenSIPS or<br>
it has<br>
better<br>
uac_redirect module?<br>
<br>
I'll consider switching to OpenSIPS if it solves<br>
this<br>
issue.<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>>><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>>>><br>
<br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>>><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div>