sr-users January 2003

sr-users@lists.kamailio.org

47 participants
77 discussions

[Serusers] Multiple potential memory leaks in ser

by Maxim Sobolev

Folks, I've noticed that there are multiple potential memory leaks in SER. The problem is that if a insert_new_lump*() function returns a NULL for some reason (currently the only condition is memory allocation error), it doesn't free the memory buffer passed to it and most of the code doesn't care to deallocate that buffer after NULL is returned. It could be easily fixed and probably needs to before the next version is released. Thanks! -Maxim

21 years, 10 months

RE: [Serusers] [RFC] ideas about new dialog module

by Schliesser, Benson

I'm thinking that the 'forceful termination' should have options for redirection, i.e. to an announcements (or other media) server, etc. Is this in line with your thoughts? -Benson > -----Original Message----- > From: Maxim Sobolev [mailto:sobomax@portaone.com] > Sent: Thursday, January 16, 2003 3:37 PM > To: serusers(a)lists.iptel.org; kapitan(a)portaone.com > Subject: [Serusers] [RFC] ideas about new dialog module > > > Hi, > > I am thinking about writing a new module for SER, which will track SIP > dialogs and will serve as an abstraction layer for other modules, much > like the tm module now. We need such module for 2 reasons: > > 1. Call accounting. Our billing engine is based on the assumption that > a node provides accounting information for completed calls, not for > individual transactions. It is easier for us to extend proxy with > similar features than to modify billing engine to do transaction > matching. > > 2. Debit card application. Currently, there is no way to use SER for > debit card applications, where it is necessary to set the maximum > duration of the call and terminate it forcefully if that duration is > exceeded. > > The raw idea is as follows: > > - the module will register callbacks with tm.register_tmcb(), probably > TMCB_REQUEST_IN and TMCB_REPLY_IN ones and will match INVITEs to BYEs > keeping information about the state of ongoing sessions in the shared > memory. > > - the module will provide interested modules with ability to register > several callbacks, i.e. on dialog creation/teardown and yet another > callback on dialog timeouts (more about that below). > > - the module will provide utility functions for forceful termination > of any ongoing dialog. > > - when invoking dialog creation callback function, the module will > give the function opportunity to install a timer on that dialog, so > that if the dialog is still active after timer expires, then some > action is performed. For example, in the debit card applications, in > such case the accounting module can decide to forcefully terminate a > dialog. > > What do you think? > > -Maxim > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers >

21 years, 10 months

[Serusers] [RFC] ideas about new dialog module

by Maxim Sobolev

Hi, I am thinking about writing a new module for SER, which will track SIP dialogs and will serve as an abstraction layer for other modules, much like the tm module now. We need such module for 2 reasons: 1. Call accounting. Our billing engine is based on the assumption that a node provides accounting information for completed calls, not for individual transactions. It is easier for us to extend proxy with similar features than to modify billing engine to do transaction matching. 2. Debit card application. Currently, there is no way to use SER for debit card applications, where it is necessary to set the maximum duration of the call and terminate it forcefully if that duration is exceeded. The raw idea is as follows: - the module will register callbacks with tm.register_tmcb(), probably TMCB_REQUEST_IN and TMCB_REPLY_IN ones and will match INVITEs to BYEs keeping information about the state of ongoing sessions in the shared memory. - the module will provide interested modules with ability to register several callbacks, i.e. on dialog creation/teardown and yet another callback on dialog timeouts (more about that below). - the module will provide utility functions for forceful termination of any ongoing dialog. - when invoking dialog creation callback function, the module will give the function opportunity to install a timer on that dialog, so that if the dialog is still active after timer expires, then some action is performed. For example, in the debit card applications, in such case the accounting module can decide to forcefully terminate a dialog. What do you think? -Maxim

21 years, 10 months

[Serusers] radius_auth problem

by Joe_chen

hi, I have a problem with radius_auth, i use raidus_auth module as www-authentication ,but something is wrong, the free-radius server need the PW_PASSWORD attribute for authentication, while the ser's radius_auth module doesn't send the PW_PASSWORD attribute, i can't find the password from the REGISTER message, there is a NONCE like nonce="3e1947180000000040c0e6240c7f8145a64eb654ce9a14e0" and encrypted with MD5. Do i need get the user's password and how to get user's the password? please help. thanks.

21 years, 10 months

[Serusers] Troubles using b2bua as a accounting and call duration limiting module for SER router

by Maxim Sobolev

Dear Sirs, I am having some strange problems when trying to use b2bua for accounting and call duration limiting with SER proxy server. The idea is simple: since the SER can route SIP messages depending on their source address, we can force incoming SIP messages to be passed to B2BUA for accounting purposes first, and after the same request re-enters the proxy from B2BUA pass it to the final destination. Call flow looks like the following: ----- |UA2| ----- ^ | |4 | ----- 3 ------- ----- 1 | |<-----------| | |UA1|---->|SER| 2 |B2BUA| ----- | |----------->| | ----- ------- For some reason, it doesn't work in such configuration. The problem is that B2BUA's UAC keeps resending `200 OK' replies ingnoring ACKs it receives from UA2 until timeout hits, after which it considers the call dead, despite the fact that both UA1 and UA2 think that the call is established. Maybe it has something to do with the fact that it sends to and receives messages from the same host (SER), but I don't think that this should be a problem, since those two call legs have different call id's, so that b2bua should be able to distinguish between them easily. Attached please find tcpdump logs of one such session, here 192.168.1.1 is UA1 (originating), 192.168.0.9 is UA2, 192.168.1.100 is the host running both SER and B2BUA (the former uses port 5060, while the latter - 5065). There are two files: ser-b2bua.log is the log of udp exchange between SER and B2BUA and ser-ua1ua2.log - log of exchange between SER and UA1/UA2. Any ideas are appreciated. Thanks! -Maxim

21 years, 10 months

[Serusers] problem with phone authentication

by lgfausak＠august.net

This works with my eStara soft phone client: --------------cut # route[1], REGISTER block # REGISTER messages destined for our realm are forwarded here. # after a successful registration a customer can receive calls. # route[1] { if(!www_authorize("augustvoice.net", "subscriber")) { www_challenge("augustvoice.net", "0"); break; }; log("here is a register"); if(!save("location")) { sl_reply_error(); }; break; } ---------------uncut However, when I try to get my Cisco 7960 to authorize it fails. I've appended the ngrep trace of the failed transaction. The only difference I can see is that the line argument algorithm=MD5 is in the WWW-Authenticate line. Do I have to do something special to accept a MD5 password??? ---greg Greg Fausak ngrep trace: --------cut # U 216.87.128.66:5060 -> 64.90.42.25:5060 REGISTER sip:64.90.42.25 SIP/2.0. Via: SIP/2.0/UDP 216.87.128.66:5060;branch=f6645848fea927b96489c6a32e39a956.0. From: sip:2424377@64.90.42.25. To: sip:2424377@64.90.42.25. Call-ID: 003094c4-3d2f0002-23a6c56d-0dcb5c8f(a)192.168.100.101. Date: Sat, 18 Jan 2003 00:42:54 GMT. CSeq: 101 REGISTER. Contact: <sip:2424377@216.87.128.66>. Expires: 3600. Content-Length: 0. . # U 64.90.42.25:5060 -> 216.87.128.66:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 216.87.128.66:5060;branch=f6645848fea927b96489c6a32e39a956.0. From: sip:2424377@64.90.42.25. To: sip:2424377@64.90.42.25;tag=af30b122c950f7c4343d8a73d2eaf455.2313. Call-ID: 003094c4-3d2f0002-23a6c56d-0dcb5c8f(a)192.168.100.101. CSeq: 101 REGISTER. WWW-Authenticate: Digest realm="augustvoice.net", nonce="3e28a43a000000005b6a30b9fa105b98b2fd9d1aa59c4c72", algorithm=MD5. Server: Sip EXpress router (0.8.10 (i386/linux)). Content-Length: 0. Warning: 392 register.augustvoice.net:5060 "Noisy feedback tells: pid=2262 req_src_ip=216.87.128.66 in_uri=sip:64.90.42.25 out_uri=sip:64.90.42.25 via_cnt==1". . # U 216.87.128.66:5060 -> 64.90.42.25:5060 REGISTER sip:64.90.42.25 SIP/2.0. Via: SIP/2.0/UDP 216.87.128.66:5060;branch=e71832739a0647b7ba91baa50bcc1497.0. From: sip:2424377@64.90.42.25. To: sip:2424377@64.90.42.25. Call-ID: 003094c4-3d2f0002-23a6c56d-0dcb5c8f(a)192.168.100.101. Date: Sat, 18 Jan 2003 00:42:54 GMT. CSeq: 102 REGISTER. Authorization: Digest username="2424377",realm="augustvoice.net",uri="sip:64.90.42.25",response="039cee96c9321217973c4914314fc3ed",nonce="3e28a43a000000005b6a30b9fa105b98b2fd9d1aa59c4c72",algorithm=MD5. Contact: <sip:2424377@216.87.128.66>. Expires: 3600. Content-Length: 0. . # U 64.90.42.25:5060 -> 216.87.128.66:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 216.87.128.66:5060;branch=e71832739a0647b7ba91baa50bcc1497.0. From: sip:2424377@64.90.42.25. To: sip:2424377@64.90.42.25;tag=af30b122c950f7c4343d8a73d2eaf455.2581. Call-ID: 003094c4-3d2f0002-23a6c56d-0dcb5c8f(a)192.168.100.101. CSeq: 102 REGISTER. WWW-Authenticate: Digest realm="augustvoice.net", nonce="3e28a43a000000005b6a30b9fa105b98b2fd9d1aa59c4c72", algorithm=MD5. Server: Sip EXpress router (0.8.10 (i386/linux)). Content-Length: 0. Warning: 392 register.augustvoice.net:5060 "Noisy feedback tells: pid=2263 req_src_ip=216.87.128.66 in_uri=sip:64.90.42.25 out_uri=sip:64.90.42.25 via_cnt==1". .

21 years, 10 months

[Serusers] ata

by Jan Janak

Hello, your messages about CISCO ATA reminds me that I have also one (a preproduction unit originally made by Komodo), so I upgraded firmware to 2.15 and tried it behind a symmetric NAT. It works, I had to enable portforwarding for signalling and media and setup properly outer address of the NAT box in the phone. Once you finish your NAThelper module, I would like to give it a try and see if it works without modifications of the NAT box. So I can help you to test the code if you want. regards, Jan.

21 years, 10 months

[Serusers] [HEADS UP] security vulnerability in ser 0.8.10

by Maxim Sobolev

Folks, While playing with SER I found that I can trigger repeatable crash when doing REGISTER multiple times. Quick glance at the code in question revealed that indeed, when constructing reply to REGISTER message, SER uses fixed-lengh buffer to put all non-expired contacts for that user and doesn't bother to check for overflow. The bug could be easily exploited by a complete stranger on servers that don't perform authentification of REGISTER requests, and by an user with a valid credintals on server that do authentification. Mounting attack leads to denial of service. Attached please find fake REGISTER message, which if sent to open server kills it (nc -u my.sip.server 5060 < register.killser), and patch to fix the problem. -Maxim

21 years, 10 months

[Serusers] Fwd: Guest Passes to TMC Internet Telephony Conference & Expo

by Jiri Kuthan

just in case someone would like to show up there. first come, first served. -jiri >Hello! > >Internet Telephony Conference & Expo is right around the corner! As a speaker and participant in the conference program, TMC would like to offer you (2) conference passes free of charge. These passes can be given to colleagues, clients, or guests that you would like to invite to hear you speak and to the show. These passes would be full conference passes and would allow that person to go to the entire event, not just to your session. > >If you would like to take advantage of this offer all you need to do is e-mail the following >information for each person: > >Name >Title >Company name >Address >Phone >Fax >E-mail > >Put "Internet Telephony Miami Speaker Conference Program" in the subject line and you are done! The pass will be sent to them in the mail. > >As a speaker, you will already have your speaker pass prepared. Please pick up your pass at the event registration. > >PLEASE NOTE - this program is not to replace an existing conference pass. No monies that might have been paid will be refunded.

21 years, 10 months

RE: [Serusers] Password problem with ser and mysql

by Klaus Darilion

Yes, that was my problem! Thank you very mutch! Are you involved in the SHIP (http://voip.sh.cvut.cz/about.shtml) project? (because of your emailaddress). I read that you are using Vocal as voice mail server. Do you have an installation guide how to setup such a system with vocal and ser? regards, Klaus > -----Original Message----- > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > Sent: Friday, January 17, 2003 1:14 PM > To: Klaus Darilion > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] Password problem with ser and mysql > > > Hello, > > auth is not the only module that uses database. If you have > enabled support for database in usrloc (by modparam("usrloc", > "db_mode", 1) or modparam("usrloc", "db_mode", 2) then you > have to change usrloc's password as well. Try to use the > following: modparam("usrloc", "db_url", > "sql://ser:klaus@localhost/ser") > > regards, Jan.cd > > On 17-01 11:56, Klaus Darilion wrote: > > Hello Jan! > > > > Comments inline. > > > default username and password for auth module is > > > serro:47serro11, if you are able to login as ser:heslo, then > > > username and password can be changed. > > > > > If you change your password in mysql, you must change it for > > > ser@localhost For example: grant ALL on ser.* to > > > ser@localhost identified by 'klaus'; > > > > I changed it for localhost, but it won't work. > > > > > If you use something like grant ALL on ser.* to ser > > > identified by 'klaus'; then the server will be unable to > > > login to the database. > > > > > > Try also the following: > > > mysql -h localhost -u ser -p ser > > > > I changed the password of ser@localhost to 'klaus'. I can > connect to > > mysql with mysql -h localhost -u ser -p ser > > and password 'klaus'. I changed the password in ser.cfg to 'klaus' > > modparam("auth", "db_url", "sql://ser:klaus@localhost/ser") > > , but still the ser server can't start: > > : connect_db(): Access denied for user: 'ser@localhost' (Using > > password: YES) > > > > > > I still think there must be a bug somewhere, so that ser tries to > > connect with the 'heslo' password. > > > > regards, > > Klaus > > > > > This will prompt for password, if you are unable to login > > > with your password, ser will be unable to login as well > > > (probably because you changed password for ser and not for > > > ser@localhost) > > > > > > regards, Jan. > > > > > > On 16-01 18:34, Klaus Darilion wrote: > > > > Hello! > > > > > > > > I have sucessfully installed the ser server (0.8.10 from > > > rpms) with an > > > > mysql database. When I use the standard password for the user > > > > "ser" > > > > everything works fine. But if I change the password from > > > "heslo" to a > > > > new one, for example "klaus" instead of "heslo" (of > course in the > > > > mysql-database und in the config file) the ser server > can not start > > > > up. > > > > > > > > Following are some different configurations and my suggestions > > > > what > > > > could be the problem. > > > > > > > > ser.cfg: modparam("auth", "db_url", > > > > "sql://ser:heslo@localhost/ser") > > > > mySQL-root-password: XXXXX > > > > mySQL-ser-password: heslo > > > > ---> works fine > > > > > > > > ser.cfg: modparam("auth", "db_url", > > > > "sql://ser:klaus@localhost/ser") > > > > mySQL-root-password: XXXXX > > > > mySQL-ser-password: klaus > > > > ---> doesn't work: connect_db(): Access denied for user: > > > > ---> 'ser@localhost' > > > > (Using password: YES) > > > > should work, so I tried another user > > > > > > > > ser.cfg: modparam("auth", "db_url", > > > "sql://root:XXXXX@localhost/ser") > > > > mySQL-root-password: XXXXX > > > > mySQL-ser-password: heslo > > > > ---> works fine > > > > > > > > ser.cfg: modparam("auth", "db_url", > > > "sql://root:XXXXX@localhost/ser") > > > > mySQL-root-password: XXXXX > > > > mySQL-ser-password: klaus > > > > ---> doesn't work: connect_db(): Access denied for user: > > > > ---> 'ser@localhost' > > > > (Using password: YES) > > > > very strange, because I told ser to connect as root. Is ser > > > using the > > > > default user/password instead of the configured one? > > > > > > > > ser.cfg: modparam("auth", "db_url", > > > "sql://root:YYYYY@localhost/ser") > > > > mySQL-root-password: XXXXX > > > > mySQL-ser-password: heslo > > > > ---> doesn't work: connect_db(): Access denied for user: > > > > 'root@localhost' (Using password: YES) > > > > of course it doesn't work, wrong password. So ser cares > about the > > > > settings in ser.cfg > > > > > > > > So my suggestion is that ser connects several times to the > > > > database > > > > whereas one time it uses the configured user/password and > > > another time > > > > it uses the default user/password - maybe a bug in the auth > > > > module? > > > > > > > > Or does somebody of you changed the password successfuly? > > > > > > > > It would be nice if you can help me. > > > > > > > > Thanks, > > > > Klaus > > > > > > > > My system is: > > > > Linux version 2.4.18-14 (bhcompile(a)astest.test.redhat.com) > > > (gcc version > > > > 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 > > > 12:13:11 EDT 2002 > > > > MySQL 3.23.52 > > > > ser-0.8.10-2.i386.rpm > > > > ser-mysql-0.8.10-2.i386.rpm > > > > _______________________________________________ > > > > 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 > > >

21 years, 10 months

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 January 2003