sr-users

sr-users@lists.kamailio.org

50 participants
37106 discussions

by Maxim Sobolev

Folks, Attached please find several patches for ser 0.8.10. They do the following: 1. Removes hardcoded `/usr/local' from Makefiles and replaces it with LOCALBASE variable setable in the top Makefile.defs. This should make life of packagers easier. 2. Allows to override PREFIX variable with something else from environment. 3. Adds support for FreeBSD doc/man directories layout. 4. Adds some missed -I's into radius modules. 5. Fixes radius modules to use the same symbolic avp names as in dictionary. 6. Adds support for recording source port in msg structure and adds it in "Noisy feedback". This should be extremely useful for debugging various SIP&NAT scenarios and later could be re-used to implement `rport' support described in my previous message. It would be nice to have those patches integrated into the next release. Thanks! -Maxim

21 years, 3 months

[Serusers] Record-route:/Contact: conflict?

by Greg Fausak

I've got a packet that looks like: # U 2003/02/24 07:56:52.503535 216.87.144.203:5060 -> 216.87.145.22:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r. From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc. To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532. Date: Mon, 24 Feb 2003 13:56:43 GMT. Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 2 INVITE. Session-Expires: 7200;refresher=uac. Require: timer. Allow-Events: telephone-event. Contact: <sip:92143357976@216.87.144.196:5060;user=phone>. Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>. Content-Type: application/sdp. Content-Length: 209. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 16632 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 X-NSE/8000. a=fmtp:100 192-194. The main thing to note is the packet is sent to a SNOM phone from my PROXY server. Curious, when the SNOM phone responds it is responding to 216.87.144.196, which is my GATEWAY. My GATEWAY is configured to only listen to the PROXY server, so it drops the packet. In the packet above, the Record-route line indicates that 216.87.144.203 should be responded to, which is my PROXY. Also in the packet above, there is a 'Contact:' line that indicates the GATEWAY at 216.87.144.196 should be contacted. Obviously the SNOM phone is getting the address from the Contact: line (or maybe the SDP) rather than the Record-route: line. Is it doing so incorrectly, or do I have a bug in my GATEWAY, or does the PROXY need to strip out the Contact: line?

21 years, 3 months

[Serusers] SER parser benchmarks

by Sebastien Pierre

Hi! I was just wondering if you had some benchmark for the SER parser... as SER does not seem to offer a libser, it makes it more difficult to write benchmarking programs :/ TIA, -- Sebastien

21 years, 3 months

Re: [Serusers] FCP support in SER: Modifying SDP

by jaime.gill＠orange.co.uk

Thanks Jiri, I'll have a look at the CVS version. I'm sure there will be more hacking to do only to make it compile.... :( However, got the replacement of the "c=.." part working. I'll test this as soon as I can. Jaime Jiri Kuthan <jiri(a)iptel.org> on 24/02/2003 13:20:00 To: Jaime GILL/EN/HTLUK@HTLUK Nils Ohlmeier <nils(a)ohlmeier.de> cc: Jan Janak <J.Janak(a)sh.cvut.cz> serusers(a)lists.iptel.org Subject: Re: [Serusers] FCP support in SER: Modifying SDP At 12:50 PM 2/24/2003, jaime.gill(a)orange.co.uk wrote: [...] >It think the problem is in the replacement of the SDP information. The first >occurrence of the IP address in "v= " and the port in "m= " in the SDP get >replaced, but the second IP in "c=" is not. nit: it's not the "v=" line, but "o=" ('owner') line which you are replacing. However, you are not probably worried so much about this one -- it maintains primarily a (not widely utilizied) identification purpose. All "c=" occurences do matter. (In addition to port numbers in "m=" lines.) [...] >I have been trying to understand how the proxy builds the forwarded message from >the old one, and realised that for the Via replacement (or adding of more >params), I need to be using a string called add_to_branch_s and >add_to_branch_len (so ignore the replace_via implementation in the current >tar.gz). I suggest you used the mhomed option (available only on CVS). The issue is you need to print the correct IP address in Via on multihomed host. With mhomed enabled, IP routing is utilized to determine the right IP address. Let me know if you need something more for getting Via right. >But for the SDP, whenever I work with get_body, it does not modify it >appropriately. So currently, I'm using msg->orig to get to the initial message, >search for certain IP4 and audio strings and replace them with the information >provided by the fcp server. That means, in the case of the SDP, 2 IP address >replacements (in v=.. and c=..) and 1 port replacement (in m=..). As I mentioned >before, I only manged to change the v=.. and m=... Whenever I try to replace >more than one appearance, strange things happen, like strings in non expected >places, like Via, and cannot work out why. So my question is an open one:): what >is the best way to change the SDP part? I suggest here too -- use the CVS version. It has departed from the use of the buffers (orig and buf) -- we have now just one buffer (buf) without any zero termination. Previously, the two buffers and 0-termination caused lot of issues, some of them possibly annoying you right now. Look at the textops/replace_all action (only on CVS too) to see how to replace multiple occurences of a string in SIP messages. (Caution: you will eventually need to calculate new SDP body size and change content-length too.) >The other of my questions is whether all this mess with NAT's will get solved >when the proxy supports TCP, The major problem is media, which will keep using UDP. >and whether this is the best approach to solve the >SIP through NAT/FW problem. As all NAT traversal methods -- none of them is perfect, each has cons and pros. The benefit of FCP is that once fcpd works, maintenance of the SIP code is easier in user space. Also, you can better couple your pinhole policy with SER's SIP-layer policy. >For example, how about a nathelper module for >netfilter/iptables that gets this working, in the same manner as IRC or ftp >currently? Does anybody know about any work progressing this for linux/FreeBSD? I'm not aware of such. There is Billy Biggs masquerading module, but it is pretty old and no longer maintained. -Jiri _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 3 months

Re: [Serusers] FCP support in SER: Modifying SDP

by jaime.gill＠orange.co.uk

Hi Nils, Once again I'm writing to ask about more things and to give you an update on what is happening with the FCP tests... We have set up a simple scenario with 2 proxies separated by a firewall/NAT, and 2 UA, one within (UA1) and another outside the firewall (UA2). One UA registers with the natted proxy (UA1), the other with the "public" proxy (UA2). At the moment, SIP messages go forwards and backwards without problems, but media is not flowing across the firewall. It think the problem is in the replacement of the SDP information. The first occurrence of the IP address in "v= " and the port in "m= " in the SDP get replaced, but the second IP in "c=" is not. I have been trying all sorts of things, but no joy :( . Here are the INVITE messages in more detail. I also include the latest fcp module for you to play with it. ---------- UA1 to proxy message ------------------ U 172.21.68.78:1129 -> 192.168.6.153:5060 INVITE sip:jaime@asereje.orange.co.uk SIP/2.0 Call-ID: 5812832001907970791(a)172.21.68.78 Content-Length: 121 Content-Type: application/sdp To: sip:jaime@asereje.orange.co.uk From: sip:pepe@asereje.orange.co.uk;tag=-779729009 Contact: sip:pepe@172.21.68.78:5061 CSeq: 1 INVITE Via: SIP/2.0/UDP 172.21.68.78:5061;branch=AC15444E13C5000000F38F819DE5-2*0 v=0..o=- 1046084768435 1046084768465 IN IP4 172.21.68.78 s=- c=IN IP4 172.21.68.78 t=0 0 m=audio 5006 RTP/AVP 8 3 0 ---------- End of UA1 to proxy message ----------------- -------- Proxy to UA2 message --------------------- U 192.168.6.153:5060 -> 172.21.68.78:15592 INVITE sip:172.21.68.78:15592 SIP/2.0 Call-ID: 5812832001907970791(a)172.21.68.78 Content-Length: 121 Content-Type: application/sdp To: sip:jaime@asereje.orange.co.uk From: sip:pepe@asereje.orange.co.uk;tag=-779729009 Contact:<sip:192.168.0.1:33240> CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.6.153;branch=z9hG4bK1019.21c52996.0 Via: SIP/2.0/UDP 172.21.68.78:5061;branch=AC15444E13C5000000F38F819DE5-2*0 v=0..o=- 1046084768435 1046084768465 IN IP4 192.168.0.1 s=- c=IN IP4 172.21.68.78 <--- Need to change this as well!!! t=0 0 m=audio 33240 RTP/AVP 8 3 0 ------------ End of Proxy to UA2 message ------------------- (See attached file: fcp-module210203.tar.gz) I have been trying to understand how the proxy builds the forwarded message from the old one, and realised that for the Via replacement (or adding of more params), I need to be using a string called add_to_branch_s and add_to_branch_len (so ignore the replace_via implementation in the current tar.gz). But for the SDP, whenever I work with get_body, it does not modify it appropriately. So currently, I'm using msg->orig to get to the initial message, search for certain IP4 and audio strings and replace them with the information provided by the fcp server. That means, in the case of the SDP, 2 IP address replacements (in v=.. and c=..) and 1 port replacement (in m=..). As I mentioned before, I only manged to change the v=.. and m=... Whenever I try to replace more than one appearance, strange things happen, like strings in non expected places, like Via, and cannot work out why. So my question is an open one:): what is the best way to change the SDP part? The other of my questions is whether all this mess with NAT's will get solved when the proxy supports TCP, and whether this is the best approach to solve the SIP through NAT/FW problem. For example, how about a nathelper module for netfilter/iptables that gets this working, in the same manner as IRC or ftp currently? Does anybody know about any work progressing this for linux/FreeBSD? Greetings, Jaime Nils Ohlmeier <nils(a)ohlmeier.de> on 18/02/2003 02:58:47 To: Jaime GILL/EN/HTLUK@HTLUK cc: Jan Janak <J.Janak(a)sh.cvut.cz> Jiri Kuthan <jiri(a)iptel.org> Subject: Re: [Serusers] FCP support in SER: Modifying SDP Hi Jaime, debugging without the code is really hard :-) But maybe your problme with SDP is correlated to a bug in the Via header which i marked below. Greetings Nils On Monday 17 February 2003 11:58, jaime.gill(a)orange.co.uk wrote: > U 192.168.6.153:5060 -> 172.21.68.78:5061 > INVITE sip:pepe@172.21.68.78:5061 SIP/2.0..Via: SIP/2.0/UDP > 192.168.6.153;b ranch=z9hG4bKb848.8a014f84.0..Via: SIP/2.0/UDP > 192.168.0.1192.168.0.1:9439. .From: "jaime" ^^^^^^^^^^^^^^^^^^^^^^ Here you inserted the external IP twice. Maybe your SDP replacer did this? > <sip:jaime@asereje.orange.co.uk>;tag=8c20540f-4259-11d7-9cc5 > -00065b4c11cb..To: <sip:pepe@asereje.orange.co.uk>..Call-ID: 8c205410-4259- > 11d7-9cc5-00065b4c11cb@172.21.68.78..CSeq: 1 INVITE..Contact:<sip:192.168.0 > .1:33186>.User-Agent: Windows RTC/1.0..Content-Type: application/sdp..Conte > nt-Length: 211....v=0..o=gill_j 0 0 IN IP4 172.21.68.78..s=session..c=IN IP > 4 172.21.68.78..b=CT:1000..t=0 0..m=audio 33186 RTP/AVP 97 0 8 4..a=rtpmap: > 97 red/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:4 G723/80 > 00.. -- gpg-key: http://www.ohlmeier.org/public_key.asc ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 3 months

[Serusers] Cannot add "alias" mysql DB (using default passwords)

by Lenny Tropiano

I have turned on mysql authentication, and was able to add users, but aliases complain that "table" doesn't exist: $ serctl add lenny abcdef lenny(a)voiping.com MySql Password: new user added $ serctl alias add 1234 sip:lenny@voiping.com sip:lenny@voiping.com 400 Table 'aliases' Not Found $ mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 243 to server version: 3.23.53 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> connect ser; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Connection id: 244 Current database: ser mysql> show tables; +-----------------+ | Tables_in_ser | +-----------------+ | acc | | active_sessions | | aliases | | config | | event | | grp | | location | | missed_calls | | pending | | phonebook | | reserved | | silo | | subscriber | | version | +-----------------+ 14 rows in set (0.00 sec) mysql> --- Lenny Tropiano E-mail: lenny(a)voiping.com Partner, Networking Specialist Pager: pager-lenny(a)voiping.com VoIPing, LLC URL: http://www.voiping.com/ PO Box 867, Cedar Park, TX 78630-0867 Mobile: 512-698-VOIP [8647]

21 years, 3 months

[Serusers] On CVS, Radius and Generally SER Status (2003/II)

by Jiri Kuthan

I'm observing increasing number of downloads from CVS and would like to issue few disclaimers to prevent any disappointments. The CVS code is work in progress -- it has not been integrated, tested, it is not complete and we cannot provide help on incomplete software. Also, folks should know that compilation of one of the most frequently asked features, Radius support, is disabled on purpose. It is an external contribution which deserves a clean-up, we are working on it but we are not there yet. My previous forecast for the upcoming release is turning out to be too optimistic. We decided to carry out some more clean-ups and the work takes time. Anyway, we think it is better to clean up now than later -- interest in ser is growing, and we need to keep the codebase sane despite all the new features. -Jiri -- Jiri Kuthan http://iptel.org/~jiri/

21 years, 3 months

[Serusers] problem in using acc.so and radius_acc.so and auth.so

by Benny Ho

Dear all, after days of trial, I finally load radius_acc.so in my ser. But when I testing the modules with the new routing config. Nothing happen. I follow the sample config in the CVS as follow. I check the radius server with radius -x, no packet seem to send to radius server. I also check the Mysql database, no entry is wrote to acc table. Why? Can anyone tell me what's wrong? ================== [benny@md benny]$ more /etc/ser/ser.cfg # # $Id: ser.cfg,v 1.12 2002/10/21 02:40:06 jiri Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "//usr/lib/ser/modules/mysql.so" [benny@md benny]$ cat /etc/ser/ser.cfg # # $Id: ser.cfg,v 1.12 2002/10/21 02:40:06 jiri Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "//usr/lib/ser/modules/mysql.so" # Uncomment this to use radius for accounting loadmodule "/usr/lib/ser/modules/radius_acc.so" loadmodule "//usr/lib/ser/modules/acc.so" #--- radius_ acc.so params --- modparam("radius_acc","log_level",1) modparam("radius_acc","acc_flag",1) modparam("radius_acc","report_ack",1) modparam("radius_acc","early_media",0) modparam("radius_acc","failed_transactions",0) #--- acc.so params --- modparam("acc","log_level",1) modparam("acc","acc_flag",1) modparam("acc","report_ack",1) modparam("acc","early_media",1) modparam("acc","failed_transactions",1) 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" # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "//usr/lib/ser/modules/auth.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", "secret", "alsdkhglaksdhfkloiwr") #modparam("auth", "calculate_ha1", yes) #modparam("auth", "calculate_ha1", no) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # #modparam("auth", "password_column", "password") # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwars==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; }; # Do strict routing if pre-loaded route headers present # rewriteFromRoute(); #if (method=="INVITE") { addRecordRoute(); #} else { rewriteFromRoute(); #}; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication # if (!www_authorize("iptel.org", "subscriber")) { # www_challenge("iptel.org", "0"); # break; # }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; #labeled all transaction for accouting setflag(1); #record-route INVITES to make sure BYEs will visit our server too #if (method=="INVITE") addRecordRoute(); # forward to current uri now if (!t_relay()) { sl_reply_error(); }; } [benny@md benny]$ ==================================

21 years, 3 months

[Serusers] NAT Traversal Technique Survey

by Jiri Kuthan

Folks, please help me -- share with me techniques for NAT traversal you use and have hands-on experience with. People repeatedly ask about it, and I'd like to create an FAQ that reflects deployment experience and as wide user feed-back as possible. Just tell me the technique you use, its requirements, limitations, the devices it is known (not) to work with, why you prefer one method over the other, etc. I'll then try to compile it in an FAQ. So please send me an e-mail, an example is attached. I will appreciate any practical details. Thank you, -Jiri ---------------------------------------------------------------- technique: using symmetric communication requirements: phone devices that support symmetric communication; existing species: Cisco's ATA configuration practice: ATAs need to be configured to advertise public address in signaling, or learn it from REGISTER replies; alternatively, one can rewrite signaling using ser's nethelper module; one needs to rewrite SIP anyway because ATAs don't advertise their symmetricity; see www.foo.bar for info on configuring ATA... limitations: non-symmetric devices, like Messenger don't work; misc: ATA has no display, that's why I am anxiously waiting for more vendors to support symmetric signaling ---------------------------------------------------------------- technique: UPnP requirements: NATs and phones with UPnP support; Messenger and snom are known to support UPnP; there is linux support for it configuration practice: of course, upnp requires by definition no configuration ;-) (I'm not serious -- anyone actually tried it?) ---------------------------------------------------------------- technique: geek tweaks: set-up port forwading manually configuration practice: you need to configure NATs to split its public-side port numbers accross your private-side phones, and configure the phones (if they allows so) to use these port numbers; also, phones need to be configured to use publicly reachable address in their payloads requriements: configurable NATs (many residental NATs are configurable) and configurable phones (ATAs do that, I heard pingtel did it too) ---------------------------------------------------------------- technique: ALG requirements: SIP-capable NAT (like Intertex or Cisco/PIX) issues: intertex freezes my ssh connections after some time on-line and elderly models don't like all Ethernet devices; when things don't work, the red-button off-on helps sometimes ---------------------------------------------------------------- technique: STUN requirements: STUN-enabled phone (like k-phone, snom) limitations: doesn't work over symmetric NATs (words-of-mouth propaganda has been telling me that many residential NATs are fortunately not symmetric, but I don't know how objective this information really is) ---------------------------------------------------------------- -- Jiri Kuthan http://iptel.org/~jiri/

21 years, 3 months

[Serusers] Windows- Sms gateway

by ant buckland

Hi- I am a very Junior designer, and as part of my efforts to impress my boss, I am trying to create a simple email to sms application. Sadly, here in South Africa, the cellular service providers do not provide an sms gateway to the public, and so I am researching the iptel.org SIP Express Router. I need to know the following: after reading the iptel.org website, I would like to know whether it is possible to install the application on a Windows 2000 server, and run the gateway. From what I read, apparently only the core application can be installed... and this does not appear to include the gateway? Obviously, I will pass the project on to a programmer who knows more, so you will not be plagued by too-simple questions from an inexperienced designer... but I would appreciate any assistance/info that will allow me to convince my boss. Thank you! ph (021) 685 6499 anthony_buckland(a)yahoo.co.uk 70 Strubens Rd, Observatory, Cape Town --------------------------------- With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs

21 years, 3 months

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