sr-users June 2005

sr-users@lists.kamailio.org

241 participants
595 discussions

Re: [Serusers] add_rcv_param() for INVITEs

by Klaus Darilion

Hi Martin! As far as I understand, the problem is not the initial INVITE, but the in-dialog request, which use the fixed contact in the request URI. Correct? Do you have problems with certain clients or is it an academical question? regards, klaus Martin Koenig wrote: > Hello Klaus, > > I know that fix_nated_register works for REGISTERs, the question was > whether add_rcv_param() works for INVITEs ;) > > Answer: It does not. > > Regards, > Martin > > Klaus Darilion wrote: > >> I thin k I solved the problem using fix_nated_register instead of >> fix_nated_contact for REGISTER messages. (using nathelper) >> >> regards, >> klaus >> >> Martin Koenig wrote: >> >>> Hello, >>> >>> is it possible to use add_rcv_param() also for Contact-HF of INVITEs, >>> instead of fix_nated_contact()? >>> >>> This would make sure that the NATed End Device gets fed exactly the >>> contact as R-URI that it announced in the INVITE: >>> >>> Example R-URI in Loose-Route Requests for fix_nated_contact(): >>> >>> Ser (1.2.3.4): >>> INVITE device(a)4.5.6.7 >>> Route: 1.2.3.4;lr=on >>> >>> Device (10.0.0.1, NAT 4.5.6.7): >>> INVITE device(a)123.123.123.123 >>> >>> With add_rcv_param(): >>> >>> Ser: >>> INVITE device(a)10.0.0.1;rcv_param=4.5.6.7 >>> Route: 1.2.3.4;lr=on >>> >>> Device: >>> INVITE device(a)10.0.0.1 >>> >>> The problem is that the End-Device, in the fix_nated_contact() >>> callflow, has to accept a Request that is not really for this device >>> (IP in Request-URI != IP of the Device). Imagine a Ser checkip uri == >>> myself. This would fail without knowing the public IP of the NAT and >>> hard-conding it into Ser.cfg. >>> >>> Does Ser support the rcv_param in Request-URI also? >>> >>> What do you think? Any experience on this? >>> >>> Regards, >>> Martin >>> >>> _______________________________________________ >>> Serusers mailing list >>> serusers(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >>> >> > >

19 years

[Serusers] ERROR: t_get_trans_ident: no transaction found

by Roger Lewau

Whenever I make a call I get these entries in the log.... Jun 7 17:56:29 ns2 ser[520]: WARNING: script writer didn't release transaction Jun 7 17:56:42 ns2 ser[522]: ERROR: t_get_trans_ident: no transaction found Jun 7 17:56:42 ns2 ser[522]: assemble_msg: t_get_trans_ident failed Jun 7 17:56:42 ns2 ser[522]: ERROR:tm:t_write_req: Error int assemble_msg Jun 7 17:56:42 ns2 ser[522]: ERROR: t_reply: cannot send a t_reply to a message for which no T-state has been established If the user is online I get connected properly, if user is offline I get connected to sems. So It seems to be working after all. But I had this config running for three days then I got a lot of errors regarding t_newtran and out of memory... and phones lost their registration. Also does any have any idea where to put t_release() to avoid the first WARNING message... This is my ser.cfg debug=3 fork=yes log_stderror=no listen=212.247.91.237 port=5060 children=4 alias=sip.serverhallen.com dns=no rev_dns=no fifo_mode=0666 fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" #LADDA IN DE MODULER VI BEHÖVER #--------------------------------------------------------------------------- ------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" #MySQL database support loadmodule "/usr/local/lib/ser/modules/sl.so" #Stateless replies loadmodule "/usr/local/lib/ser/modules/tm.so" #Transaction Management loadmodule "/usr/local/lib/ser/modules/rr.so" #Routing and Record-Routing loadmodule "/usr/local/lib/ser/modules/maxfwd.so" #Max-Forwards check loadmodule "/usr/local/lib/ser/modules/usrloc.so" #User location support loadmodule "/usr/local/lib/ser/modules/registrar.so" #Registrar loadmodule "/usr/local/lib/ser/modules/auth.so" #Common functions for digest authentication loadmodule "/usr/local/lib/ser/modules/auth_db.so" #Database support for digest authentication loadmodule "/usr/local/lib/ser/modules/uri.so" #Various URI checks loadmodule "/usr/local/lib/ser/modules/uri_db.so" #URI checking using DB loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" #RTP Mediaproxy for NATed UAs loadmodule "/usr/local/lib/ser/modules/nathelper.so" #Functions to handle NAT traversal loadmodule "/usr/local/lib/ser/modules/textops.so" #Message Textual Operations loadmodule "/usr/local/lib/ser/modules/avpops.so" #avp operations, pseudo-variable support loadmodule "/usr/local/lib/ser/modules/domain.so" #checks if a host part of an URI is "local" or not. loadmodule "/usr/local/lib/ser/modules/permissions.so" #determine if a call has appropriate permission to be established #VARIABLER FÖR DATABAS OCH HANTERINGA AUTENTISIERING #--------------------------------------------------------------------------- ------------------- modparam("auth_db|permissions|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) #VARIABLER FÖR HANTERING AV NATade UAs #--------------------------------------------------------------------------- -------------------- 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) #VARIABLER FÖR HANTERING AV PSTN #--------------------------------------------------------------------------- -------------------- modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") #MEDDELANDEHANTERING AV SIP MEDDELANDEN #--------------------------------------------------------------------------- -------------------- #Alla meddelanden kommer behandlas enligt detta regelverk i sekventiell ordning route { # ----------------------------------------------------------------- # Sanity Check Section, Kontrollera hur många gånger ett meddelande tagits emot. # ----------------------------------------------------------------- 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, Sektion som lägger till vår egen sip server i routing kedjan så att svaren kommer tillbaka till oss. # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { record_route_preset("212.247.91.237:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Call Tear Down Section, Denna sektion hanterar nedtagning av samtal # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { # end_media_session(); # if(!t_write_req("/tmp/am_fifo","bye")) { t_reply("500","error contacting sems"); }; }; # ----------------------------------------------------------------- # Loose Route Section, # ----------------------------------------------------------------- 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; }; # ----------------------------------------------------------------- # Call Type Processing Section, om meddelandet inte skulle skickas vidare är det förmodligen riktat till SER # ----------------------------------------------------------------- if (uri!=myself) { route(5); route(1); break; }; if (uri==myself) { # switch to statefull mode: if (!t_newtran()){ sl_send_reply("500","could not create transaction"); break; }; if (method=="ACK") { route(6); break; } else if (method=="CANCEL") { route(3); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (uri!=myself) { route(5); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User not found"); break; }; }; log("NO MATCH"); route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler, Standardhantering av Meddelanden # ----------------------------------------------------------------- t_on_reply("1"); if (!t_relay()){ if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!search("^Contact:\ +\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); }; 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] { # ----------------------------------------------------------------- # CANCEL and INVITE Message Handler # ----------------------------------------------------------------- if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (method=="INVITE" && !allow_trusted()) { 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 (uri=~"^sip:[+|00][0-9]*@") { route(4); break; }; if (uri=~"^sip:0[1-9]*@") { route(4); break; }; if (uri=~"sip:100.*@") { if(!t_write_req("/tmp/am_fifo","conference")) { t_reply("500","error contacting sems"); }; break; }; if (!lookup("location")) { #Send caller to users answering machine if uri is local if(!t_write_req("/tmp/am_fifo","voicemail")) { t_reply("500","error contacting sems"); }; break; }; if (method=="CANCEL") { route(1); break; }; route(5); route(1); } route[4] { # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- rewritehost(" 192.168.0.1 "); avp_write("i:45", "inv_timeout"); route(5); route(1); } route[5] { # ----------------------------------------------------------------- # RTP Proxy Enabler, aktiverar proxyn # ----------------------------------------------------------------- if (isflagset(6) || isflagset(7)) { use_media_proxy(); }; } route[6] { # ------------------------------------------------------------------------ # ACK Handler # ------------------------------------------------------------------------ # ------------------------------------------------------------------------ # Aliases Section, hanterar acks # ------------------------------------------------------------------------ lookup("aliases"); if (uri!=myself) { route(1); break; }; lookup("location"); route(1); } onreply_route[1] { 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(); }; }

19 years

RE: [Serusers] Mediaproxy in LAN (?)

by a cairo

Thanks, but if all clients connect to ser how balancing happen from mediaproxy? -----Original Message----- From: "Shaikat Mahmud" <shaikat(a)stitel.com> To: "'a cairo'" <a.cairo(a)scsitalia.it>, "'Giudice, Salvatore'" <Salvatore.Giudice(a)FMR.COM>, "'bogdan aux'" <aux1d(a)yahoo.com>, <serusers(a)lists.iptel.org> Date: Sat, 4 Jun 2005 16:29:36 +0600 Subject: RE: [Serusers] Mediaproxy in LAN (?) > Hi, > > In mediaproxy, README file has all the architectural information. > > Is mediaproxy between client and ser? > No, its some thing like below, > > > Ua1--------------> SER-------------->UA2 > | > | (Mediaproxy module requesting for a session) > | > | > | > MediaProxy > > > Then RTP flow will be like following: > Ua1 <-------> MediaProxy <-------> Ua2 > > Read the README file for details. > shaikat > > > -----Original Message----- > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On > Behalf Of a cairo > Sent: Saturday, June 04, 2005 4:14 PM > To: Giudice, Salvatore; bogdan aux; serusers(a)lists.iptel.org > Subject: RE: [Serusers] Mediaproxy in LAN (?) > > Hi all, > i don't understand architecture of mediaproxy with ser ! > Is mediaproxy between client and ser? > Thanks > > -----Original Message----- > From: "Giudice, Salvatore" <Salvatore.Giudice(a)FMR.COM> > To: "bogdan aux" <aux1d(a)yahoo.com>, <serusers(a)lists.iptel.org> > Date: Tue, 17 May 2005 20:10:46 -0400 > Subject: RE: [Serusers] Mediaproxy in LAN (?) > > > I am trying to route a call from a non-routable 10.x.x.x network to a > > phone on the internet using ser 0.9.0 and mediaproxy 1.31. Aka: PSTN > to > > SIP from my asterisk to an x-lite > > > > I found some references indicating that I should call: > > > > > > if ( src_ip = IP_GATEWAY) > > { > > force_rport(); > > fix_contact(); > > use_media_proxy(); > > }; > > > > Supposedly, you need the force_rport and the fix_contact to put media > > proxy in the middle of the two rtp sessions, but I have et to see > this > > actually work. Has anyone been able to pass a call through media > proxy > > from a GW on a non-routable to a routable network, or even between > two > > ip's on the same network as the mediaproxy? > > > > If so, please share your configs. > > > > -----Original Message----- > > From: bogdan aux [mailto:aux1d@yahoo.com] > > Sent: Friday, May 13, 2005 6:16 AM > > To: serusers(a)lists.iptel.org > > Subject: [Serusers] Mediaproxy in LAN (?) > > > > I want to route RTP packets between 2 computers in the > > same network through Mediaproxy. I know this may have > > no sense, but it's just a test configuration. > > The call use_media_proxy() seems to have no effect, > > the RTP packets go directly from one computer to > > another. > > My guess is mediaproxy makes a test on the IPs (they > > are 192.168.147.2 and 192.168.147.3) and refuses to > > proxy the call. > > Is mediaproxy working just between different networks > > or it's an error in my configuration file? > > > > > > > > > > Yahoo! Mail > > Stay connected, organized, and protected. Take the tour: > > http://tour.mail.yahoo.com/mailtour.html > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers >

19 years

[Serusers] Re-routing to same device in failure_route

by Karun Chemudugunta

Hi Group, Cisco 5300 -----> SER ----> Xten softphone-A ----> Failed call with error code >400 -------> try to route to Xten softphone A(same as previous) I am trying to route calls to softphones in such way that, if call failed by some reason (>400), trying to route second time to the same soft phone using append_brach() and t_relay() like below. But, soft phone is unable process INVITE message for some reason. But, if I forward failed call different soft phone, call was successful. Am I doing any thing wrong in config ??? Thanks for your help in advance. Regards, Karun ########################################################################################## # # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ #debug=9 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode debug=7 fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) #dns=no # (cmd. line: -r) #rev_dns=no # (cmd. line: -R) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/ser_fifo" #alias=voip.cafe.bevocal.com #alias=66.77.14.238 alias=209.233.189.177 alias=voice.engca.bevocal.com # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "/usr/lib/ser/modules/mysql.so" 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/exec.so" loadmodule "/usr/lib/ser/modules/textops.so" #loadmodule "/usr/lib/ser/modules/acc.so" #modparam("acc", "log_level", 2) #modparam("acc", "log_flag", 1) #modparam("acc", "report_cancels", 1) #modparam("acc", "failed_transactions", 1) # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/lib/ser/modules/auth.so" #loadmodule "/usr/lib/ser/modules/auth_db.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) # ------------------------- 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; }; # 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 # record_route(); # loose-route processing if (loose_route()) { t_relay(); 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; }; if(method=="INVITE") { log(1,"about lookup in route zero"); if (!lookup("location")) { log(1,"lookup failed :SIP request from config"); sl_send_reply("404", "Not Found"); break; }; t_on_failure("5"); }; }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); }; } failure_route[5] { log(1,"Inside failure_route five"); revert_uri(); append_branch(); if (!lookup("location")) { log(1,"lookup failed :SIP request from config"); t_reply("404", "Not Found"); break; }; if (!t_relay()) { sl_reply_error(); }; } ######################################################################################

19 years

[Serusers] Re: [Serdev] ENUM issues - req. for discussion

by Samuel Osorio Calvo

Hi Klaus, responses inline...(command and file names are taken from my memory, so don't pay much attention at the spelling) Samuel. Unclassified. >>> Klaus Darilion <klaus.mailinglists(a)pernau.at> 06/07/05 01:43PM >>> >Hi all! > >Some time of using ser with ENUM revealed several problems which I would >like to dicuss with you. Be aware - this email is long! > >ENUM is a wonderful thing for call routing nevertheless, as it is DNS >based there are some important things an ENUM aware application has to >consider: > 1. You never know how long the lookup takes > 2. You never know if the lookup will fail or succeed > 3. If the lookup was successful, you never may trust the result> > >I will explain this points in detail know: > >1+2: >Using enum, the application is giving control to the DNS resolver of the >OS and the DNS infrastructure. Thus, the ser thread which performs the >ENUM lookup will be blocked until there is a result from the system's >DNS resolver. > >If DNS is slow, or misconfigured (e.g. a zone is delegated to a >nameserver which is down), the thread will be blocked for several >seconds. E.g. if you use debian woody and 2 nameservers in >/etc/resolv.conf, the timeout is 20 seconds. If you are lucky, the OS >allows configuration of the DNS timeouts. Nevertheless, you have to >consider that a ser thread will be blocked up to 20 seconds. This has >impacts on your configuration: I don't know the details but would it be really difficult to use an asyncrhonous resolver, such as resiprocate SIP stack does with ARES?? Besides exec_* calls, the main SER's performance bottelneck is the DNS resolving step thus it would be a great improvement adding asyncronous DNS queries. >Typically, you use some kind of the following logic: >if (uri =~ "+[0-9].") { > if (enum_lookup()) { > t_relay(); break; > } else { > forward to PSTN gateway; break; > } >} > >Thus, the INVITE will be received and the ENUM lookup will be performed. >If the lookup will take longer than 0.5s, the SIP client will start >restransmitting the INVITE. Thus, another thread will process this >INVITE and enother ENUM lookup will be performed. After several seconds, >all of ser's threads will be blocked with ENUM lookups and your SIP >proxy will not handle any requests until the DNS query times out. Thus, >it is very easy to generate a DoS attack against the proxy. >Another funny thing is, that the SIP client will detect a proxy error >and hangs up, but the INVITEs are still processed in the SIP proxy and >after the timeout forwarded to the PSTN gateway. > >A solution to stop the retransmission is to immediatle >sl_send_reply("100","Trying"), But this rises another problem. Now, if >the caller hangs up before the DNS timeout, the SIP client will send >CANCEL (as it received 100) to the SIP proxy. But the SIP proxy can not >cancel the transaction, as it is not genereated yet - the INVITE thread >is still waiting for the ENUM lookup and the transaction will be >generated after the ENUM lookup (after 20s timeout). Thus, we still end >up with an INVITE forwarded to the PSTN gateway although the SIP client >already hang up. > >I thought of using t_newtran and t_forward_nonack_uri instead of t_realy >to generate the transaction before doing the ENUM lookup. Thus, the >thread which will process the CANCEL should find a transaction and stop >it. But will this really prevent the INVITE sent to the PSTN gateway, >once the DNS times out? (not tested) I think the best way would be to add a reply(100) AND t_forward_nonack, something like: sl_send_reply("100","Trying"); t_newtran(); uri =~ "+[0-9].") { if (enum_lookup()) { t_forward_nonack(); break;} else{ t_forward_nonac();break; } But it adds a complexity level which will lead to many non-working config files......but I vote for it! > >btw: this problem does not only occour for ENUM lookups, but for all DNS >lookups (SRV, A, AAAA). > >3: >If the ENUM lookup succeeds, you never may trust the result. It may be a >invalid SIP URI, or a tel: URI, or anything else a user puts into its >NAPTRs. This may result in a failed transaction, or like revealed at the >ENUM plugtest in failed accounting. Even worse, maybe it is possible to >complete crash ser using realy bad formated URIs? > >Thus you can't avoid doing some URI checks against the URI received from >the ENUM lookup. Perfomance issues are no valid arguements! Once I give >control to external services (DNS, radius, exec), the perfomance >penalties due to parsing the SIP URI are much more less than due to the >ENUM lookup. > >In case of ser, I would do the URI parsing in the ENUM module, or maybe >generate a dedicated function/module for checking SIP URIs inside the >routing logic. Thus, I can also check the result of exec calls. Since URI check is a really global action, it should be implemented in SER's core, providing commands to the config file (something like uri_check(To|From|Req-URI|Contact) ) and functions to be called from any module. > >I'm eagerly waiting for your opinions. > >regards, >Klaus _______________________________________________ Serdev mailing list serdev(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev

19 years

[Serusers] Re: RADIUS failure for long domains returned by ENUM queries

by Adrian Georgescu

Juha, what if the response from DNS is greater then 253 bytes? Juha Heinanen wrote: >adrian, > >the value of the attribute that you try to add is 202 bytes long. >my /usr/include/radiusclient.h defines > >#define AUTH_STRING_LEN 128 /* maximum of 253 */ > >typedef struct value_pair >{ > char name[NAME_LENGTH + 1]; > int attribute; > int type; > UINT4 lvalue; > char strvalue[AUTH_STRING_LEN + 1]; > struct value_pair *next; >} VALUE_PAIR; > >thus the value is too long and would fail. > >on the other hand, my /usr/include/radiusclient-ng defines: > >#define AUTH_STRING_LEN 253 /* maximum of 253 */ > >which one are you using in your test setup? > >-- juha > >

19 years

[Serusers] ENUM issues - req. for discussion

by Klaus Darilion

Hi all! Some time of using ser with ENUM revealed several problems which I would like to dicuss with you. Be aware - this email is long! ENUM is a wonderful thing for call routing nevertheless, as it is DNS based there are some important things an ENUM aware application has to consider: 1. You never know how long the lookup takes 2. You never know if the lookup will fail or succeed 3. If the lookup was successful, you never may trust the result I will explain this points in detail know: 1+2: Using enum, the application is giving control to the DNS resolver of the OS and the DNS infrastructure. Thus, the ser thread which performs the ENUM lookup will be blocked until there is a result from the system's DNS resolver. If DNS is slow, or misconfigured (e.g. a zone is delegated to a nameserver which is down), the thread will be blocked for several seconds. E.g. if you use debian woody and 2 nameservers in /etc/resolv.conf, the timeout is 20 seconds. If you are lucky, the OS allows configuration of the DNS timeouts. Nevertheless, you have to consider that a ser thread will be blocked up to 20 seconds. This has impacts on your configuration: Typically, you use some kind of the following logic: if (uri =~ "+[0-9].") { if (enum_lookup()) { t_relay(); break; } else { forward to PSTN gateway; break; } } Thus, the INVITE will be received and the ENUM lookup will be performed. If the lookup will take longer than 0.5s, the SIP client will start restransmitting the INVITE. Thus, another thread will process this INVITE and enother ENUM lookup will be performed. After several seconds, all of ser's threads will be blocked with ENUM lookups and your SIP proxy will not handle any requests until the DNS query times out. Thus, it is very easy to generate a DoS attack against the proxy. Another funny thing is, that the SIP client will detect a proxy error and hangs up, but the INVITEs are still processed in the SIP proxy and after the timeout forwarded to the PSTN gateway. A solution to stop the retransmission is to immediatle sl_send_reply("100","Trying"), But this rises another problem. Now, if the caller hangs up before the DNS timeout, the SIP client will send CANCEL (as it received 100) to the SIP proxy. But the SIP proxy can not cancel the transaction, as it is not genereated yet - the INVITE thread is still waiting for the ENUM lookup and the transaction will be generated after the ENUM lookup (after 20s timeout). Thus, we still end up with an INVITE forwarded to the PSTN gateway although the SIP client already hang up. I thought of using t_newtran and t_forward_nonack_uri instead of t_realy to generate the transaction before doing the ENUM lookup. Thus, the thread which will process the CANCEL should find a transaction and stop it. But will this really prevent the INVITE sent to the PSTN gateway, once the DNS times out? (not tested) btw: this problem does not only occour for ENUM lookups, but for all DNS lookups (SRV, A, AAAA). 3: If the ENUM lookup succeeds, you never may trust the result. It may be a invalid SIP URI, or a tel: URI, or anything else a user puts into its NAPTRs. This may result in a failed transaction, or like revealed at the ENUM plugtest in failed accounting. Even worse, maybe it is possible to complete crash ser using realy bad formated URIs? Thus you can't avoid doing some URI checks against the URI received from the ENUM lookup. Perfomance issues are no valid arguements! Once I give control to external services (DNS, radius, exec), the perfomance penalties due to parsing the SIP URI are much more less than due to the ENUM lookup. In case of ser, I would do the URI parsing in the ENUM module, or maybe generate a dedicated function/module for checking SIP URIs inside the routing logic. Thus, I can also check the result of exec calls. I'm eagerly waiting for your opinions. regards, Klaus

19 years

[Serusers] outbound proxy

by harry gaillac

Hello ser users, I wish all sip message are handle by ser. phone1 -------------------------- | ser+mediaproxy|------internet phone2 -------------------------- In order to send all sip messages via ser I set outbound sip proxy (ser/public ip) for sip clients. However ser don't route invite message for other domains.Why? Harry # $Id: ser.cfg,v 1.27 2005/03/10 14:16:25 andrei Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) #memlog=5 # memory debug log level #log_facility=LOG_LOCAL0 # sets the facility used for logging (see syslog(3)) /* 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" fifo_db_url="mysql://ser:heslo@localhost/ser" user=root group=ser fifo_user=root # owner of the ser fifo fifo_group=ser fifo_mode=0660 # fifo's permissions #disable_core=yes #disables core dumping #open_fd_limit=1024 # sets the open file descriptors limit #mhomed=yes # usefull for multihomed hosts, small performance penalty #disable_tcp=yes #tcp_accept_aliases=yes # accepts the tcp alias via option (see NEWS) listen=80.119.9.14 # # ------------------ module loading ---------------------------------- loadmodule "/usr/lib/ser/modules/mysql.so" 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/uri.so" loadmodule "/usr/lib/ser/modules/nathelper.so" loadmodule "/usr/lib/ser/modules/mediaproxy.so" loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_db.so" loadmodule "/usr/lib/ser/modules/textops.so" loadmodule "/usr/lib/ser/modules/permissions.so" loadmodule "/usr/lib/ser/modules/group.so" loadmodule "/usr/lib/ser/modules/domain.so" loadmodule "/usr/lib/ser/modules/avpops.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params-- modparam("usrloc", "db_mode", 2) # -- autdb_params-- modparam("auth_db", "calculate_ha1", yes) 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 params -- modparam("nathelper", "natping_interval", 0) modparam("nathelper", "rtpproxy_disable", 1) # --mediaproxy param -- modparam("mediaproxy", "natping_interval", 30) modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy.sock") # -- registrar params -- modparam("registrar", "nat_flag", 6) # -- tm params -- modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") # --domain params -- modparam("domain", "db_mode", 1) # Use caching # -- permissions params -- modparam("permissions", "db_url", "mysql://ser:heslo@localhost/ser") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") modparam("permissions", "default_deny_file", "/etc/ser/permissions.deny") modparam("permissions", "default_allow_file", "/etc/ser/permissions.allow") # ------------------------- 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; }; # 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(); }; if (method=="CANCEL" || method=="BYE") { end_media_session(); }; # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { if (has_totag() && method=="INVITE" || method=="ACK") { if (nat_uac_test("3")) { setflag(6); force_rport(); fix_contact(); }; use_media_proxy(); }; route(1); break; }; # Requests to others domains if (!is_from_local()) { # 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 (is_from_local()) { if (method=="CANCEL") { route(3); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; }; } route[1] { ########################### # Default Message Handler # ########################### t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { end_media_session(); }; sl_reply_error(); }; } route[2] { ############################ # Register Message Handler # ############################ if (nat_uac_test("3")) { setflag(6); force_rport(); fix_contact(); }; if (!www_authorize("nxs.yi.org", "subscriber")) { www_challenge("nxs.yi.org", "0"); sl_send_reply("401", "Unauthorized"); break; }; if (!save("location")) { sl_reply_error(); break; }; } route[3] { ############################# # CANCEL and INVITE handler # ############################# if (nat_uac_test("3")) { setflag(6); }; if (isflagset(6)) { force_rport(); fix_contact(); use_media_proxy(); }; if (!is_from_local()) { route(1); break; }; # SIP destinations from PSTN if (src_ip==192.168.0.50 && allow_trusted()) { route(4); } else if (src_ip==192.168.0.50 && !allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); sl_send_reply("403", "Forbidden"); break; }; }; # SIP destinations to PSTN if (uri=~"^sip:1013@.*$" || uri=~"^sip:[0-9]{10}@.*$" || uri=~"^sip:06[0-9]{8}@.*$") { route(5); route(1); break; }; # native SIP destinations are handled using our USRLOC DB lookup("aliases"); if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); break; } _____________________________________________________________________________ Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

19 years

[Serusers] Re: Welcome to the "Serusers" mailing list (Digest mode)

by gsalvucci＠ing.unrc.edu.ar

Mensaje citado por serusers-request(a)lists.iptel.org: > Welcome to the serusers(a)lists.iptel.org mailing list! > > To post to this list, send your email to: > > serusers(a)lists.iptel.org > > General information about the mailing list is at: > > http://lists.iptel.org/mailman/listinfo/serusers > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > http://lists.iptel.org/mailman/options/serusers/gsalvucci%40ing.unrc.edu.ar > > > You can also make such adjustments via email by sending a message to: > > serusers-request(a)lists.iptel.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > hipolita > > Normally, Mailman will remind you of your iptel.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > > ---------------------------------------------------------------- Este mensaje ha sido enviado usando el servicio de Webmail de la Universidad Nacional de Río Cuarto. Basado en Horde/IMP

19 years

[Serusers] setting up SER

by Tomasz Gingold

Hello, i´m fairly new in SER. After setting up the SER i tried to register at SER with the kphone. Inside the kphone i set up the Outbound proxy with the adress of the SER. When i try to REGISTER with the kphone at SER i get always also a REGISTER message back from the SER. Kphone SER -----REGISTER---------> <----REGISTER---------- (the first REGISTER follow 3xREGISTER back) <----REGISTER---------- <----REGISTER---------- -----REGISTER---------> <----REGISTER---------- -----REGISTER---------> <----REGISTER---------- -----REGISTER---------> <----REGISTER---------- ... <----403 Timeout------- It looks like the SER doesn't go into the routing logic. I modify the ser.cfg in this way to check this. route { sl_send_reply("420","Bad Extension"); After this nothing has changed in the packet flow described before. No 420 replys are beeing send back. I know that this is not a detailed description of my problem.Anyhow i hope that anybody can give me some tips. thanks in advance tomasz g. -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++

19 years

← Newer
1
...
45
46
47
48
49
50
51
...
60
Older →

Jump to page:

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 June 2005