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
>
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
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
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
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.htmlhttp://subversion.tigris.org/
OpenSER SVN page at sourceforge:
http://sourceforge.net/svn/?group_id=139143
Cheers,
Daniel
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
>> > >> > > >> >
>> >
>>
>
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
Hello all,
I am very new to openSER and have been going over MANY, MANY pages of info
on openSER (and SER) and am having a bit of a problem figuring out what
exactly i need to do for what I am trying to have happen.
Basically it's like this: I have a small company running a NATed asterisk
pbx (there is actually about 30 to 40 users already setup and using
Asterisk). Now I would like to add openSER to allow some outsourced/remote
users via voip so they may dial anyone in the company directly over their
voip connection. Basically, all asterisk users can call all asterisk users
and also call remote (openSER) users; and all remote (openSER) users can
call Asterisk users. I know Asterisk decently well, but I am not sure what
I would need to set up in openSER to handle this. My Asterisk box is
currently not set up for DB auth. I just have the users set up in sip.conf.
Re-doing the Asterisk box is absolutely out of the scope of this project. I
would just like to set up some remote users via openSER. (I do have a
public IP set up for my openSER box.)
Anyone have this type of setup going? Or anyone can tell me how this would
best be done? (I'd love to see an openser.cfg of this setup....)
Thanks in advance,
Ben Jeffries
fjsixty [at] gmail [dot] com
Hi,
I have the same problem.
When the SNOM ( 360 SIP 6.5.2 ) sends the REGISTER using TLS OpenSER
crashes.
I´m using
OpenSer (1.1.1-tls (i386/linux)),
openssl-0.9.7f-7.10
openssl-devel-0.9.7f-7.10
Fedora 2.6.11-1.1369_FC4
Any help?
Thanks
Paulo Angonese
[Users] CVS 31.03, TLS and dead tcp child
Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Oct 31 17:13:43 CET 2006
* Previous message: [Users] CVS 31.03, TLS and dead tcp child
* Next message: [Users] Q:ABOUTE:SET UP MESSAGE FLOW
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Frank,
can you pack the cores + binaries (lib + exe) + sources+logs(in debug
mode) and put it somewhere for download?
I will try to take a look.
regards,
Bogdan
Frank DInnocenzo wrote:
> Bogdan,
>
> I am using openser-1.1.0-tls_src. I actually get two core files after
> the crash. Can I post them somehow?
>
>
> # openser -V
> version: openser 1.1.0-tls (i386/linux)
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE,
> USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC,
> FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> @(#) $Id: main.c,v 1.20 2006/07/04 17:25:54 bogdan_iancu Exp $
> main.c compiled on 14:27:50 Oct 24 2006 with gcc 4.0.0
>
> Thanks
> Frank
>
>
> */Bogdan-Andrei Iancu <bogdan at voice-system.ro>/* wrote:
>
> Hi Frank,
>
> I'm successfully using a SNOM 320 with TLS and no problem so far.....
> What openser version are you using?...do you get any core file
> after the
> crash??
>
> regards,
> bogdan
>
> Frank DInnocenzo wrote:
>
> > Hello,
> >
> > I'm new to openSer and wondered if there was any resolution to this
> > post??? I'm hitting this same crash with openSer (with TLS enabled)
> > using a Snom phone (300 with latest Beta firmware -
> > snom300-6.5-SIP-j.bin ). I've gone
> > through the archives looking for help getting this setup
> working. I've
> > also tried the Snom Softphone with the same result.
> >
> > Thanks
> > Frank
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > Hi,
> >
> > I have tried to register to OpenSER CVS 31.03 with my SNOM 360
> > (5.3.6sw), disabled pretty all modules from OpenSER (radius,
> xlog, auth,
> > ...) and always the server crashes.
> >
> > Is there something I have missed in configuration ?
> >
> > Thanks a lot for help,
> > -Mika
> >
> > The error message and debug info seems like this:
> >
> > 11(24351) tcpconn_new: new tcp connection to: XXX.XX.XX.XXX
> > 11(24351) tcpconn_new: on port 2171, type 3
> > 11(24351) tls_tcpconn_init: Entered: Creating a whole new ssl
> connection
> > 11(24351) tls_tcpconn_init: Looking up tls domain
> [XXX.XX.XX.XXX:5061]
> > 11(24351) tls_tcpconn_init: Using default tls server settings
> > 11(24351) tls_tcpconn_init: Setting in ACCEPT mode (server)
> > 11(24351) tcpconn_add: hashes: 442, 1
> > 11(24351) handle_new_connect: new connection: 0xb608f6a0 24
> flags: 0002
> > 11(24351) send2child: to tcp child 0 7(24347), 0xb608f6a0
> > 7(24347) received n=4 con=0xb608f6a0, fd=19
> > 7(24347) DBG: io_watch_add(0x810e580, 19, 2, 0xb608f6a0), fd_no=1
> > 7(24347) tls_update_fd: New fd is 19
> > 11(24351) DBG: handle_tcp_child: dead tcp child 0 (pid 24347, no 7)
> > (shutting down?)
> > 11(24351) DBG: io_watch_del (0x810e420, 17, -1, 0x0) fd_no=16
called
> > 11(24351) ERROR: receive_fd: EOF on 15
> > 11(24351) DBG: handle_ser_child: dead child 7, pid 24347
> (shutting down?)
> > 11(24351) DBG: io_watch_del (0x810e420, 15, -1, 0x0) fd_no=15
called
> > 0(24339) child process 24347 exited by a signal 11
> > 0(24339) core was generated
> > 0(24339) INFO: terminating due to SIGCHLD
> > 6(24346) INFO: signal 15 received
> > 6(24346) Memory status (pkg):
