sr-users

sr-users@lists.kamailio.org

1 participants
37454 discussions

[Serusers] ser2 and sems?
by TZieleniewski 27 Feb '07

27 Feb '07

Hi!! I am going to set up the sems-ser configuration. In the mini-sems-ser-howto there is a clue to have separate instance of ser for sems. Will sems 0.10.0 work with the ser ottendorf release?? Bests tomasz

1 0

[Users] install:1.1.x-to-1.2.x
by Daniel-Constantin Mierla 27 Feb '07

27 Feb '07

(started a new thread from a devel discuttion) Everybody is encouraged to update the page below: http://openser.org/dokuwiki/doku.php/install:1.1.x-to-1.2.x If you do not know how to explain clear, but you know (feel) something changed from 1.1.x to 1.2.0 in a module or other place, just introduce in bold red a short phrase at the beginning or in module's section. Someone will see later and elaborate it. Cheers, Daniel On 02/27/07 13:01, Andreas Granig wrote: > Thank god there is > http://openser.org/dokuwiki/doku.php/install:1.1.x-to-1.2.x > > Hopefully, all the small changes are documented there (hint: the one > below isn't yet) ;o) > > Cheers, > Andreas > > Bogdan-Andrei Iancu wrote: >> Hi Juha, >> >> yes, there is an impact on the script, but very small. The only >> change is: >> modparam("registrar", "sip_natping_flag", x ) >> goes into >> modparam("nathelper","sipping_bflag",x) >> >> regards, >> bogdan

1 0

[Users] Presence module
by Helmut Kuper 27 Feb '07

27 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I just configured the presence modul and got some strange output in my shell when my xlite phone trys to subscribe to a non existant user: 0(16615) ERROR: warning_builder: buffer size exceeded 0(16615) WARNING: warning skipped -- too big 0(16615) ERROR: warning_builder: buffer size exceeded 0(16615) WARNING: warning skipped -- too big 0(16615) ERROR: warning_builder: buffer size exceeded 0(16615) WARNING: warning skipped -- too big 0(16615) PRESENCE: get_subs_dialog:The query for subscribtion for [user]= sebastian.bruening%40googlemail.comtalk.v104112f54d0,[domain]= sip0.en.ewetel.de for [event]= presence.winfo returned no result 0(16615) PRESENCE:query_db_notify: Could not get subs_dialog from database 0(16615) PRESENCE:update_subscribtion:Could not send notify for presence.winfo 0(16615) PRESENCE:get_xcap_tree:The query in table xcap for [username]=sebastian.bruening%40googlemail.comtalk.v104112f54d0 , domain=sip0.en.ewetel.de returned no result any ideas what this mean? I use latest version of openser (1.2.0). regards Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5D+D4tZeNddg3dwRAiYcAKCt9FJYu/yM6+HW/+QOXlp0XOAPWACfYpFZ 0JbJo+z27a2M1zr8WlEG4G4= =I9/o -----END PGP SIGNATURE-----

2 1

[Users] bug in radiusclient ng for 64b
by Stuart Clark 27 Feb '07

27 Feb '07

Hello, I have a 64bit machine running openser 1.1.0, and wish to log radius accounting details to radius using the acc module and radiusclient-ng. I am facing issues talking to a freeradius server, as described at: https://developer.berlios.de/bugs/?func=detailbug&bug_id=7442&group_id=1208 Basically, the server reports: Error: Received Accounting-Request packet from w.x.y.z with invalid signature! (Shared secret is incorrect.) I have updated to the cvs version of radiusclient-ng, but the problem still exists. It would appear that the md5 routine is not compatible with the md5 routine used by the freeradius software. Just wondering is anyone else has worked their way around this problem. Cheers, Stuart > X-Archived: http://article.gmane.org/gmane.comp.voip.openser.user/4415 > From: Daniel-Constantin Mierla <daniel@...> > Subject: FYI: bug in radiusclient ng for 64b > Newsgroups: gmane.comp.voip.openser.user, gmane.comp.voip.openser.devel > Date: 2006-05-16 01:44:16 GMT (13 weeks, 3 days and 58 minutes ago) > > On 05/16/06 02:48, Maxim Sobolev wrote: >> Hi, >> >> Reportedly there is an problem in radiusclient library with md5 hash >> calculation on 64bit platforms (amd64, sparc64, etc), which results in >> server rejecting requests even with proper secret configured on >> client. I have applied a fix, but don't have access to any 64bit >> hardware, therefore can't verify. >> >> Therefore, if anybody is having problems with radiusclient on 64bit >> arch he is more than welcome to try update to the latest version from >> cvs and let me know if it helps or not. Instructions on checking out >> sources from berlios cvs are here: >> https://developer.berlios.de/cvs/?group_id=1208. >> >> Thanks! >> >> -Maxim >

3 2

[Users] OpenSER administrator issue
by Pat wang 27 Feb '07

27 Feb '07

Hi, Just managed to install the new openser administrator and everything just works. Thanks to Mike for this nice application. However I can't add user with openserctl anymore. The following error appears: ERROR 1054 (42S22) at line 1: Unknown column 'phplib_id' in 'field list' ERROR: introducing the new user '5702' to the database failed On the other hand, adding new users from administrator GUI does not have this problem. This happened right after installation of aministrator so I think it is related to the administrator mysql table changes. Any suggestions please? Thanks, Patrick

4 4

[Users] eta for v1.2.0 - March 12
by Daniel-Constantin Mierla 27 Feb '07

27 Feb '07

Hello everybody, just to give you an update with estimation time line for release 1.2.0... The plan is to release it on the 12th of March, hard work being with packaging files update, migration tools, and of course still with testing and stress-testing ... If you have good DB (mysql/postgres) skills and want to help, just say it, it is enough work around :-) . Some tables changed the structure of the fields (like LCR with the IP address), and a bit more advanced migration mechanism should be in place. Of course, help with testing is always appreciated ... Cheers, Daniel

1 0

[Serusers] PATH Module in SER?
by SER LIST 27 Feb '07

27 Feb '07

Is there a paths module for SER? I want to implement a Load balancer using Dispatcher module and I will need a path module for handling registrations. Thanks in advance _________________________________________________________________ Your Space. Your Friends. Your Stories. Share your world with Windows Live Spaces. http://spaces.live.com/?mkt=en-ca

1 0

[Users] OpenSER CVS was migrated to SVN
by Daniel-Constantin Mierla 27 Feb '07

27 Feb '07

Hello, after the discussion on devel mailing list was decided to migrate OpenSER CVS repository to SVN. Most of developers considered the SVN more convenient to work with, especially when hunting reported bugs (svn revision number is printed by openser -V). Unfortunately this bring a bit of work for those installing and maintaining OpenSER from CVS. The have to grab the subversion (svn) tree righ now. There are no changes in directory structure, so any patch you had privately should apply easy. To get the same directory tree as for CVS: # svn co https://openser.svn.sourceforge.net/svnroot/openser sip-server For details about how to get a certain branch, please see the download page on http://www.openser.org: http://www.openser.org/index.php?option=com_content&task=view&id=29&Itemid=… We are still working on making snapshot system using SVN, and maybe some other tools are not yet updated, but they will be in the next days. However, what is most important should be ready to go -- source tree should be fully functional with SVN. Please let us know if you encounter any issue. The translation to SVN was made over this weeken. New commits were already done to SVN. There was no critical update you should run after, but is recommended to get SVN version as soon as possible. Old branches were migrated (releases 0.9.x, 1.0.x, 1.1.x). For the reference, initial revision for subversion is 1689. Once you get your patch against latest CVS version availabe, then should be no issue to apply it to this subversion revision. Full commit history from CVS is available on SVN. Hope SVN will make openser maintenance easier for all of you. Here are some links to get you familiar with SVN commands and capabilities: http://svnbook.red-bean.com/nightly/en/index.html http://subversion.tigris.org/ OpenSER SVN page at sourceforge: http://sourceforge.net/svn/?group_id=139143 Cheers, Daniel

4 6

Re: [Users] dialog module configuration question
by Bogdan-Andrei Iancu 26 Feb '07

26 Feb '07

Hi Andy, yes, you are correct - the package 7 (the 200 OK) must mirror the Record-Route set from the request. For this you need to enable the rrs param : <recv request="INVITE" crlf="true" rrs="true"> </recv> regards, bogdan Andy Pyles wrote: > Hi Bogdan, > > ok let me go back to my example: > > Here's more detail: > 192.168.0.101 = Caller (sipp uas) > 1.2.3.4 = openser > 4.3.2.1 = callee ( sipp uac) > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE > sip:service@1.2.3.4:5060, with session description > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE > sip:service@4.3.2.1:5060, with session description > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session > description > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session > description > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK > sip:service@1.2.3.4:5060 > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060 > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE > sip:service@1.2.3.4:5060 > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060 > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK > > So, you are saying for Packets 8, 10 I should add the '[routes]' logic > to sipp. How this works is: from the sipp documentation: "rrs: Record > Route Set. if this attribute is set to "true", then the > "Record-Route:" header of the message received is stored and can be > recalled using the [routes] keyword.". > > This I completey agree with. sipp Must be sending the Route: header > in Packets 8 and 10. However, packet 7 MUST have the Record-route > header, otherwise, How can sipp can put the correct value into the > Route: header. See my point? > > Reference: rfc 3665 ( secion 3.2 Packet f11, f14) > > regards, > Andy > > > On 2/23/07, Andy Pyles <andy.pyles(a)gmail.com> wrote: >> Hi Bogdan, >> >> correct. but on client config "[routes]" ( for sipp) will only work >> IF the client receives a Record-route. Since I'm not, it doesn't help >> me. Am I missing something? >> >> Andy >> >> On 2/23/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: >> > Hi Andy, >> > >> > in client config, you need to add "[routes]" for ACK and BYE messages >> > (take a look at the cfg I sent you) >> > >> > regards, >> > bogdan >> > >> > Andy Pyles wrote: >> > > I Just re-read the docs on loose_route(). So please disregard this >> > > question. ( only processed if Route: header is present. Which isn't >> > > present because Record-route: header isn't being sent to caller ) >> > > >> > > So, I'm still trying to figure out why record-route: header is not >> > > being sent to caller. >> > > >> > > >> > > On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote: >> > >> Hi Bogdan, >> > >> >> > >> After running additional debugs, for some reason the call to >> > >> loose_route() is failing. >> > >> >> > >> if (loose_route()) { >> > >> # mark routing logic in request >> > >> xlog("L_INFO", "loose_route() succeeded\n "); >> > >> route(1); >> > >> } else{ >> > >> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu >> > >> T=$tu IP=$si ID=$ci\n"); >> > >> }; >> > >> >> > >> >> > >> Any ideas why this could be occuring? >> > >> >> > >> >> > >> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote: >> > >> > HI Bogdan, >> > >> > >> > >> > I'm already using an almsot identical version of uas.xml and >> uac.xml ( >> > >> > yes rrs=true) is being used. However in your version the uas.xml >> > >> > doesn't have rrs="true" after initial invite which I think is >> needed. >> > >> > See as you can see below, setting rrs="true" for uac will only >> work if >> > >> > it receives a Record-Route header in the 200OK which it's not. >> > >> > >> > >> > In this case, ALL messages from openser to sipp uac do not >> contain the >> > >> > Record-route header. So I don't think it's a sipp problem, but an >> > >> > openser configuration problem. I've tried using other devices >> for a >> > >> > uac, such as x-lite but the same problem. >> > >> > >> > >> > Andy >> > >> > >> > >> > On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: >> > >> > > Hi Andy, >> > >> > > >> > >> > > so it's about sipp :D - I remember I had some hard times to >> make >> > >> it work >> > >> > > with record Route. >> > >> > > >> > >> > > take a look at the attached files, they might help you. >> > >> > > >> > >> > > regards, >> > >> > > bogdan >> > >> > > >> > >> > > Andy Pyles wrote: >> > >> > > > HI Bogdan, >> > >> > > > >> > >> > > > thanks for your reply. >> > >> > > > yes you are correct. The Bye doesn't have the Route header. >> > >> > > > It appears the the 200 OK sent to the caller doesn't >> contain a >> > >> > > > Record-route header. >> > >> > > > Messages between openser and callee contain record-route >> > >> information, >> > >> > > > but messages between caller and openser do not. >> > >> > > > Is there a way to enable that? >> > >> > > > >> > >> > > > Here's more detail: >> > >> > > > 192.168.0.101 = Caller (sipp) >> > >> > > > 1.2.3.4 = openser >> > >> > > > 4.3.2.1 = callee ( sipp) >> > >> > > > >> > >> > > > >> > >> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE >> > >> > > > sip:service@1.2.3.4:5060, with session description >> > >> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try >> > >> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE >> > >> > > > sip:service@4.3.2.1:5060, with session description >> > >> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing >> > >> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with >> > >> session >> > >> > > > description >> > >> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing >> > >> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with >> > >> session >> > >> > > > description >> > >> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK >> > >> > > > sip:service@1.2.3.4:5060 >> > >> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK >> > >> sip:service@4.3.2.1:5060 >> > >> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE >> > >> > > > sip:service@1.2.3.4:5060 >> > >> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE >> > >> sip:service@4.3.2.1:5060 >> > >> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK >> > >> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK >> > >> > > > >> > >> > > > --- >> > >> > > > Packets 6,7 and following contain no Record-route >> information. >> > >> > > > The other weird thing is that openser is passing on the >> Route: >> > >> header >> > >> > > > it recevied from callee to the caller. >> > >> > > > >> > >> > > > >> > >> > > > Please see attached for complete ngrep output. >> > >> > > > >> > >> > > > >> > >> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> >> wrote: >> > >> > > >> Hi Andy, >> > >> > > >> >> > >> > > >> could you check on the net if the BYE contain the Route hdr >> > >> added to >> > >> > > >> INVITE as Record-Route? I have some doubts on this as I see: >> > >> > > >> 0(966) find_first_route: No Route headers found >> > >> > > >> 0(966) loose_route: There is no Route HF >> > >> > > >> >> > >> > > >> and if the BYE is not identified, the dialog is not closed. >> > >> > > >> >> > >> > > >> regards, >> > >> > > >> bogdan >> > >> > > >> >> > >> > > >> Andy Pyles wrote: >> > >> > > >> > Hello, >> > >> > > >> > >> > >> > > >> > I have a question on how to configure the dialog module ( >> > >> 1.2.x from >> > >> > > >> > cvs yesterday ). >> > >> > > >> > >> > >> > > >> > With my config, ( attached) I can make calls and have >> > >> verified that >> > >> > > >> > the acc module is working correctly. >> > >> > > >> > >> > >> > > >> > My question is, when I enable the dialog module, I can see >> > >> that it is >> > >> > > >> > incrementing call count correctly, but when a bye is >> > >> received, the >> > >> > > >> > dialog:active_dialogs statistic is never decremented. >> > >> > > >> > >> > >> > > >> > In the debug level 9 logs, ( also attached) I see this >> error >> > >> after the >> > >> > > >> > 200OK is sent to the bye: >> > >> > > >> > >> > >> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 >> > >> > > >> (delete=0)-> 1 >> > >> > > >> > >> > >> > > >> > Is this a case of one of the timers being set too >> short? by >> > >> the way >> > >> > > >> > using a variable call length from well under a second ( >> > >> using sipp ) >> > >> > > >> > to 20 second call doesnt' seem to make a difference . >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > Thanks, >> > >> > > >> > Andy >> > >> > > >> > >> > >> >

2 3

[Users] Exported statistics and pseudo-variables
by Michel Bensoussan 26 Feb '07

26 Feb '07

Hello I didn't understand how to use the exported statistics and the pseudo-variables. In module dialog, active_dialogs is an exported statistic and $dlg_count a pseudo variable. How can I get them in code and in cfg file? Can I write in cfg file something like: if ($dlg_count > 10){...}? (not in this way of course but that's the idea). Thanks, Michel. PS: I didn't understand the example in http://www.openser.org/dokuwiki/doku.php/pseudovariables:1.1.x -- Michel Bensoussan Extricom Ltd. Tel-Aviv University, The Wolfson Computer and Software Engineering Building 30 Haim Levanon Street, P.O.B. 39040 Tel-Aviv, 61390 Israel Tel: +972 3 745 1000 ext 1065 Fax: +972 3 745 1001

2 5

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