Hi Iqbal,
I'm sorry, I didn't notice that you replied to my request.
I'm not 100% sure that the duplicate messages are related to the problem I am having, but I want to understand why ser is doing that. I took ser out of the loop (put the spa2000 on the Internet and disabled outbound proxy) and it worked fine.
The first column is the timestamp, and it shows that the duplicate INVITE is about 1/100'th of a second after the initial INVITE.
I'm really stuck here, and since I really don't know enough about ser, and am pretty green with voip, my next step would be trying to understand the source :( and seeing why the message would be send out twice :(
Thanks, Tim
Iqbal wrote:
Its Sunday night, so please double check anything I write :-)
Although I cant be a 100% for sure it seems as if you SER is just sending another INVITE this could be due to not receiving a reply in time, how long b4 the reply comes from the itsp, I think default in ser is 120secs or something.
If this is not the case, any chance of seeing what the itsp is throwing up when you send a request, might be something to do with the sdp, although ser doesnt really do much when it comes to codec/sdp parameter negotiation
Iqbal
On 6/26/2005, "Tim Pushor" timp@crossthread.com wrote:
Hi Friends,
I am trying to learn ser and wrap my head around the routing logic. My first project is a simple outbound proxy to handle SIP/RTP from an SPA2000 behind a NAT. The ser server is on the public Internet, but I am having trouble making it work :( The spa2000 has been reset to default, and basically setup the same way that I'd set it up for FWD behind nat).
I am using an example config from the Internet as as starting point (included below) and running on Ser 0.8.14 on FreeBSD (from a port). I am using the RTP proxy from ser cvs. This , It almost works, and capturing the traffic with ethereal looks to be mostly correct, but I am seeing duplicate sip messages (plz excuse formatting), which I think is causing me a big problem (even if it isn't, I'd like to know why this is happening).
I didn't include frames 1 and 2, they are a SIP keepalive.
3 is the request from the spa2000 to the proxy 4 is the response from the proxy 5 is the request from the proxy to the itsp 6 is a dup! And then the problem compounds as the itsp tries to connect the same call twice.
I would be very appreciative of any advice from you veterans ;-)
Thanks, Tim
** Doctored trace
207.46.199.15 is the address of the NAT
207.46.199.14 is the address of the Proxy running ser
69.16.138.164 is the address of my itsp's SIP proxy
3 4.563455 207.46.199.15 207.46.199.14
SIP/SDP Request: INVITE sip:6415551234@my.itsp.com, with session description 4 4.564809 207.46.199.14 207.46.199.15 SIP Status: 100 trying -- your call is important to us 5 4.566539 207.46.199.14 69.16.138.164 SIP/SDP Request: INVITE sip:6415551234@my.itsp.com, with session description 6 4.578979 207.46.199.14 69.16.138.164 SIP/SDP Request: INVITE sip:6415551234@my.itsp.com, with session description 7 4.589856 69.16.138.164 207.46.199.14 SIP Status: 100 Trying 8 4.602580 69.16.138.164 207.46.199.14 SIP Status: 407 Proxy Authorization Required 9 4.602733 207.46.199.14 69.16.138.164 SIP Request: ACK sip:6415551234@my.itsp.com 10 4.602808 207.46.199.14 207.46.199.15 SIP Status: 407 Proxy Authorization Required 11 4.611428 69.16.138.164 207.46.199.14 SIP Status: 407 Proxy Authorization Required 12 4.611574 207.46.199.14 69.16.138.164 SIP Request: ACK sip:6415551234@my.itsp.com 13 4.613772 207.46.199.15 207.46.199.14 SIP Request: ACK sip:6415551234@my.itsp.com 14 4.622070 207.46.199.15 207.46.199.14 SIP/SDP Request: INVITE sip:6415551234@my.itsp.com, with session description 15 4.623428 207.46.199.14 207.46.199.15 SIP Status: 100 trying -- your call is important to us 16 4.625164 207.46.199.14 69.16.138.164 SIP/SDP Request: INVITE sip:6415551234@my.itsp.com, with session description 17 4.648612 69.16.138.164 207.46.199.14 SIP Status: 100 Trying 18 7.101641 69.16.138.164 207.46.199.14 SIP Status: 180 Ringing 19 7.101844 207.46.199.14 207.46.199.15 SIP Status: 180 Ringing 20 7.601009 69.16.138.164 207.46.199.14 SIP Status: 180 Ringing 21 7.601206 207.46.199.14 207.46.199.15 SIP Status: 180 Ringing 22 8.859386 69.16.138.164 207.46.199.14 SIP Status: 180 Ringing 23 8.859577 207.46.199.14 207.46.199.15 SIP Status: 180 Ringing ..... .....
My config:
# ----------- global configuration parameters ------------------------
fork=no log_stderror=yes debug=7
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=1 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/textops.so"
# !! Nathelper loadmodule "/usr/local/lib/ser/modules/nathelper.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- 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
# ------------------------- 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 privateIP, rewriting\n");
# This will work only for user agents that supportsymmetric # 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 sourceIP 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") { 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(); if (!( search ("^Content-Length:\ 0") )) { 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(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers