Yes, you are right. Sorry for not being clear enough. ser.cfg is at the botton of the message. The scenario is as follows: The sip server is listening on 194.179.25.52. The user chano(a)wmserver.hi.inet on the machine sayuritra (private address: 192.168.1.34, public address: 81.35.36.166) calls to the user raquel(a)wmserver.hi.inet on hobbes (private address: 192.168.1.34, public addess: 80.32.97.245). The messages captured in the sip server are the following (irrelevant messages are omitted): 1) INVITE from sayuritra to server (81.35.36.166:20820 -> 194.179.25.52:5060): INVITE sip:raquel@wmserver.hi.inet SIP/2.0..Via: SIP/2.0/UDP 81.35.36.166:20818..From: "chano" <sip:chano@wmserver.hi.inet>;tag=a350c270-a7ff-4149-8e05-8af9f79e9e92..To: <sip:raquel@wmserver.hi.inet>..Call-ID: 5e5ba0ab-2321-4e87-b038-5a99fc37acdd@81.35.36.166..CSeq: 1 INVITE..Contact: <sip:81.35.36.166:20818>..User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Content-Length: 531....v=0..o=sayuritra 0 0 IN IP4 81.35.36.166..s=session..c=IN IP4 81.35.36.166..b=CT:1000..t=0 0..m=audio 20857 RTP/AVP 97 111 112 6 0 8 4 5 3 101..a=rtpmap:97 red/8000..a=rtpmap:111 SIREN/16000..a=fmtp:111 bitrate=16000..a=rtpmap:112 G7221/16000..a=fmtp:112 bitrate=24000..a=rtpmap:6 DVI4/16000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/8000..a=rtpmap:5 DVI4/8000..a=rtpmap:3 GSM/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..m=video 61674 RTP/AVP 34 31..a=rtpmap:34 H263/90000..a=rtpmap:31 H261/90000.. (so sayuritra is waiting for incoming video from server on port 61674 and audio on 20857) 2) INVITE from server to hobbes (194.179.25.52:5060 -> 80.32.97.245:12595): INVITE sip:80.32.97.245:12595 SIP/2.0..Max-Forwards: 10..Record- Route: <sip:194.179.25.52;ftag=a350c270-a7ff-4149-8e05- 8af9f79e9e92;lr=on>..Via: SIP/2.0/UDP 194.179.25.52;branch=z9hG4bKdbfe.e72b2f84.0..Via: SIP/2.0/UDP 81.35.36.166:20818..From: "chano" <sip:chano@wmserver.hi.inet>;tag=a350c270-a7ff-4149-8e05-8af9f79e9e92..To: <sip:raquel@wmserver.hi.inet>..Call-ID: 5e5ba0ab-2321-4e87-b038- 5a99fc37acdd@81.35.36.166..CSeq: 1 INVITE..Contact: <sip:81.35.36.166:20818>..User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Content-Length: 550..P-hint: usrloc applied....v=0..o=sayuritra 0 0 IN IP4 81.35.36.166..s=session..c=IN IP4 194.179.25.52..b=CT:1000..t=0 0..m=audio 35106 RTP/AVP 9 7 111 112 6 0 8 4 5 3 101..a=rtpmap:97 red/8000..a=rtpmap:111 SIREN/16000..a=fmtp:111 bitrate=16000..a=rtpmap:112 G7221/16000..a=fmtp:112 bitrate=24000..a=rtpmap:6 DVI4/16000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/8000..a=rtpmap:5 DVI4/8000..a=rtpmap:3 GSM/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..m=video 61674 RTP/AVP 34 31..a=rtpmap:34 H263/90000..a=rtpmap:31 H261/90000..a=n ortpproxy:yes.. (so server is waiting for incoming video from hobbes on port 35106 and audio on 20857) 3) 200 OK from hobbes to server (80.32.97.245:12595 -> 194.179.25.52:5060): SIP/2.0 200 OK..Via: SIP/2.0/UDP 194.179.25.52;branch=z9hG4bKdbfe.e72b2f84.0..Via: SIP/2.0/UDP 81.35.36.166:20818..From: "chano" <sip:chano@wmserver.hi.inet>;tag=a350c270-a7ff-4149-8e05-8af9f79e9e92..To: <sip:raquel@wmserver.hi.inet>;tag=54e09747-9530-456b-b0bf-e98bc4c72d3c..Call-ID: 5e5ba0ab-2321-4e87-b038-5a99fc37acdd@81.35.36.166..CSeq: 1 INVITE..Record-Route: <sip:194.179.25.52;ftag=a350c270-a7ff-4149-8e05-8af9f79e9e92;lr=on>..Contact: <sip:192.168.1.34:9843>..User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Content-Length: 528....v=0..o=hobbes 0 0 IN IP4 192.168.1.34..s=session..c=IN IP4 192.168.1.34..b=CT:1000..t=0 0..m=audio 47976 RTP/AVP 97 111 112 6 0 8 4 5 3 101..a=rtpmap:97 red/8000..a=rtpmap:111 SIREN/16000..a=fmtp:111 bitrate=16000..a=rtpmap:112 G7221/16000..a=fmtp:112 bitrate=24000..a=rtpmap:6 DVI4/16000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/8000..a=rtpmap:5 DVI4/8000..a=rtpmap:3 GSM/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..m=video 25608 RTP/AVP 34 31..a=rtpmap:34 H263/90000..a=rtpmap:31 H261/90000.. (so hobbes is waiting for incoming video from server on port 25608 and audio on 47976) 4) 200 OK from server to sayuritra (194.179.25.52:5060 -> 81.35.36.166:20818): SIP/2.0 200 OK..Via: SIP/2.0/UDP 81.35.36.166:20818..From: "chano" <sip:chano@wmserver.hi.inet>;tag=a350c270-a7ff-4149-8e05-8af9f79e9e92..T o: <sip:raquel@wmserver.hi.inet>;tag=54e09747-9530-456b-b0bf-e98bc4c72d3c..Call-ID: 5e5ba0ab-2321-4e87-b038-5a99fc37acdd@81.35.36.166..CSeq : 1 INVITE..Record-Route: <sip:194.179.25.52;ftag=a350c270-a7ff-4149-8e05-8af9f79e9e92;lr=on>..Contact: <sip:80.32.97.245:12595>..User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Content-Length: 547....v=0..o=hobbes 0 0 IN IP4 192.168.1.34..s=session..c=IN IP4 194.179.25.52..b=CT:1000..t=0 0..m=audio 35108 RTP/AVP 97 111 112 6 0 8 4 5 3 101..a=rtpmap:97 red/8000..a=rtpmap:111 SIREN/16000..a=fmtp:111 bitrate=16000..a=rtpmap:112 G7221/16000..a=fmtp:112 bitrate=24000..a=rtpmap:6 DVI4/16000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/8000..a=rtpmap:5 DVI4/8000..a=rtpmap:3 GSM/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..m=video 25608 RTP/AVP 34 31..a=rtpmap:34 H263/90000..a=rtpmap:31 H261/90000..a=nortpproxy:yes.. (so server is waiting for incoming video from sayuritra on port 25608 and audio on 35108) After the connection has stablished, if we put a sniffer in sayuritra, we can see that there are ICMP 'destination unreachable' packets directed from server to sayuritra on port 25608, that is, the RTP proxy is directing the video packets to a closed port on sayuritra. Oddly, that port is the one where hobbes is listening on, that is, it seems that the RTP proxy is sending packets to the correct port in the wrong machine or, the other way other round, to the right machine in the correct port. Any ideas?. Thank you very much, Luciano Bajo Ser.cfg: # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ # machine has two network interfaces, listen only on the public one: listen=194.179.25.52 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" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "/usr/local/lib/ser/modules/mysql.so" 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/textops.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/local/lib/ser/modules/auth.so" #loadmodule "/usr/local/lib/ser/modules/auth_db.so" # !! Nathelper loadmodule "/usr/local/lib/ser/modules/nathelper.so" # ----------------- setting module-specific parameters --------------- # -- 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) # !! Nathelper 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 modparam("nathelper","rtpproxy_sock","/var/run/rtpproxy.sock") # ------------------------- 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"); 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) { #ppend_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\.|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(); }; }