- freeswitch-dev@lists.freeswitch.org - FreeSWITCH Mailing Lists

Re: [Freeswitch-dev] Compiling error - libsndfile.so
by Anthony Minessale 12 Oct '06

12 Oct '06

Ok I'll try this one more time. BEGIN --------------------------------------------------------- Quite simple, When our build process gets to the module building stage, each module has it's own Makefile with targets to build it's own depends. it downloads the tarball with wget and configures it to the same target prefix as all of the others. The lines you pasted reflect that the directories in the install prefix and the cwd at build time contain the word "freeswitch" and does not imply much more than that. snippit of our mod_sndfile's Makefile depends: MAKE=$(MAKE) $(BASE)/build/buildlib.sh $(BASE) install libsndfile-1.0.16.tar.gz --prefix=$(PREFIX) --disable-sqlite Like I said we only host the exact tarball on our server, checksum it if you wish: http://svn.freeswitch.org/downloads/libs/libsndfile-1.0.16.tar.gz Feel free to see for yourself if you still do not believe me. http://svn.freeswitch.org/svn/freeswitch/trunk http://svn.freeswitch.org/svn/freeswitch/trunk/src/mod/formats/mod_sndfile/ Your library is a welcome addition as a module to our software and we have had little trouble with it, thank you. If you would reccommend we use the newer version let me know: anthmct(a)yahoo.com END --------------------------------------------------------- Stuart, Since this is a mailing list I am going to talk to some other people to save time on mutiple emails, excuse me a minute: Roman, Here is the downside to your suggestion, this guy is unhappy just because he *thinks* we keep his code in our tree. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@66.250.68.194 iax:guest@66.250.68.194/888 googletalk:freeswitch@gmail.com pstn:712-432-7800 ----- Original Message ---- From: Stuart <stuart(a)stu.org.uk> To: freeswitch-dev(a)lists.freeswitch.org Sent: Wednesday, October 11, 2006 2:37:26 AM Subject: Re: [Freeswitch-dev] Compiling error - libsndfile.so Anthony Minessale wrote: Reply to him and say We *do* use a pristine copy of thier tarball we just host it on our server to save you the bandwidth of people constantly downloading it we do not ship it with our source code so please do not make that assumption. Reply from libsndfile: Well then someone needs to explain this: > "/usr/local/freeswitch/include" > /usr/bin/install -c -m 644 'sndfile.h' > '/usr/local/freeswitch/include/sndfile.h' > make[5]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src' > make[4]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src' > make[3]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src' _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

4 3

Re: [Freeswitch-dev] Compiling error - libsndfile.so
by Anthony Minessale 11 Oct '06

11 Oct '06

Reply to him and say We *do* use a pristine copy of thier tarball we just host it on our server to save you the bandwidth of people constantly downloading it we do not ship it with our source code so please do not make that assumption. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@66.250.68.194 iax:guest@66.250.68.194/888 googletalk:freeswitch@gmail.com pstn:712-432-7800 ----- Original Message ---- From: Stuart <stuart(a)stu.org.uk> To: freeswitch-dev(a)lists.freeswitch.org Sent: Tuesday, October 10, 2006 2:47:39 PM Subject: Re: [Freeswitch-dev] Compiling error - libsndfile.so > Please report back your findings and also report this issue to the > libsndfile bug tracker. > > This the the reply I got from libsndfile: "YOu need to talk to the freeSWITCH people. They are shipping a specific version of libsndfile (1.0.16) with their code and I don't know if the sources are pristine or not. When you contact them about this issue, maybe you could recommend that they use the version of libsndfile from the installed distribution rather than shipping libnsdfile as part of their source code." _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

2 1

[Freeswitch-dev] SIP stack integrated in Solaris
by Roman Shaposhnik 11 Oct '06

11 Oct '06

FYI: http://www.opensolaris.org/os/project/network-sip/

1 0

[Freeswitch-dev] Skype integration in FreeSwitch
by Nikolay Kolev 10 Oct '06

10 Oct '06

Guys, recently there are two projects integrating Skype with Asterisk & SIP (http://www.rsdevs.com/ and also http://www.chanskype.com/) They are all paywarez. I know, I know - doing it their way sucks, but at the point there's no other way (even though the Chinese claim to have already reverse-engineered the Skype protocol - http://www.voipwiki.com/blog/?p=31) There's one IVR product (http://www.callbutler.com/) that also just added Skype support. VoxLib.com (even if I couldn't make it work) also does it. The old mate NCH also does it now - http://www.nch.com.au/skypetosip/index.html. I think it could be very cool even from pure marketing point of view to implement something like this in FreeSwitch. BTW, ChanSkype claims support for 30 channels and probably even more. Nikolay Kolev kolev @ #freeswitch

6 6

[Freeswitch-dev] Integration of external libraries into FreeSwitch
by Roman Shaposhnik 06 Oct '06

06 Oct '06

Guys, since I haven't got any major feedback on my suggestion of privatizing external libraries FreeSwitch depends upon I guess its time for me to give a practical example of how I would like FreeSwitch to be structured. Lets take libresample-0.1.3 as the simplest case (the meat of it is just 3 files: filterkit.c, resample.c, resamplesubs.c; the rest is precisely the fluff I'd like to get rid of): Anyway, here's what I would like to see in FreeSwitch's SVN instead: extlib/libresample/Makefile.[in|am] [ORIGIN|README] src/filterkit.c src/resample.c src/resamplesubs.c src/filterkit.h src/resample_defs.h [inc|include]/libresample.h ORIGIN (or README) file would describe where the library came from an what is the procedure for manually sync'ing up with the upstream development version (if needed). Makefile.[in|am] would mostly be from the original project (which means most of the time it would a trivial one) feeding off a *single* configure run. We can even introduce specific targets into it so that it does "export" public API header files and object files into a predetermined location for ease of future linking: extlib/lib extlib/include so that -I and -L have to point to a single location only (but still withing our build area which means no messy make install's!). PROS: * much greater control over how we build external libraries, which includes ease of using performance related options, building libraries as archives, etc. * much greater control over source code of the the external libraries (don't have to depend on maintainers to push changes we need ASAP). * everything is in SVN * single ./configure run * no messy make installs screwing up the place where --prefix points to * no LD_LIBRARY_PATH and LD_RUN_PATH mess to deal with CONS: * everytime we actually need something from the upstream version it would have to be manually sync'ed up with the FreeSwitch SVN (hence ORIGIN|README). And finally -- as far as Anthony's coding speed is concerned it should be pretty transparent ;-), so what do you all think ? Thanks, Roman.

6 7

[Freeswitch-dev] mod_ruby
by Brian Fertig 05 Oct '06

05 Oct '06

To all who love ruby so.. I got a email back from Matz today who said he will agree to issue a license to us. So mod_ruby is here to stay! Brian

13 16

[Freeswitch-dev] DSO library management issues
by Roman Shaposhnik 01 Oct '06

01 Oct '06

Hi Guys! I'm getting pretty close to having FreeSwitch up and running on a SPARC Solaris Niagara box (yeah -- that's the one with 8 physical cores and 32 threads per CPU) which is a good news. The bad news (at least from my POV) is that I think I've stumbled upon a particular problem in how FreeSwitch gets built and packaged for which I don't really have a good solution. So, in order for me to move forward I have to make sure that you guys also view this as an issue and that you'd be willing to address it. Here's the deal -- its no secret that FreeSwitch depends on DSOs a *LOT* (in fact, the core of FreeSwitch itself is a DSO library with a simple wrapper bin/freeswitch around it). In general I would divide these DSOs into 3 broad categories: 1. Plugin/modules (including CORE) These guys posses no problem whatsoever -- they get developed within the FreeSwitch SVN repository, they DO NOT get distributed outside of FreeSwitch. They also get built as part of building FreeSwitch. Always. The only trouble with them is that sometimes they depend on functionality available only from external libraries. And that leads us to the following 2 categories: 2. Well-known external DSO libraries These are the things you would expect to see on a reasonably well configured Linux system these days. Things like /usr/lib/libsqlite3.so or /usr/lib/libapr.so.0. Things which get developed elsewhere, have their dedicated maintainers and packagers. And which are relatively easy to find in .RPMs or .DEBs. 3. DSO libraries originating from the FreeSwitch project itself. Now in this category I don't want to discriminate between something that Anthony has written (i.e. libteletone) or something that just got sucked into FreeSwitch for a lack of a better home (i.e. lib/codec/g726). All of these things Now, why am I telling you all this ? :-) Well, simply because during my Solaris "porting" effort I've really convinced myself that we have to have a much better plan for #2 and #3 w.r.t. building and packaging than what we have in FreeSwitch now. And here's why: 1. For the #2 I really don't want to sit through the endless stream of ./configure ; make ; make install if I already have these libraries on my system. What I want instead is a detection mechanism (or --with-<package name>= option for a configure script) that would also warn me about the version FreeSwitch developers deem to be appropriate for each of the packages. 2. As for the #3... my take on it is that we shouldn't really have #3 in FreeSwitch at all. Every single library from that category should either be moved to #1 or to #2. If it ends up being in #2 than it has to be moved to a separate SVN repo. So consider all of the above as a preliminary request for opinions and lets hope to make FreeSwitch really portable and highly configurable at the building and packaging level! Thanks, Roman.

2 2

Re: [Freeswitch-dev] DSO library management issues
by Anthony Minessale 01 Oct '06

01 Oct '06

There are a few good explanations (I hope). I have chosesn to build all of the code used in the program for a few reasons: 1) To ensure proper configuration and versioning. a) We have no control over what options the default system libs were built with (thread saftey options etc). b) As a side-effect of our extensive push on our dependancies, we often need the code to be modified to work properly due to necessary modifications or bugfixes that only exist in our private tarball while we wait for a new version to be released. c) Most distros do not provide cutting edge releases of libraries which be necessary due to results from sub-reason (b) 2) To create a atonomous environment. a) The defualt install prefix is /usr/local/freeswitch all of the depends are installed in this dir so you can subsequently tar up that directory and move it to another machine without installing it again. b) Some systems have slightly different versions of the same libraries that do not co-exist well we never need to look outside of our own lib dir for these libraries. I am fairly concerned with making huge initiatives in the build process during a time where I am still coding 12 hours a day on the core but I am open to improvement as long as the tangent does not impeed my development effort. Imagine if someone wanted to install superior scafolding while the guy is on top of it building the house still. Once development shifts to higher level stuff my concerns will most likely subside. One bright note is if you dont watch during the endless stream of ./configure make ; make install, it goes faster (a watched pot never boils) =D And that only happens the first time, subsequent builds go much faster. I am truely anxious to see what happens on this super sun box and I'd like to thank you for your efforts and your valuable time I really appriciate your help. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@66.250.68.194 iax:guest@66.250.68.194/888 googletalk:freeswitch@gmail.com pstn:712-432-7800 ----- Original Message ---- From: Roman Shaposhnik <rvs(a)sun.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Saturday, September 30, 2006 1:02:01 AM Subject: [Freeswitch-dev] DSO library management issues Hi Guys! I'm getting pretty close to having FreeSwitch up and running on a SPARC Solaris Niagara box (yeah -- that's the one with 8 physical cores and 32 threads per CPU) which is a good news. The bad news (at least from my POV) is that I think I've stumbled upon a particular problem in how FreeSwitch gets built and packaged for which I don't really have a good solution. So, in order for me to move forward I have to make sure that you guys also view this as an issue and that you'd be willing to address it. Here's the deal -- its no secret that FreeSwitch depends on DSOs a *LOT* (in fact, the core of FreeSwitch itself is a DSO library with a simple wrapper bin/freeswitch around it). In general I would divide these DSOs into 3 broad categories: 1. Plugin/modules (including CORE) These guys posses no problem whatsoever -- they get developed within the FreeSwitch SVN repository, they DO NOT get distributed outside of FreeSwitch. They also get built as part of building FreeSwitch. Always. The only trouble with them is that sometimes they depend on functionality available only from external libraries. And that leads us to the following 2 categories: 2. Well-known external DSO libraries These are the things you would expect to see on a reasonably well configured Linux system these days. Things like /usr/lib/libsqlite3.so or /usr/lib/libapr.so.0. Things which get developed elsewhere, have their dedicated maintainers and packagers. And which are relatively easy to find in .RPMs or .DEBs. 3. DSO libraries originating from the FreeSwitch project itself. Now in this category I don't want to discriminate between something that Anthony has written (i.e. libteletone) or something that just got sucked into FreeSwitch for a lack of a better home (i.e. lib/codec/g726). All of these things Now, why am I telling you all this ? :-) Well, simply because during my Solaris "porting" effort I've really convinced myself that we have to have a much better plan for #2 and #3 w.r.t. building and packaging than what we have in FreeSwitch now. And here's why: 1. For the #2 I really don't want to sit through the endless stream of ./configure ; make ; make install if I already have these libraries on my system. What I want instead is a detection mechanism (or --with-<package name>= option for a configure script) that would also warn me about the version FreeSwitch developers deem to be appropriate for each of the packages. 2. As for the #3... my take on it is that we shouldn't really have #3 in FreeSwitch at all. Every single library from that category should either be moved to #1 or to #2. If it ends up being in #2 than it has to be moved to a separate SVN repo. So consider all of the above as a preliminary request for opinions and lets hope to make FreeSwitch really portable and highly configurable at the building and packaging level! Thanks, Roman. _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

2 1

[Freeswitch-dev] Solaris build/DTrace status
by Roman Shaposhnick 27 Sep '06

27 Sep '06

Hi Guys! First of all after poking around freeswitch source code a bit I've decided that personally I would really like to apply DTrace to it to see what's going on w.r.t. threading. Hence I really need to make sure that it builds on Solaris10/SPARC. Because of that I decided to put other things (like PerfAnalyzing it on Linux on a backburner) and focus on at least building it on Solaris. I think I'm making some progress there, but it also seems to me that your build process might need a bit of a cleanup. Little things like specifying #!/bin/sh but actually expecting bash. Little things -- but they do add up. Thanks, Roman. P.S. And if anybody has any tips for me w.r.t. SPARC/Solaris build I'd be more than happy to hear them.

6 6

[Freeswitch-dev] mod_cepstral and session.hangup() in javascript
by Nikolay Kolev 21 Sep '06

21 Sep '06

Hi all! On September 9 there was a change in mod_cepstral to switch to dynamic buffers, but at the same time the buffer size got reduced. As a result, the module broke and in some situations it cut off sounds, crapping out totally the TTS. I restore the buffer size to the old value (1024 * 256) and it works perfectly again! Can somebody patch the trunk as most probably I don't have the rights to do so. Also, some of the commits to the core today fixed the problem with session.hangup() in javascript not closing the session. Now, it works properly! Thanks, guys! Nikolay Kolev kolev @ #freenode

2 4