There are several problems:
1. "ERROR: send_rtpp_command: can't read reply from a RTP proxy" in log
means that either rtpproxy wasn't running at the time when you started
SER or incompatible version of it was installed. Please note that you
have to use latest cvs version of rtpproxy with nethelper from cvs.
2. isflagset(6) test in onreply_route is bogus since you don't have
setflag(6) in onreply_route, so that the test is always false.
-Maxim
Eduard San Anselmo Mateu wrote:
Hello.
I'm newbie to this list, as well as to SER. I'm testing SER with nathelper
module and rtpproxy (portaone RTP proxy), and I can't get to make it work.
The version I'm using is that from the CVS (latest), because I tried with
v.0.8.12 and didn't get satisfactory results.
rtpproxy is started this way:
rtpproxy -2f -l 192.168.20.15
My config file is the one that comes with the files, with the appropiate changes:
debug=3 # debug level (cmd line: -dddddddddd)
#fork=no
#log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
listen=192.168.20.15
alias=mydomain.com
alias=192.168.0.15
alias=192.168.20.15
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.so"
loadmodule "/usr/lib/ser/modules/nathelper.so"
modparam("usrloc", "db_mode", 0)
modparam("rr", "enable_full_lr", 1)
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
modparam("nathelper", "ping_nated_only", 1) # Ping only clients
behind NAT
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");
break;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test("3")) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if (method == "REGISTER" || !
search("^Record-Route:")) {
log("LOG: Someone trying to register from private IP,
rewriting\n");
# This will work only for user agents that support symmetric
# communication. We tested quite many of them and majority is
# smart enough to be symmetric. In some phones it takes a
configuration
# option. With Cisco 7960, it is called NAT_Enable=Yes, with
kphone it is
# called "symmetric media" and "symmetric
signalling".
fix_nated_contact(); # Rewrite contact with source IP of
signalling
if (method == "INVITE") {
fix_nated_sdp("1"); # Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setflag(6); # Mark as NATed
};
};
# 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);
break;
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
break;
};
# 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("iptel.org",
"subscriber")) {
# www_challenge("iptel.org", "0");
# break;
# };
save("location");
break;
};
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# !! Nathelper
#if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"
&&
!search("^Route:")){
# sl_send_reply("479", "We don't forward to private IP
addresses");
# break;
#};
# if client or server know to be behind a NAT, enable relay
if (isflagset(6)) {
force_rtp_proxy();
};
# NAT processing of replies; apply to all transactions (for example,
# re-INVITEs from public to private UA are hard to identify as
# NATed at the moment of request processing); look at replies
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
# !! Nathelper
onreply_route[1] {
# NATed transaction ?
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
force_rtp_proxy();
# otherwise, is it a transaction behind a NAT and we did not
# know at time of request processing ? (RFC1918 contacts)
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
These are the logs I get at /var/log/messages:
sistemas2 ser: WARNING: fix_socket_list: could not rev. resolve 192.168.20.15
sistemas2 ser: WARNING: fix_socket_list: could not rev. resolve 192.168.20.15
sistemas2 ser: Listening on
sistemas2 ser: udp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 ser: tcp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 ser: Aliases:
sistemas2 ser: *: 192.168.20.15:*
sistemas2 ser: *: 192.168.0.15:*
sistemas2 ser: *: mydomain.com:*
sistemas2 ser:
sistemas2 ser: Listening on
sistemas2 ser: udp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 ser: tcp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 ser: Aliases:
sistemas2 ser: *: 192.168.20.15:*
sistemas2 /usr/sbin/ser[25761]: ERROR: send_rtpp_command: can't read reply from
a RTP proxy
sistemas2 ser: *: 192.168.0.15:*
sistemas2 /usr/sbin/ser[25761]: WARNING: nathelper: can't get version of the RTP
proxy
sistemas2 ser: *: mydomain.com:*
sistemas2 /usr/sbin/ser[25761]: WARNING: nathelper: support for RTP proxyhas
been disabled
sistemas2 ser:
sistemas2 /usr/sbin/ser[25761]: INFO: udp_init: SO_RCVBUF is initially 65535
sistemas2 ser: Listening on
sistemas2 /usr/sbin/ser[25761]: INFO: udp_init: SO_RCVBUF is finally 131070
sistemas2 ser: udp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 /usr/sbin/ser[25762]: NOTICE:init_avp_child: no avp_db_url specified
-> feature disabled
sistemas2 /usr/sbin/ser[25763]: NOTICE:init_avp_child: no avp_db_url specified
-> feature disabled
sistemas2 /usr/sbin/ser[25764]: NOTICE:init_avp_child: no avp_db_url specified
-> feature disabled
sistemas2 /usr/sbin/ser[25765]: NOTICE:init_avp_child: no avp_db_url specified
-> feature disabled
sistemas2 /usr/sbin/ser[25766]: INFO: fifo process starting: 25766
sistemas2 ser: tcp: 192.168.20.15 [192.168.20.15]:5060
sistemas2 /usr/sbin/ser[25766]: SER: open_uac_fifo: fifo server up at
/tmp/ser_fifo...
sistemas2 ser: Aliases:
sistemas2 /usr/sbin/ser[25766]: WARNING: no fifo_db_url given - fifo DB commands
disabled!
sistemas2 ser: *: 192.168.20.15:*
sistemas2 ser: *: 192.168.0.15:*
sistemas2 ser: *: mydomain.com:*
sistemas2 ser:
sistemas2 ser: ser startup succeeded
sistemas2 /usr/sbin/ser[25764]: ERROR: force_rtp_proxy2: support for RTP proxy
is disabled
sistemas2 /usr/sbin/ser[25762]: ERROR: force_rtp_proxy2: support for RTP proxy
is disabled
sistemas2 /usr/sbin/ser[25762]: ERROR: on_reply processing failed
What's wrong? I can't seem to find my mistake!
Thanks in advance.
Eduard San Anselmo
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers