Re: [Serusers] Call forward on no answer and busy failing

Think of a branch as something that can be used and then must be discarded, so in failure route you must append a new branch. This is how SER keeps track of status for each. The appending of branches works a bit strange unless you know how it works (a bit simplified): Each time you call append_branch(), a copy of the whole message (i.e. transaction state) is copied and everything in there is inaccessible from ser.cfg. So, you need to change the request-uri before you append a branch. In regular route, if you want to parallel branch, you thus need to change the request-uri to where you want to branch, append_branch() and then change the request-uri to another destination. When the script hits t_reply(), two INVITEs will be sent. In failure route, the current transaction has failed and can thus not be forwarded again. You change the request-uri and then append_branch(). Now, as there is one failed and one new, only one will be sent when you hit t_reply(). If you want to add more parallel branches, you do the same: change request-uri, then append_branch(). Now you have three, where one has failed. So, after calling append_branch(), you have spun off a new branch,and are back to the original branch, regardless of where you are in the script. Note that on_branch route in SER 2.0 is called once for each parallel branch, so you can do extra stuff there (but not change everything). g-) Ranganath B wrote: Hi Greger, Thanks for replying and your help. I was able to solve the issue. But now the call forward on no answer and busy are failing due to a different reason. I get the following error message on the /var/log/messages May 17 15:22:54 localhost /usr/local/sbin/ser[28719]: ERROR: t_forward_nonack: no branched for forwarding May 17 15:22:54 localhost /usr/local/sbin/ser[28719]: ERROR: w_t_relay (failure mode): forwarding failed May 17 15:22:54 localhost /usr/local/sbin/ser[28719]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL) I observed in one of the mailing list that the solution for this problem is to change the uri to the new, then append_branch. Any suggestions on how to do this? Please point me to the change that is needed to solve this issue. Here's the chunk of code for your reference from my ser.cfg: # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { route(4); route(5); break; }; if (avp_db_load("$ruri/username", "s:callfwd")) { setflag(22); avp_pushto("$ruri", "s:callfwd"); route(6); break; }; if (!lookup("location")) { if (uri=~"^sip:[0-9]{10}@") { route(4); route(5); break; }; sl_send_reply("404", "User Not Found"); break; }; if (avp_db_load("$ruri/username", "s:fwdbusy")) { if (!avp_check("s:fwdbusy", "eq/$ruri/i")) { setflag(26); }; }; if (avp_db_load("$ruri/username", "s:fwdnoanswer")) { if (!avp_check("s:fwdnoanswer", "eq/$ruri/i")) { setflag(27); }; }; t_on_failure("1"); route(4); route(1); } route[4] { # ----------------------------------------------------------------- # NAT Traversal Section # ----------------------------------------------------------------- if (isflagset(6) || isflagset(7)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; } route[5] { # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- rewritehost("192.0.2.245"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); t_on_failure("1"); route(1); } route[6] { # ------------------------------------------------------------------------ # Call Forwarding Reply Route Handler # # This must be done as a route block because sl_send_reply() cannot be # called from the failure_route block # ------------------------------------------------------------------------ if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; lookup("aliases"); if (!is_uri_host_local()) { if (!isflagset(22)) { append_branch(); }; route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { route(4); route(5); break; }; if (!lookup("location")) { if (uri=~"^sip:[0-9]{10}@") { route(4); route(1); break; }; sl_send_reply("404", "User Not Found"); }; route(4); route(1); } onreply_route[1] { if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { if (!search("^Content-Length:[ ]*0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; } failure_route[1] { if (t_check_status("487")) { break; }; if (isflagset(26) && t_check_status("486")) { if (avp_pushto("$ruri", "s:fwdbusy")) { avp_delete("s:fwdbusy"); resetflag(26); route(6); break; }; }; if (isflagset(27) && t_check_status("408")) { if (avp_pushto("$ruri", "s:fwdnoanswer")) { avp_delete("s:fwdnoanswer"); resetflag(27); route(6); break; }; }; end_media_session(); } Thanks again, Ranganath B On 5/17/07, Greger Viken Teigre <greger(a)teigre.com > wrote: