Not sure about the loose routing.. here is my config file..
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) dns=yes rev_dns=yes check_via=no fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/group.so" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" #loadmodule "/usr/local/lib/ser/modules/textops.so" #loadmodule "/usr/local/lib/ser/modules/vm.so"
#loadmodule "/usr/local/lib/ser/modules #loadmodule "/usr/local/lib/ser/modules #loadmodule "/usr/local/lib/ser/modules #loadmodule "/usr/local/lib/ser/modules #loadmodule "/usr/local/lib/ser/modules #loadmodule "/usr/local/lib/ser/modules
# ----------------- setting module-specific parameters ---------------
modparam("auth_db", "db_url","mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("usrloc", "db_mode", 1)
# -- acc params -- modparam("acc", "log_level", 1) # that is the flag for which we will account -- don't forget to # set the same one :-) modparam("acc", "db_flag", 1) modparam("acc", "db_url","mysql://ser:heslo@localhost/ser") modparam("acc", "db_missed_flag", 3)
modparam("tm", "fr_inv_timer", 20) modparam("group", "db_url", "mysql://ser:heslo@localhost/ser")
# ------------------------- request routing logic ------------------- # main routing logic
alias="ion.dom" alias="44.44.444.154"
route {
if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483", "Alas Too Many Hops"); break; };
setflag(1);
if (!(method=="REGISTER")) record_route(); if (loose_route()) { t_relay(); break; };
# if (!uri==myself) { # t_relay(); # break; # };
if (method == "REGISTER") { if (!save("location")) { sl_reply_error(); }; break; };
# does the user wish redirection on no availability? (i.e., is he # in the voicemail group?) -- determine it now and store it in # flag 4, before we rewrite the flag using UsrLoc if (is_user_in("Request-URI", "voicemail")) { setflag(4); };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # handle user which was not found route(4); break; };
# if user is on-line and is in voicemail group, enable redirection if (method == "INVITE" && isflagset(4)) { t_on_failure("1"); }; t_relay(); }
# ------------- handling of unavailable user ------------------ route[4] {
# non-Voip -- just send "off-line" if (!(method == "INVITE" || method == "ACK" || method == "CANCEL" || met hod == "BYE")) { sl_send_reply("404", "Not Found"); break; };
# not voicemail subscriber if (!isflagset(4)) {
if (uri=~"^sip:1.*") { setflag(1); rewritehostport("33.33.333.157:5060"); t_relay_to_udp("33.33.333.157", "5060"); break;
};
if (uri=~"^sip:011.*") { setflag(1); rewritehostport("22.222.222.26:5060"); t_relay_to_udp("22.222.222.26", "5060"); break; };
}
# forward to voicemail now setflag(3); rewritehostport("11.11.111.148:5060"); t_relay_to_udp("11.11.111.148", "5060"); }
# if forwarding downstream did not succeed, try voicemail running # at bat.iptel.org:5060
failure_route[1] { setflag(3); revert_uri(); rewritehostport("11.11.111.148:5060"); append_branch(); t_relay_to_udp("11.11.111.148", "5060"); }
-----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Thursday, December 18, 2003 4:48 PM To: Darren Sessions; serusers@lists.iptel.org Subject: Re: [Serusers] RE: Serusers Digest, Vol 8, Issue 16
SER does not generate such an error, SEMS does. Possibly, your BYEs are mistakenly passed to SEMS. They are supposed to be processed by loose routing.
-jiri
At 08:33 PM 12/18/2003, Darren Sessions wrote:
Situation:
Endpoint is called Party (Sipura SPA2000)
Calling Party is routed through from a TDM call and VoIP'd by Cisco 3640 router then sent to SER.
Endpoint receives call - everything works. When the Sipura hangs up the call, it sends a BYE to ser - but ser does not send the BYE to the router
to
disconnect the TDM channel.
All other situations result in a completed call with channels released on the router just fine.
After further inspection - we noticed that when the Sipura hangs up and
send
the BYE to SER, SER responds with this:
SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 11.11.111.155:5060;branch=z9hG4bK-b76fe29f From: sip:8646783182@22.22.222.154;tag=bc5a80577e3d5642 To: sip:8644679887@33.33.333.157;tag=322BCA98-25A3 Call-ID: F429FDCE-30B011D8-BA0EDB9C-52307829@33.33.333.157 CSeq: 101 BYE Contact: sip:8644679887@44.44.444.148 Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 44.44.444.148:5060 "Noisy feedback tells: pid=20033 req_src_ip=22.22.222.154 req_src_port=5060 in_uri=sip:8644679887@44.44.444.148:5060 out_uri=sip:8644679887@44.44.444.148:5060 via_cnt==0"
Any ideas?
Thanks,
- Darren
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/