Interesting, the config file looks sane -- can you send me message dumps too?

Thanks,

-jiri

At 11:01 PM 12/18/2003, Darren Sessions wrote:

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/

-- Jiri Kuthan http://iptel.org/~jiri/