[Serusers] RTP proxy
Maxim Sobolev
sobomax at portaone.com
Tue Feb 17 15:36:52 CET 2004
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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
More information about the sr-users
mailing list