sr-users August 2005

sr-users@lists.kamailio.org

220 participants
558 discussions

[Serusers] 1 way voice issue
by Sam Lee 01 Aug '05

01 Aug '05

Hi, I've recently encountered some problem with my SIP service whereby i call out to a specific number and i encounter a one way voice. If i'm the initiator, i cannot hear the other party but he can hear me. At first i thought it was a return route issue (as i'm going thru NAT) , so i switch my SIP to a public IP but i still face the same problem. Its really only that specific PSTN number that i have dialed facing this problem. The only difference that i can think of is that PSTN number is on … [View More]

2 1

[Serusers] STUN for NAT traversal...
by Roger Lewau 01 Aug '05

01 Aug '05

I'm trying to use STUN for NAT traversal for all clients not using 1 to 1 NATing, and mediaproxy for the rare few who does.But it seems that all traffic is proxied anyway, dont really understand why. I do call the routeblock for mediaproxy before relaying the call, but since STUN is used it should not detect that NAT is in place. Or am I missing some logic? Any Idea on how to accomplish this? Kind regards Roger - Getting one step closer to a really god service everyday ;)

2 1

[Serusers] Mediaproxy Load Balacing
by smy＠addm.com 01 Aug '05

01 Aug '05

Hi all, I've tried playing with Mediaproxy for sometime now, and thou with some clarification from Greger, I'm still having some problems with getting it up and running. I'm trying to have 1 SER with multiple Mediaproxy, and here's my configuration. I'm desperate since I've experienced no improvement with the system after over a week playing with it! :< Any help is really appreciated. --------- ser.cfg --------- loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/… [View More]

2 1

[Serusers] NAT Problem (Mediaproxy)... Pls help
by Yan Yu Lim 01 Aug '05

01 Aug '05

Hi Guys, I have a NAT problem, whereby I cannot get the RTP packets from a NATed user. Hence, I am trying to implement the Mediaproxy solution from ONSIP. 1. Mediaproxy and Ser are installed on the same PC, say 202.123.45.85. I've set SER to listen at 202.123.45.85, port 5060. How should I configure the ini file for Mediaproxy? Can someone please provide me with a simple example of how the mediaproxy ini file should be configured? 2. Assuming that I set mediaproxy to listen at 202.123.45.85, … [View More]

2 1

[Serusers] Mediaproxy -- pls help!
by yy lim 01 Aug '05

01 Aug '05

Hi guys, I'm trying to get my mediaproxy working without much success. Both mediaproxy and ser are installed on the same machine, i.e. 201.23.13.145 for example. SER is listening on port 5060, and mediaproxy is set up as below. Please kindly advise. Rgrds, Zan ----- Mediaproxy.ini ------ [MediaProxy] start = yes socket = /var/run/mediaproxy.sock group = ser listen = 201.23.13.145:5062 allow = any proxyIP = 201.23.13.145 portRange = 5062:5064 TOS = 0xb8 idleTimeout = 60 holdTimeout = 3600 … [View More]forceClose = 0 accounting = off ------- ser.cfg ------- debug=3 fork=yes listen=201.23.13.145 log_stderror=yes check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:XXXXX@localhost/ser" # ------------------ 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/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/exec.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" loadmodule "/usr/local/lib/ser/modules/acc.so" # -- mediaproxy NAT modules --- loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" # ----------------- setting module-specific parameters --------------- # -- auth_radius params -- modparam("auth_db|uri_db|usrloc", "db_url", "mysql://ser:XXXXXX@localhost/ser") modparam("acc", "db_url", "mysql://ser:XXXXXX@localhost/ser") # -- usrloc params -- # store user location in memory, not using database modparam("usrloc", "db_mode", 0) # -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", 1) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "password") # mysql accounting # -- acc params -- modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 1) modparam("acc", "failed_transactions", 1) # -- tm params -- # set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, # fr_timer for all others modparam("tm","fr_inv_timer",15) modparam("tm","fr_timer",10) modparam("tm","fr_inv_timer_avp", "inv_timeout") #modparam("permissions", "db_mode", 1) #modparam("permissions", "trusted_table", "trusted") # -- Mediaproxy params -- modparam("nathelper", "rtpproxy_disable", 1) modparam("nathelper", "natping_interval", 0) modparam("mediaproxy","natping_interval", 30) modparam("mediaproxy","mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/ser/sip-clients") modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/ser/rtp-clients") modparam("registrar", "nat_flag", 6) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # main routing logic route{ # ----------------------------- # Sanity check # ----------------------------- # 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; }; # ----------------------------- # Record Route Section # ----------------------------- # perform NAT check if (method=="INVITE" && client_nat_test("3")) { record_route_preset("201.23.13.145:5060;nat=yes"); log(1,"Invite + NAT test- Record Route\n"); } # 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 else if(method!="REGISTER") { record_route(); }; # ------------------------------- # Call Tear Down Section # ------------------------------- if (method=="BYE" || method=="CANCEL") { end_media_session(); log(1,"Tear Down Section\n"); }; # ------------------------- # loose-route processing # ------------------------- if (loose_route()) { if (has_totag() && (method=="INVITE" || method=="ACK")) { if (client_nat_test("3") || search("^Route:.*;nat=yes")) { setflag(6); use_media_proxy(); }; log(1,"Loose route processing\n"); }; route(1); break; }; setflag(1); # ----------------------------- # Call Type Processing Section # ----------------------------- if(uri != myself) { route(5); route(1); break; }; if (uri==myself) { if(method == "ACK") { route(6); break; } else if (method =="CANCEL") { route(3); break; } else if(method=="INVITE") { route(3); t_on_failure("1"); break; } else if(method=="REGISTER") { route(2); break; }; lookup("aliases"); if (uri!=myself) { route(5); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; route(1); } # ------------------------------- # Route Processing Section # ------------------------------- # ------------------------------ # Default Message Handler # ------------------------------ route[1] { t_on_reply("1"); if(!t_relay()) { if(method=="INVITE" || method=="ACK") { end_media_session(); log(1,"Route 1 default message handler\n"); }; sl_reply_error(); }; } # REGISTER Message Handler # ---------------------------------------------------------------- route[2] { sl_send_reply("100", "Trying"); if (!search("^Contact:\ +\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); log(1,"Nated register\n"); }; if (!www_authorize("","subscriber")) { www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } # ----------------------------------------------------------------- # CANCEL & INVITE Message Handler # ----------------------------------------------------------------- route[3] { if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if(method=="INVITE" && !(src_ip==10.10.10.4)) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; lookup("aliases"); if (uri!=myself) { route(5); route(1); break; }; if (!lookup("location")) { # attempt handoff to PSTN if (uri=~"^sip:8[0-9]*@") { log(1, "Forwarding to PSTN\n"); route(4); break; }; # retrieve voicemail if (uri=~"^sip:2[0-9]*@") { log(1, "Retrieving voicemail\n"); route(7); break; }; sl_send_reply("404", "User Not Found!"); break; }; if(method=="CANCEL") { route(1); break; }; route(5); route(1); } # ----------------------------- # PSTN Handler # ----------------------------- route[4] { rewritehostport("10.10.10.4:5060"); avp_write("i:45", "inv_timeout"); # ------------------------------- # RTP Proxy Enabler # ------------------------------- route[5] { if(isflagset(6)||isflagset(7)) { use_media_proxy(); log(1,"Using rtp proxy\n"); }; } # ------------------------------- # ACK # ------------------------------- route[6] { if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; lookup("aliases"); if (uri!=myself) { route(5); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found!"); break; }; route(5); route(1); } route(5); route(1); } # ------------------------------ # Asterisk voicemail # ------------------------------ route[7] { #redirect now! rewritehostport("201.23.13.145:5061"); append_branch(); t_relay_to_udp("201.23.13.145","5061"); } failure_route[1] { if(!(method=="BYE") && !(method=="CANCEL")) { log(1,"Activating voicemail!!\n"); }; #revert_uri(); #redirect now! rewritehostport("201.23.13.145:5061"); append_branch(); t_relay_to_udp("201.23.13.145","5061"); } onreply_route[1] { log(1,"On reply route/n"); if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { if (!search("^Content-Length:\ +0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [View Less]

1 0

Re: [Serusers] serctll add error
by chris 01 Aug '05

01 Aug '05

hi kofi, were you able to run and test my config file? any developments? :) much thanks. chris ----- Original Message ----- From: chris To: Kofi Obiri-Yeboah ; serusers(a)lists.iptel.org Sent: Wednesday, July 27, 2005 11:46 AM Subject: Re: [Serusers] serctll add error hi kofi, i did commented out the listen=IP line. but i gives me the same error. ERROR: bad config file (1 errors) by the way, when i tried the hello_world.cfg from onsip i did not encountered any … [View More]problem and ser was able to run. thnks kofi, i will wait for you reply next week. chris. ----- Original Message ----- From: Kofi Obiri-Yeboah To: chris ; serusers(a)lists.iptel.org Sent: Wednesday, July 27, 2005 11:19 AM Subject: RE: [Serusers] serctll add error Chris, I will run your config file over the weekend and will get back to you. Clearly that fact that you are receiving a bad config file error is an indication that there is a problem. Could you please comment out the listen=IP address line and rerun ?????? KOFI -----Original Message----- From: chris [mailto:chris@fivestartel.com] Sent: Tuesday, July 26, 2005 10:19 AM To: Kofi Obiri-Yeboah; serusers(a)lists.iptel.org Subject: Re: [Serusers] serctll add error hi kofi, attached is my ser.cfg i got this sample script from onsip.org getting started doc. this is their auth-mysql.3.05.cfg sample script, i just change the IP address on the listen variable. running using this cfg file leads me to an error. ERROR: bad config file (1 errors) maybe u can help me fix this. i have no idea how i can give you more details on the error cause that is the only line the system gives me. thnks. debug=3 fork=yes log_stderror=no listen=203.115.128.41 # put your server IP address here port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" 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/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" modparam("auth_db|uri_db|usrloc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("usrloc", "db_mode", 2) modparam("rr", "enable_full_lr", 1) route { # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (uri!=myself) { route(1); break; }; if (uri==myself) { if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (uri!=myself) { route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); }; } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- if (!t_relay()) { sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ---------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!www_authorize("","subscriber")) { www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } route[3] { # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); lookup("aliases"); if (uri!=myself) { route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); } ----- Original Message ----- From: Kofi Obiri-Yeboah To: chris ; serusers(a)lists.iptel.org Sent: Tuesday, July 26, 2005 11:39 PM Subject: RE: [Serusers] serctll add error please send your config file -----Original Message----- From: chris [mailto:chris@fivestartel.com] Sent: Tuesday, July 26, 2005 6:34 AM To: Kofi Obiri-Yeboah; serusers(a)lists.iptel.org Subject: Re: [Serusers] serctll add error hi, i still got the same error bash-2.05# serctl add 1001 1001 chris(a)yahoo.com awk: syntax error near line 1 awk: bailing out near line 1 awk: syntax error near line 1 awk: bailing out near line 1 HA1 calculation failed bash-2.05# pls. advise on how to fix this. thnks. ----- Original Message ----- From: Kofi Obiri-Yeboah To: chris ; serusers(a)lists.iptel.org Sent: Tuesday, July 26, 2005 8:06 PM Subject: RE: [Serusers] serctll add error syntax is <username> <password> <email address> you have a typo in the email address use "@" instead of "2" use shift-2 before yahoo.com HTH -----Original Message----- From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org]On Behalf Of chris Sent: Tuesday, July 26, 2005 12:58 AM To: serusers(a)lists.iptel.org Subject: [Serusers] serctll add error hello i tried running serctl add 1001 1001 chris_cleofe2yahoo.com but i got this error: awk: syntax error near line 1 awk: bailing out near line 1 awk: syntax error near line 1 awk: bailing out near line 1 HA1 calculation failed pls advise. thnks. [View Less]

1 0

Re: [Serusers] Problem : Can SER process the reINVITE messages properly?
by Greger V. Teigre 01 Aug '05

01 Aug '05

BTW, I sketched out a few other solutions, where I believe at least a couple should be valid attempts. Did you try those and what were the results? g-) Ricardo Martinez wrote: > Hello Greger and SER users. > About this issue here are some test that i made. I added the > lookup("location") as you recommend me : > > # > > > > ----------------------------------------------------------------- # > Loose Route Section # > -----------------------------------… [View More]------------------------------ if > (loose_route()) { > > if (has_totag() && (method=="INVITE" || > method=="ACK")) { lookup("location"); > if (isflagset(6) || client_nat_test("3") || > search("^Route:.*;nat=yes")){ > setflag(6); > use_media_proxy(); > }; > }; > > route(1); > break; > }; > > > Unfortunately, i'm still unable to have voice in both ways, but this > modification seems to handle better the reINVITE message. And this > is why. For the normal approach (i mean the initial onsip_pstn > configuration) the second INVITE was not using the mediaproxym as > Greger pointed. Now, as you can see in the debugs that i'm > attaching, the second invite is using the mediaproxy, and therefore > the "c" parameter in the SDP message is being correctly modified by > SER. So, i don't understand why this time the call is failing. Could > it be that mediaproxy is not capable to handle the reINVITEs?. For > example in the debug from mediaproxy (i'm also attaching this one), i > see a warning message like this : warning: Received packet from a > third party: 200.0.0.7:16432. It seems like mediaproxy is not > accepting "voice packets" from the second IP (the one indicated by > the reINVITE). Why? > Also, when the call is established this is the output from the > "session" command : > > Caller Via Called > Status Duration Codec Type Traffic > ---------------------------------------------------------------------------- > -------------------------------------- > 200.0.0.6:17480 - 200.0.0.5:35094 - 200.0.0.4:46115 inactive > 0'24" G729 Audio 0/16.75k/16.75k > > The call is established but between the first IP (Asterisk box) and > the endpoint public IP. > So, could this be a problem with mediaproxy?. I read the changelog > from the version 1.3.1 and this is what i found : > > Changes from version 1.2.1 to 1.3.0 > ----------------------------------- > > - Only create a new session if a request belongs to the first INVITE > (no longer creates new sessions on re-INVITEs) > > could it be related?. > > I also have a general question about the reINVITE. As you can see > the first INVITE has in his URI the domain name for the number : > 5555848114(a)sipvoiss.desarrollo.redvoiss.net (Frame 1 from the debug). > The reINVITE sent by Asterisk has the URI : 5555848114(a)200.0.0.4. Is > this ok?, despite of this the reINVITE is correctly redirected to the > endpoint. (You can check this in the frame 13 from the debug). > > Thanks again. > > Regards, > > Ricardo Martinez.- > > > >> -----Mensaje original----- >> De: Greger V. Teigre [mailto:greger@teigre.com] >> Enviado el: Miércoles, 20 de Julio de 2005 3:06 >> Para: Ricardo Martinez; serusers(a)lists.iptel.org >> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE >> messages properly? >> >> >> Hm. This was a tricky one. I would like to ask a second >> opinion from you >> NAT gurus on my musings below. What is the most appropriate >> response to >> Ricardo's scenario? WARNING to others: This is getting fairly >> technical on >> NAT/SDP... ;-) >> >> The reINVITE from Asterisk has a valid IP address and a valid >> (but new) SDP >> media ip (C=IN IP4 200.0.0.7). nat=yes is correctly not >> present in the >> reINVITE from Asterisk (it is not NATed). Thus >> use_media_proxy is correctly >> not used in the reINVITE, i.e. client_nat_test("3") and test >> on nat=yes will >> not trigger under the has_totag if statement (loose route >> processing): >> >> if (loose_route()) { >> >> if (has_totag() && (method=="INVITE" || method=="ACK")) { >> >> if (client_nat_test("3") || search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> }; >> >> route(1); >> break; >> }; >> >> In the OK from the Linksys: >> U 200.0.0.5:5060 -> 200.0.0.6:5060 >> SIP/2.0 200 OK. >> To: >> <sip:5555848114@sipvoiss.desarrollo.redvoiss.net>;tag=64d7492d >> b018b13ai0. From: "5565625858196" >> <sip:5565625858196@sipvoiss.desarrollo.redvoiss.net>;tag=as5d352c9a. >> Call-ID: >> 0848ef78297116742562204e2c04cbcb(a)sipvoiss.desarrollo.redvoiss.net. >> CSeq: 104 INVITE. >> Via: SIP/2.0/UDP 200.0.0.6:5060;branch=z9hG4bK518d870e. >> Record-Route: <sip:200.0.0.5;ftag=as5d352c9a;lr=on>. >> Contact: 5555848114 <sip:5555848114@200.0.0.4:46081>. >> Server: Linksys/PAP2-2.0.10(LSb). >> Content-Length: 237. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 33068 33068 IN IP4 192.168.15.200. >> s=-. >> c=IN IP4 192.168.15.200. >> t=0 0. >> m=audio 16424 RTP/AVP 18 100 101. >> a=rtpmap:18 G729/8000. >> a=rtpmap:100 NSE/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> ...you have 192.168.15.200, a private c= address in SDP, but >> the Contact has >> correctly been fixed (200.0.0.4:46081). So it seems the OK is >> processed >> correctly in onreply even though it does not show up in the >> debug. Flags 6 >> and 7 are not set, so use_media_proxy is correctly not run. >> The problem is >> that flag 6 should have been set (the Linksys is NATed), but >> as the reINVITE >> is not processed using lookup("location") the flag will not >> be picked up >> from usrloc. >> ---------------------------------------- >> >> However, now that Asterisk in the reINVITE is requesting >> another (valid) IP >> as media destination, the question is: what is propor behavior? >> >> The most natural would be to add a lookup("location") after: >> if (has_totag() && (method=="INVITE" || method=="ACK")) >> and then add isflagset(6) to the or test: >> if (isflagset(6) || client_nat_test("3") || >> search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> >> However, I'm not sure the lookup will work, because the R-URI >> is likely to >> be the direct address (5555848114@200.0.0.4:46081) and not >> the registered >> URI (@domain.com). It would be tempting to try to see if we >> somehow could >> make nat=yes set in the early INVITE. We would have to split the >> record_route section in two. One to handle !="REGISTER && >> !="INVITE" with a >> regular record_route() and wait until AFTER >> lookup("location") (maybe in >> route[1], the default handler) to add the following: >> if(method=="INVITE")){ >> if(isflagset(6)) { >> # INSERT YOUR IP ADDRESS HERE >> record_route_preset("192.0.2.13:5060;nat=yes"); >> } else { >> record_route(); >> } >> } >> >> This would make sure that not only dialogs where caller is >> nated, but also >> where callee is nated, will be tagged as nated. This again >> would cause >> nat=yes to be set and rtp proxy forced, further flag 6 is >> set, and thus the >> OK also processed with use_media_proxy(). >> >> BUT: Would this nat=yes cause any problems in other >> scenarios??? I'm not >> sure, but I don't think so. If that is correct, this is >> maybe the right >> solution. >> --------------------------------------- >> OTHER (SIMPLER?) SOLUTIONS: >> ---------- >> Instead you could add ||client_nat_test("1") together with >> isflagset 6 and 7 >> in your reply route: >> if ((isflagset(6) || isflagset(7) || client_nat_test("1")) && >> (status=~"(180)|(183)|2[0-9][0-9]")) >> >> but it will not work because the reINVITE did not get >> use_media_proxy(). >> >> Or, you could instead add fix_nated_sdp("2"); in your onreply route: >> if (client_nat_test("1")) { >> fix_nated_contact(); >> fix_nated_sdp("2"); >> }; >> WARNING! You will have to add else in between this test and >> the previous to >> avoid messing up use_media_proxy(). >> >> This will fix the SDP (c=IN IP4), but it will probably not >> help, because the >> port is still unknown. You could use "3" instead in >> fix_nated_sdp, this >> will add direction=active to the OK. However, another thread >> stated that >> Asterisk does not support direction=active. If it does, it >> will probably >> work and you get a non-proxied stream between Asterisk and >> the Linksys. >> >> Or finally, the third option would be to add the (hopefully) >> fixed IP in the >> loose_route test: >> if (src_ip==200.0.0.6 || client_nat_test("3") || >> search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> >> This would cause the OK automatically to get use_media_proxy. >> >> Ricardo, could you please test these various solutions and >> see if they >> really work or if (where...) I go wrong :-) >> g-) >> >> Ricardo Martinez wrote: >>> Hello Greger. >>> Thanks for your answer on this topic. Now i'm attaching more debug >>> information (the /var/log/messages from mediaproxy, the ngrep output >>> and some xlog statements in the ser.cfg file) beside some >> comments in >>> the file reINVITE_debug_problem.txt. >>> >>>> - Is your session really set up initially (before the reINVITE)? >>>> (mediaproxy reports 0/0/0 bytes) >>> >>> At least i have ringback tone. Then, when the call is answered i >>> have an OK and a ACK message coming to my SER box, then inmediatly >>> the reINVITE message arrives Asterisk box. >>> >>> >>> For what i can see from the debug the "nat=yes" is never reached >>> because the caller has a "valid ip" and therefore the first "if" in >>> the statament >>> >>> if (method=="INVITE" && client_nat_test("3")) { >>> # INSERT YOUR IP ADDRESS HERE >>> record_route_preset("64.76.148.246:5060;nat=yes"); >>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION : >>> invite & client_nat_test(3) TRUE ,record_route_preset [%rm]\n"); >>> } else if (method!="REGISTER") { >>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION : >>> record_route [%rm]\n"); >>> record_route(); >>> }; >>> >>> from the RECORD ROUTE SECTION is FALSE. >>> >>> Also, i don't understand why the second OK (the one from the >>> reINVITE) is not procesed in the ONREPLY ROUTE, or at least i don't >>> see any statement from the "xlog" in the debug. Is this normal? >>> >>> Thanks.! >>> Regards, >>> >>> Ricardo Martinez.- >>> >>> >>>> -----Mensaje original----- >>>> De: Greger V. Teigre [mailto:greger@teigre.com] >>>> Enviado el: Lunes, 18 de Julio de 2005 2:45 >>>> Para: Ricardo Martinez; serusers(a)lists.iptel.org >>>> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE >>>> messages properly? >>>> >>>> >>>> Hi Ricardo, >>>> Thanks for a detailed analysis. Some questions: >>>> - Is your session really set up initially (before the reINVITE)? >>>> (mediaproxy reports 0/0/0 bytes) >>>> - You didn't show the ngrep trace. The script uses nat=yes in >>>> the Route >>>> header of the INVITE to detect a nat'ed client. Can you >>>> verify that the >>>> reINVITE has the nat=yes? >>>> - You haven't showed the mediaproxy log (it will show the >>>> callers reporting >>>> in etc). That could help (default /var/log/messages) >>>> - You can put a log statement in the loose_route section >>>> after the test for >>>> nat=yes to see if use_media_proxy was called >>>> >>>> g-) >>>> >>>> Ricardo Martinez wrote: >>>>> Hello. >>>>> I'm having problems trying to make SER, NAT'd endpoints >>>> and reINVITE >>>>> work together. >>>>> I was using the "gw-pstn3.07.cfg" file from onsip.org to do some >>>>> tests, and this is what i have. In one side i have an >> Asterisk with >>>>> an endpoint registered in it (let's call it A). In the >> other side i >>>>> have a PAP2 under NAT (let's call it B). >>>>> >>>>> >>>>> A ---------- Asterisk ----------- SER ----------- B (NAT'd) >>>>> 200.0.0.7 200.0.0.6 200.0.0.5 >>>>> 10.0.0.4 >>>>> >>>>> When i make a call from "A" to "B" this is what i see (in terms of >>>>> SDP). Looking from SER. >>>>> >>>>> A --------- Asterisk ------------ SER ------------ B (NAT'd) >>>>> Public: >>>>> 200.0.0.4 >>>>> 200.0.0.7 200.0.0.6 200.0.0.5 >>>> Inside: >>>>> 10.0.0.1 >>>>> >>>>> INVITE >>>>> c:200.0.0.6:19996 >>>>> -------------------> >>>>> INVITE >>>>> c:200.0.0.5:35010 >>>>> ----------------> >>>>> >>>>> >>>>> Caller Via Called Status >>>>> Duration Codec Type Traffic >>>>> >>>> -------------------------------------------------------------- >>>> ------------ >>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - ?.?.?.?:? inactive 0'04" >>>>> Unknown Audio 0/0/0 >>>>> >>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out) >>>>> Session count: 1 >>>>> >>>>> So far is ok..........and the phone is answered >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <---------------- (the phone is >>>>> answered) >>>>> OK >>>>> c:200.0.0.5:35010 >>>>> <--------------------- >>>>> >>>>> reINVITE >>>>> c:200.0.0.7:19996 >>>>> ---------------------> >>>>> reINVITE >>>>> c:200.0.0.7:19996 >>>>> ----------------> >>>>> >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <---------------- >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <--------------------- >>>>> >>>>> Finally according to the "session" information : >>>>> >>>>> Caller Via Called >>>>> Status Duration Codec Type Traffic >>>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>>> ---------- >>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - 200.0.0.7:16420 inactive >>>>> 0'26" G729 Audio 0/11.48k/11.48k >>>>> >>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out) >>>>> Session count: 1 >>>>> And the audio is only in one way. :( >>>>> >>>>> So. you can see the reINVITE message apparently is not being >>>>> processed as a call to a NAT'd endpoint and therefore is not using >>>>> the mediaproxy, you can see the second "OK" messsage has >> the invalid >>>>> IP from the NAT'd user is in his sdp information. >>>>> As i said it before i am using the gw-pstn configuration >>>> file from the >>>>> onsip.org and as far as i can remember this configuration >> can handle >>>>> the reINVITE? isn't >>>>> I'm also using the last version of the mediaproxy (1.3.1). >>>>> Can someone tell me what i'm doing wrong? >>>>> >>>>> Hope someone could help me here. >>>>> Thanks in advance. >>>>> Regards... >>>>> >>>>> Ricardo Martinez.- >>>>> >>>>> _______________________________________________ >>>>> Serusers mailing list >>>>> serusers(a)lists.iptel.org >>>>> http://lists.iptel.org/mailman/listinfo/serusers [View Less]

1 0

Re: [Serusers] Problem : Can SER process the reINVITE messages properly?
by Greger V. Teigre 01 Aug '05

01 Aug '05

Ricardo, I think you are correct in your analysis of mediaproxy not accepting a third party. Also, I saw the post from somebody on the newest mediaproxy version. Have you tried it? Version 1.2.1 created a new session for reINVITEs, that's why the nat=yes is used in the ONsip.org configs. Version 1.3.0 added support for detecting that a reINVITE came in and would reuse the session (which I btw don't think is good for your scenario as you change the IP). 1.4.2 seems to address your problem,… [View More] so it would be interesting to hear if you have any success. As for the reINVITE with the IP address instead of domain, that's ok. g-) Ricardo Martinez wrote: > Hello Greger and SER users. > About this issue here are some test that i made. I added the > lookup("location") as you recommend me : > > # > > > > ----------------------------------------------------------------- # > Loose Route Section # > ----------------------------------------------------------------- if > (loose_route()) { > > if (has_totag() && (method=="INVITE" || > method=="ACK")) { lookup("location"); > if (isflagset(6) || client_nat_test("3") || > search("^Route:.*;nat=yes")){ > setflag(6); > use_media_proxy(); > }; > }; > > route(1); > break; > }; > > > Unfortunately, i'm still unable to have voice in both ways, but this > modification seems to handle better the reINVITE message. And this > is why. For the normal approach (i mean the initial onsip_pstn > configuration) the second INVITE was not using the mediaproxym as > Greger pointed. Now, as you can see in the debugs that i'm > attaching, the second invite is using the mediaproxy, and therefore > the "c" parameter in the SDP message is being correctly modified by > SER. So, i don't understand why this time the call is failing. Could > it be that mediaproxy is not capable to handle the reINVITEs?. For > example in the debug from mediaproxy (i'm also attaching this one), i > see a warning message like this : warning: Received packet from a > third party: 200.0.0.7:16432. It seems like mediaproxy is not > accepting "voice packets" from the second IP (the one indicated by > the reINVITE). Why? > Also, when the call is established this is the output from the > "session" command : > > Caller Via Called > Status Duration Codec Type Traffic > ---------------------------------------------------------------------------- > -------------------------------------- > 200.0.0.6:17480 - 200.0.0.5:35094 - 200.0.0.4:46115 inactive > 0'24" G729 Audio 0/16.75k/16.75k > > The call is established but between the first IP (Asterisk box) and > the endpoint public IP. > So, could this be a problem with mediaproxy?. I read the changelog > from the version 1.3.1 and this is what i found : > > Changes from version 1.2.1 to 1.3.0 > ----------------------------------- > > - Only create a new session if a request belongs to the first INVITE > (no longer creates new sessions on re-INVITEs) > > could it be related?. > > I also have a general question about the reINVITE. As you can see > the first INVITE has in his URI the domain name for the number : > 5555848114(a)sipvoiss.desarrollo.redvoiss.net (Frame 1 from the debug). > The reINVITE sent by Asterisk has the URI : 5555848114(a)200.0.0.4. Is > this ok?, despite of this the reINVITE is correctly redirected to the > endpoint. (You can check this in the frame 13 from the debug). > > Thanks again. > > Regards, > > Ricardo Martinez.- > > > >> -----Mensaje original----- >> De: Greger V. Teigre [mailto:greger@teigre.com] >> Enviado el: Miércoles, 20 de Julio de 2005 3:06 >> Para: Ricardo Martinez; serusers(a)lists.iptel.org >> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE >> messages properly? >> >> >> Hm. This was a tricky one. I would like to ask a second >> opinion from you >> NAT gurus on my musings below. What is the most appropriate >> response to >> Ricardo's scenario? WARNING to others: This is getting fairly >> technical on >> NAT/SDP... ;-) >> >> The reINVITE from Asterisk has a valid IP address and a valid >> (but new) SDP >> media ip (C=IN IP4 200.0.0.7). nat=yes is correctly not >> present in the >> reINVITE from Asterisk (it is not NATed). Thus >> use_media_proxy is correctly >> not used in the reINVITE, i.e. client_nat_test("3") and test >> on nat=yes will >> not trigger under the has_totag if statement (loose route >> processing): >> >> if (loose_route()) { >> >> if (has_totag() && (method=="INVITE" || method=="ACK")) { >> >> if (client_nat_test("3") || search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> }; >> >> route(1); >> break; >> }; >> >> In the OK from the Linksys: >> U 200.0.0.5:5060 -> 200.0.0.6:5060 >> SIP/2.0 200 OK. >> To: >> <sip:5555848114@sipvoiss.desarrollo.redvoiss.net>;tag=64d7492d >> b018b13ai0. From: "5565625858196" >> <sip:5565625858196@sipvoiss.desarrollo.redvoiss.net>;tag=as5d352c9a. >> Call-ID: >> 0848ef78297116742562204e2c04cbcb(a)sipvoiss.desarrollo.redvoiss.net. >> CSeq: 104 INVITE. >> Via: SIP/2.0/UDP 200.0.0.6:5060;branch=z9hG4bK518d870e. >> Record-Route: <sip:200.0.0.5;ftag=as5d352c9a;lr=on>. >> Contact: 5555848114 <sip:5555848114@200.0.0.4:46081>. >> Server: Linksys/PAP2-2.0.10(LSb). >> Content-Length: 237. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 33068 33068 IN IP4 192.168.15.200. >> s=-. >> c=IN IP4 192.168.15.200. >> t=0 0. >> m=audio 16424 RTP/AVP 18 100 101. >> a=rtpmap:18 G729/8000. >> a=rtpmap:100 NSE/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> ...you have 192.168.15.200, a private c= address in SDP, but >> the Contact has >> correctly been fixed (200.0.0.4:46081). So it seems the OK is >> processed >> correctly in onreply even though it does not show up in the >> debug. Flags 6 >> and 7 are not set, so use_media_proxy is correctly not run. >> The problem is >> that flag 6 should have been set (the Linksys is NATed), but >> as the reINVITE >> is not processed using lookup("location") the flag will not >> be picked up >> from usrloc. >> ---------------------------------------- >> >> However, now that Asterisk in the reINVITE is requesting >> another (valid) IP >> as media destination, the question is: what is propor behavior? >> >> The most natural would be to add a lookup("location") after: >> if (has_totag() && (method=="INVITE" || method=="ACK")) >> and then add isflagset(6) to the or test: >> if (isflagset(6) || client_nat_test("3") || >> search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> >> However, I'm not sure the lookup will work, because the R-URI >> is likely to >> be the direct address (5555848114@200.0.0.4:46081) and not >> the registered >> URI (@domain.com). It would be tempting to try to see if we >> somehow could >> make nat=yes set in the early INVITE. We would have to split the >> record_route section in two. One to handle !="REGISTER && >> !="INVITE" with a >> regular record_route() and wait until AFTER >> lookup("location") (maybe in >> route[1], the default handler) to add the following: >> if(method=="INVITE")){ >> if(isflagset(6)) { >> # INSERT YOUR IP ADDRESS HERE >> record_route_preset("192.0.2.13:5060;nat=yes"); >> } else { >> record_route(); >> } >> } >> >> This would make sure that not only dialogs where caller is >> nated, but also >> where callee is nated, will be tagged as nated. This again >> would cause >> nat=yes to be set and rtp proxy forced, further flag 6 is >> set, and thus the >> OK also processed with use_media_proxy(). >> >> BUT: Would this nat=yes cause any problems in other >> scenarios??? I'm not >> sure, but I don't think so. If that is correct, this is >> maybe the right >> solution. >> --------------------------------------- >> OTHER (SIMPLER?) SOLUTIONS: >> ---------- >> Instead you could add ||client_nat_test("1") together with >> isflagset 6 and 7 >> in your reply route: >> if ((isflagset(6) || isflagset(7) || client_nat_test("1")) && >> (status=~"(180)|(183)|2[0-9][0-9]")) >> >> but it will not work because the reINVITE did not get >> use_media_proxy(). >> >> Or, you could instead add fix_nated_sdp("2"); in your onreply route: >> if (client_nat_test("1")) { >> fix_nated_contact(); >> fix_nated_sdp("2"); >> }; >> WARNING! You will have to add else in between this test and >> the previous to >> avoid messing up use_media_proxy(). >> >> This will fix the SDP (c=IN IP4), but it will probably not >> help, because the >> port is still unknown. You could use "3" instead in >> fix_nated_sdp, this >> will add direction=active to the OK. However, another thread >> stated that >> Asterisk does not support direction=active. If it does, it >> will probably >> work and you get a non-proxied stream between Asterisk and >> the Linksys. >> >> Or finally, the third option would be to add the (hopefully) >> fixed IP in the >> loose_route test: >> if (src_ip==200.0.0.6 || client_nat_test("3") || >> search("^Route:.*;nat=yes")) { >> setflag(6); >> use_media_proxy(); >> }; >> >> This would cause the OK automatically to get use_media_proxy. >> >> Ricardo, could you please test these various solutions and >> see if they >> really work or if (where...) I go wrong :-) >> g-) >> >> Ricardo Martinez wrote: >>> Hello Greger. >>> Thanks for your answer on this topic. Now i'm attaching more debug >>> information (the /var/log/messages from mediaproxy, the ngrep output >>> and some xlog statements in the ser.cfg file) beside some >> comments in >>> the file reINVITE_debug_problem.txt. >>> >>>> - Is your session really set up initially (before the reINVITE)? >>>> (mediaproxy reports 0/0/0 bytes) >>> >>> At least i have ringback tone. Then, when the call is answered i >>> have an OK and a ACK message coming to my SER box, then inmediatly >>> the reINVITE message arrives Asterisk box. >>> >>> >>> For what i can see from the debug the "nat=yes" is never reached >>> because the caller has a "valid ip" and therefore the first "if" in >>> the statament >>> >>> if (method=="INVITE" && client_nat_test("3")) { >>> # INSERT YOUR IP ADDRESS HERE >>> record_route_preset("64.76.148.246:5060;nat=yes"); >>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION : >>> invite & client_nat_test(3) TRUE ,record_route_preset [%rm]\n"); >>> } else if (method!="REGISTER") { >>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION : >>> record_route [%rm]\n"); >>> record_route(); >>> }; >>> >>> from the RECORD ROUTE SECTION is FALSE. >>> >>> Also, i don't understand why the second OK (the one from the >>> reINVITE) is not procesed in the ONREPLY ROUTE, or at least i don't >>> see any statement from the "xlog" in the debug. Is this normal? >>> >>> Thanks.! >>> Regards, >>> >>> Ricardo Martinez.- >>> >>> >>>> -----Mensaje original----- >>>> De: Greger V. Teigre [mailto:greger@teigre.com] >>>> Enviado el: Lunes, 18 de Julio de 2005 2:45 >>>> Para: Ricardo Martinez; serusers(a)lists.iptel.org >>>> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE >>>> messages properly? >>>> >>>> >>>> Hi Ricardo, >>>> Thanks for a detailed analysis. Some questions: >>>> - Is your session really set up initially (before the reINVITE)? >>>> (mediaproxy reports 0/0/0 bytes) >>>> - You didn't show the ngrep trace. The script uses nat=yes in >>>> the Route >>>> header of the INVITE to detect a nat'ed client. Can you >>>> verify that the >>>> reINVITE has the nat=yes? >>>> - You haven't showed the mediaproxy log (it will show the >>>> callers reporting >>>> in etc). That could help (default /var/log/messages) >>>> - You can put a log statement in the loose_route section >>>> after the test for >>>> nat=yes to see if use_media_proxy was called >>>> >>>> g-) >>>> >>>> Ricardo Martinez wrote: >>>>> Hello. >>>>> I'm having problems trying to make SER, NAT'd endpoints >>>> and reINVITE >>>>> work together. >>>>> I was using the "gw-pstn3.07.cfg" file from onsip.org to do some >>>>> tests, and this is what i have. In one side i have an >> Asterisk with >>>>> an endpoint registered in it (let's call it A). In the >> other side i >>>>> have a PAP2 under NAT (let's call it B). >>>>> >>>>> >>>>> A ---------- Asterisk ----------- SER ----------- B (NAT'd) >>>>> 200.0.0.7 200.0.0.6 200.0.0.5 >>>>> 10.0.0.4 >>>>> >>>>> When i make a call from "A" to "B" this is what i see (in terms of >>>>> SDP). Looking from SER. >>>>> >>>>> A --------- Asterisk ------------ SER ------------ B (NAT'd) >>>>> Public: >>>>> 200.0.0.4 >>>>> 200.0.0.7 200.0.0.6 200.0.0.5 >>>> Inside: >>>>> 10.0.0.1 >>>>> >>>>> INVITE >>>>> c:200.0.0.6:19996 >>>>> -------------------> >>>>> INVITE >>>>> c:200.0.0.5:35010 >>>>> ----------------> >>>>> >>>>> >>>>> Caller Via Called Status >>>>> Duration Codec Type Traffic >>>>> >>>> -------------------------------------------------------------- >>>> ------------ >>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - ?.?.?.?:? inactive 0'04" >>>>> Unknown Audio 0/0/0 >>>>> >>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out) >>>>> Session count: 1 >>>>> >>>>> So far is ok..........and the phone is answered >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <---------------- (the phone is >>>>> answered) >>>>> OK >>>>> c:200.0.0.5:35010 >>>>> <--------------------- >>>>> >>>>> reINVITE >>>>> c:200.0.0.7:19996 >>>>> ---------------------> >>>>> reINVITE >>>>> c:200.0.0.7:19996 >>>>> ----------------> >>>>> >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <---------------- >>>>> OK >>>>> c:10.0.0.1:16440 >>>>> <--------------------- >>>>> >>>>> Finally according to the "session" information : >>>>> >>>>> Caller Via Called >>>>> Status Duration Codec Type Traffic >>>>> >>>> -------------------------------------------------------------- >>>> -------------- >>>>> ---------- >>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - 200.0.0.7:16420 inactive >>>>> 0'26" G729 Audio 0/11.48k/11.48k >>>>> >>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out) >>>>> Session count: 1 >>>>> And the audio is only in one way. :( >>>>> >>>>> So. you can see the reINVITE message apparently is not being >>>>> processed as a call to a NAT'd endpoint and therefore is not using >>>>> the mediaproxy, you can see the second "OK" messsage has >> the invalid >>>>> IP from the NAT'd user is in his sdp information. >>>>> As i said it before i am using the gw-pstn configuration >>>> file from the >>>>> onsip.org and as far as i can remember this configuration >> can handle >>>>> the reINVITE? isn't >>>>> I'm also using the last version of the mediaproxy (1.3.1). >>>>> Can someone tell me what i'm doing wrong? >>>>> >>>>> Hope someone could help me here. >>>>> Thanks in advance. >>>>> Regards... >>>>> >>>>> Ricardo Martinez.- >>>>> >>>>> _______________________________________________ >>>>> Serusers mailing list >>>>> serusers(a)lists.iptel.org >>>>> http://lists.iptel.org/mailman/listinfo/serusers [View Less]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users August 2005