Hello,
I have been unsuccessfully trying to setup OpenSER as a basic server in my private network. The idea is that clients can register to the virtual domain "sipserver.apt.local" and from then, INVITES will be sent to the appropiate address.
I use the following openser.cfg
# ----------- global configuration parameters ------------------------
debug=5 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
children=4
log_facility=LOG_LOCAL7
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
#
port=5060
listen=udp:192.168.100.244:5060
listen=udp:sipserver.apt.local:5060
alias="sipserver.apt.local:5060"
sip_warning=yes
# uncomment the following lines for TLS support
#disable_tls = 0
#listen = tls:your_IP:5061
#tls_verify_server = 1
#tls_verify_client = 1
#tls_require_client_certificate = 0
#tls_method = TLSv1
#tls_certificate = "/etc/openser/tls/user/user-cert.pem"
#tls_private_key = "/etc/openser/tls/user/user-privkey.pem"
#tls_ca_list = "/etc/openser/tls/user/user-calist.pem"
# ------------------ module loading ----------------------------------
#set module path
mpath="/usr/lib/openser/modules/"
# Uncomment this if you want to use SQL database
#loadmodule "mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "xlog.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
#loadmodule "auth.so"
#loadmodule "auth_db.so"
# ----------------- setting module-specific parameters ---------------
# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
exit;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER")
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
# if you have some interdomain connections via TLS
#if(uri=~"@tls_domain1.net") {
# t_relay("tls:domain1.net");
# exit;
#} else if(uri=~"@tls_domain2.net") {
# t_relay("tls:domain2.net");
# exit;
#}
route(1);
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
#if (!www_authorize("openser.org", "subscriber")) {
# www_challenge("openser.org", "0");
# exit;
#};
xlog("L_INFO","[ACHTUNG] saved $ru");
save("location");
exit;
};
xlog("L_INFO","[ACHTUNG]request from $ru");
#lookup("aliases");
#if (!uri==myself) {
# append_hf("P-hint: outbound alias\r\n");
# route(1);
#};
# native SIP destinations are handled using our USRLOC DB
#if (!lookup("location")) {
# sl_send_reply("404", "Not Found");
# exit;
#};
#append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
I can register fine, however, on INVITE, openSER forwards it internally instead of fw to the client registered until max_fw reaches 0 and an error "too many hops" is the final response. Log below:
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: [ACHTUNG] saved sip:192.168.100.244
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=8000000
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: build_contact(): Created Contact HF: Contact: sip:oslo_2_Route_1@sipserver.apt.local:5060;expires=3600^M
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: check_via_address(192.168.100.238, sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: receive_msg: cleaning up
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: SIP Request:
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: method: <INVITE>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: uri: sip:oslo@sipserver.apt.local
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: version: <SIP/2.0>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=2
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: Found param type 232, <branch> = <z9hG4bK4211644481>; state=16
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: end of header reached, state=5
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: Via found, flags=2
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: this is the first via
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: After parse_msg...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: preparing to run routing scripts...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=100
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached, state=10
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={}, ruri={sip:oslo@sipserver.apt.local}
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_field: <t> [32]; uri=[sip:oslo@sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: to body [sip:oslo@sipserver.apt.local^M ]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_hdr_field: cseq <CSeq>: <985859914> <INVITE>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:maxfwd:is_maxfwd_present: value = 70
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_param: tag=3326383385
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached, state=29
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={}, ruri={sip:oslo_2_Route_1@sipserver.apt.local}
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=200
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_body : content_length=202
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: found end of header
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: find_first_route: No Route headers found
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: loose_route: There is no Route HF
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==15 && [sipserver.apt.local] == [192.168.100.244]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==19 && [sipserver.apt.local] == [sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==15 && [sipserver.apt.local] == [192.168.100.244]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==19 && [sipserver.apt.local] == [sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: [ACHTUNG]request from sip:oslo@sipserver.apt.local
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_newtran: T on entrance=0xffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=78
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: t_lookup_request: start searching: hash=45820, isACK=0
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: RFC3261 transaction matching failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_lookup_request: no transaction found
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238, sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: WARNING:vqm_resize: resize(0) called
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: reply sent out. buf=0x813efd8: SIP/2.0 1..., shmem=0xb3e5d980: SIP/2.0 1
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: finished
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: mk_proxy: doing DNS lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no port, no proto -> do NAPTR lookup!
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record: lookup(sipserver.apt.local, 35) failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid NAPTR record found for sipserver.apt.local, trying direct SRV lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record: lookup(_sip._udp.sipserver.apt.local, 33) failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid SRV record found for _sip._udp.sipserver.apt.local, trying A record lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238, sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBG:check_against_rule_list: using list dns
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is 500000
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[4]: 0xb4091bac (104400000)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is 30
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[0]: 0xb4091bc8 (133)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:t_relay_to: new transaction fwd'ed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:UNREF_UNSAFE: after is 0
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: receive_msg: cleaning up
What is necessary so the INVITES are sent to the client and not to the server?
Regards,
El Viernes, 18 de Abril de 2008, Eloi Pecharroman escribió:
What is necessary so the INVITES are sent to the client and not to the server?
Eloi, I already replied you in other maillist that you have "lookup(location)" commented so OpenSer is not performing the RURI modification with the call AoR address:
# native SIP destinations are handled using our USRLOC DB #if (!lookup("location")) { # sl_send_reply("404", "Not Found"); # exit; #}; #append_hf("P-hint: usrloc applied\r\n");
Not sure why you ask the same question again without modifying it. I hope you are not trying to get it working without understanding why it works.
Hi all,
Please IGNORE this message.
It was quarantined by the mailing lists and sent yesterday.
Sorry for the inconvenience.
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 22 April 2008 22:35 To: users@lists.openser.org Subject: Re: [OpenSER-Users] BAsic openSER configuration. INVITES to a UAnot looped back.
El Viernes, 18 de Abril de 2008, Eloi Pecharroman escribió:
What is necessary so the INVITES are sent to the client and not to
the
server?
Eloi, I already replied you in other maillist that you have "lookup(location)" commented so OpenSer is not performing the RURI modification with the call AoR address:
# native SIP destinations are handled using our USRLOC DB #if (!lookup("location")) { # sl_send_reply("404", "Not Found"); # exit; #}; #append_hf("P-hint: usrloc applied\r\n");
Not sure why you ask the same question again without modifying it. I hope you are not trying to get it working without understanding why it works.
-- Iñaki Baz Castillo _______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Wednesday 23 April 2008 13:45:11 Eloi Pecharroman escribió:
Hi all,
Please IGNORE this message.
It was quarantined by the mailing lists and sent yesterday.
Oh, doing cross-posting? XDD
-
Eloi Pecharroman -
Iñaki Baz Castillo -
Iñaki Baz Castillo