- FreeSWITCH-dev - FreeSWITCH Mailing Lists

Record in WAV IEEE float format
by Zoltán Szabó 24 Jul '15

24 Jul '15

Hi, I would like to record in Wave IEEE float signed 32bit, 8000hz 256kbps, mono format. For this I can set the record_stereo to false in the session and tried to modify mod_sndfile.c to configure the format, so far I tried like: if (mode & SFM_WRITE) { context->sfinfo.channels = handle->channels; context->sfinfo.samplerate = handle->samplerate; context->sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_FLOAT; } But I receive some weird data when trying to load up the wav in goldwave. The format looks fine but the data is not. Do you have any suggestion? Many thanks, Zoltan

1 0

I have a php script run by ivrd, is it possible to subscribe to events on this outbound eslconnection
by jaflong jaflong 22 Jul '15

22 Jul '15

I have a php script run by ivrd, is it possible to subscribe to events on this outbound eslconnection

1 0

Verto commands, guaranteed order?
by Chad Phillips 20 Jul '15

20 Jul '15

Are API commands sent via Verto guaranteed to be executed on the server in the order they are sent from the Verto client?

3 2

Sending non-integer id values for conference commands in Verto.
by Chad Phillips 19 Jul '15

19 Jul '15

I’ve been able to send conference commands through Verto successfully. However, I’ve discovered a limitation in the functionality — commands can only be sent if they are for a specific conferee, by their member_id. This is so because conference_event_mod_channel_handler() in conference_event.c forces the id argument passed via verto.broadcast to be an integer. The reason I’m starting here instead of a Jira is that I’m unsure if this is by design or is a bug or missing feature. Do y’all want this handler function to be able to accept the full range of values supported by the underlying mod_conference API? Most conference API commands that accept a member_id also have some selector strings you can use as well (all|last|non_moderaor) — these currently all fail when sent via Verto because of the above-mentioned implementation. My view is that since these are exposed as commands available to a moderator, and the moderator already has the capability to perform these commands on any conferee, there should be no issue supporting the other selectors from a security standpoint. What I’d like to do is submit a patch to fix this issue, if y’all do in fact think that’s the best approach. If yes to a patch, some feedback on the best implementation would also be helpful. The easiest implementation would be to always treat id as a string, and let the underlying conference API throw an error if an invalid value is passed. As soon as I get some feedback I’m happy to start working on the patch. Chad

1 0

FreeSWITCH Friday FreeForAll Reminder!
by Ken Rice 17 Jul '15

17 Jul '15

FreeSWITCHers, Do not forget to join us at 2PM CST for the FreeSWITCH Friday FreeFor All Visit http://ift.tt/1n3h0Pf and Click Call 888 with your WebRTC enabled Browser and headset, Call sip:888@conference.freeswitch.org or see http://ift.tt/1prwIZL for access info! -- Ken FreeSWITCH.org ClueCon.com OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH @ClueCon

1 0

Re: [Freeswitch-dev] FreeSWITCH-dev Digest, Vol 108, Issue 9
by sasa.ivancev 15 Jul '15

15 Jul '15

U Sent from Samsung Mobile -------- Original message -------- From: freeswitch-dev-request(a)lists.freeswitch.org Date: 25/06/2015 23:38 (GMT+01:00) To: freeswitch-dev(a)lists.freeswitch.org Subject: FreeSWITCH-dev Digest, Vol 108, Issue 9 Send FreeSWITCH-dev mailing list submissions to freeswitch-dev(a)lists.freeswitch.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev or, via email, send a message with subject or body 'help' to freeswitch-dev-request(a)lists.freeswitch.org You can reach the person managing the list at freeswitch-dev-owner(a)lists.freeswitch.org When replying, please edit your Subject line so it is more specific than "Re: Contents of FreeSWITCH-dev digest..." Today's Topics: 1. Re: Video build deps for CentOS 6 (Matteo) 2. Re: Video build deps for CentOS 6 (Michael Jerris) 3. Re: Video build deps for CentOS 6 (Matteo) well, rpmforge is even older than rpmfusion. Rpmfusion is well known, but if vlc is going to be dropped (will it?) we can skip it entirely and reduce the number of packages. Imagemagick is needed to be updated only for mod_imagick, otherwise is not needed. If we limit everything on what is on SD repo (and exclude vlc+mod_imagick) well I think (but must check) that epel is enough and only few stuff must be added (mpg123, lame?, libshout, libmpv2 and maybe nasm). But I need to recheck it since I tried to have everything fs 1.6 needs, with the correct versions. there's one dep on freetype2 is FS which is not really needed, I'll file a pull rq for it, so we can avoid updating it. (you need 2.4.something but with 2.3.11 compiles and works ok) About libpng: I've used the CentOS shipped one and seems to work ok (version 1.2.49) to me. So, I think most of the work is around vlc: you say that does not work well, what will be it's destiny? If is just an experiment I can try to rebuild everything without it and check what is needed again in order to shrink that list (it will be a lot shorter) and report back. I'm not sure about mod_imagick, not tested it yet. Another question about mp3 code: what about mpg123/lame that is needed by FS? If you're not willing to add it to your repo, how mp3 files are handled ? using libav ? If yes, another dep can be removed. matteo ----- Il 25-giu-15, alle 21:22, Michael Jerris mike(a)jerris.com ha scritto: > I have no issues rebuilding some packages for never version in our repos... The > big issues are, we will not put binaries of any of the mp3 or h264 code in our > repos, and we are not going to include documentation pointing to non-reputable > 3rd party repos. I'm open to pointing to rpmforge if we can put together some > documentation that won't result in complete nightmares from version conflicts > from all the different repos, but I'm not sure this is possible, can we craft a > meta package that helps nail down the specific versions to use, or to somehow > blacklist all but a small list of packages from rpmforge? In regards to VLC, to > be honest, I'd skip it completely, it adds little value and doesn't work great. > The one you want to get working is libav or ffmpeg built against x264. The > trick is you'll need to audit the versions of all these things you are talking > about updating and figuring out if the upgrades are even actually necessary > Please note that libav will need to be rebuilt for sure so its built against > our version of libvpx, and if not already done, some other libs will need to be > rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be > updated to our versions. Additionally some of the libs in our tree may exist in > other distros, but ours are actually different api/abi but have the same name, > and the ones in the distros are broken. For example libilbc. I have not yet > audited to see if ours has enough backwards api that it could be updated in > distro repos to replace their broken one. Most of the version limits that are > in place are those versions based on thats what we have in debian jessie that > is tested and confirmed working. Its likely you can use older versions, but > functionality will need to be tested to confirm on a library by library basis. > > Hi, > > ----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com ha scritto: > >> for things like nasm, is that newer version out there for example in epel? that >> > would be the best case. Sure, the work I've done is already based on epel, so >> what is in epel is not built again. > > I've rebuilt some epel packages only when a newer version is needed. > >> Backup would be to take a source pacakge from something > newer and just rebuild >> in a way that doesn't require any modifications, > fallback we can put the src >> out on our download servers and create a job for > it. As for x264, we will not >> be putting that in our repo, you'll have to find > some way to get that into >> some official repo that we can reference, maybe see > if you can get it into >> epel? The best case would be to get as much as possible > directly into epel so >> it leaves us having to manage as little as possible. The main "source" of deps >> (and troubles) is vlc 2.2, which needs a lot of stuff. > > I've taken some packages from rpmfusion and rebuilt them, updating when needed. > > So while epel is needed for deps, rpmfusion is not because all needed rpmfusion > packages have been rebuilt by me using same sources/specs (if not updated) > > I don't know if epel will ever accept all packages, because some are also > updates > to base system, like opencv which is present on CentOS base but too old and > ImageMagick, to name few. > > So the picture is: if you want to have video under CentOS 6 without hosting > something (mainly vlc stuff and it's deps), you're out of luck since FS > requirements are on very recent packages. > > Just a quick list of stuff needed: > > base CentOS updates not present anywhere: > ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated) > > ** from rpmfusion: > a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated > for vlc 2.2), > xvidcore > > ** from epel (rebuilt because different version) > libmpv2(updated), libshout(updated) > > ** from Freeswitch SD: > g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, > soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!) > > This is the list (should be almost complete, I'm not in the office right now) > of what I've rebuit to have video running. > > Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is > wanted or not. > > I think that epel will never accept updates to packages that are already into > base distro. > > And don't know about vlc and its deps... if rpmfusion exists maybe is because > patents > does not allow it into epel? > > What do you think? > > Matteo > > > > > On Jun 25, 2015, at 1:45 PM, Michael Jerris < mike(a)jerris.com > wrote: > > for things like nasm, is that newer version out there for example in epel? that > would be the best case. Backup would be to take a source pacakge from something > newer and just rebuild in a way that doesn't require any modifications, > fallback we can put the src out on our download servers and create a job for > it. As for x264, we will not be putting that in our repo, you'll have to find > some way to get that into some official repo that we can reference, maybe see > if you can get it into epel? The best case would be to get as much as possible > directly into epel so it leaves us having to manage as little as possible. > > On Thursday, June 25, 2015, Matteo < mbrancaleoni(a)voismart.it > wrote: > > > > I know how specs works, I'm maintaining a private repo like epel with tens of > packages since years, using the same tools used by fedora ( koji, mock, mash). > > My intent is not to create a custom build of freeswitch, but a repo like epel or > rpmfusion with only the needed build deps. > > What is not clear to me is the flow to add a new dep. > > Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a > few. > > Which is the correct approach to fit into Fs build structure? > > Mat > > Inviato da iPhone > >> Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto: >> >> You know in the spec files you can if things for specific versions... You'll >> just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse >> >> >>> On 6/25/15, 11:03 AM, "Matteo" wrote: >>> >>> Ok, >>> >>> since some packages are only centos 6 specific updates, how do you plan to >>> handle them? >>> >>> For example, nasm is a required update to CentOS 6 in order to build other >>> stuff, >>> but is not needed for debian or CentOS 7 >>> >>> Right now in the repo I don't see anything distro-specific . >>> >>> >>> Regards, >>> Matteo >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> 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 >> >> -- >> Ken >> http://www.FreeSWITCH.org >> http://www.ClueCon.com >> http://www.OSTAG.org >> irc.freenode.net #freeswitch >> Twitter: @FreeSWITCH >> >> >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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 > On Jun 25, 2015, at 4:02 PM, Matteo <mbrancaleoni(a)voismart.it> wrote: > > well, rpmforge is even older than rpmfusion. > > Rpmfusion is well known, but if vlc is going to be dropped (will it?) we can > skip it entirely and reduce the number of packages. It's not getting dropped but it is of limited value, mod_av does nearly everything mod_vlc does, and does it better, the only thing it doesn't do is play youtube videos by youtube url. Seems a minor feature for a massive dependency chain. I'd say just don't bother trying to include it. In regards to mod_av, you only get the functionality people probably want (and same for vlc) if its built against x264, which again, we may have issues finding a package in a reputable repo. > > Imagemagick is needed to be updated only for mod_imagick, otherwise is not needed. mod_imagick supports playing pdf files like videos. Its useful but your call. > > If we limit everything on what is on SD repo (and exclude vlc+mod_imagick) well I think > (but must check) that epel is enough and only few stuff must be added > (mpg123, lame?, libshout, libmpv2 and maybe nasm). > But I need to recheck it since I tried to have everything fs 1.6 needs, with the correct > versions. Just to be completely 100% clear, we will not be serving up mp3 or h264 binaries from our repos. > > there's one dep on freetype2 is FS which is not really needed, I'll file a pull rq for it, > so we can avoid updating it. (you need 2.4.something but with 2.3.11 compiles and works ok) We for sure need freetype to support a bunch of features that have to do with putting text on video, and it will require rebuilding it against libpng 1.6 for some basic functionality, while these are already optional, this will significantly impact some conference functionality. > > About libpng: I've used the CentOS shipped one and seems to work ok (version 1.2.49) to me. libpng1.6 is required for some transparency functionality that we use heavily. It will build with older versions, but functionality will be significantly diminished. > > So, I think most of the work is around vlc: you say that does not work well, > what will be it's destiny? We are not getting rid of it, but my recommendation would be to not try to build it. I already spend significant time telling people to use mod_av instead. > If is just an experiment I can try to rebuild everything without it and check what is needed again > in order to shrink that list (it will be a lot shorter) and report back. > > I'm not sure about mod_imagick, not tested it yet. > > Another question about mp3 code: what about mpg123/lame that is needed by FS? These can't go into our repo, but any moderately recent one should be fine. I think the api is stable. The issue with using older versions would be if it will cause stability issues and crashing, as there has been a long list of buffer overflow issues in that code over the years. > If you're not willing to add it to your repo, how mp3 files are handled ? using libav ? If there is no other place to get packages for that library, the module simply wouldn't be built, and that feature would not be available. > If yes, another dep can be removed. > > matteo > > ----- Il 25-giu-15, alle 21:22, Michael Jerris mike(a)jerris.com ha scritto: > >> I have no issues rebuilding some packages for never version in our repos... The >> big issues are, we will not put binaries of any of the mp3 or h264 code in our >> repos, and we are not going to include documentation pointing to non-reputable >> 3rd party repos. I'm open to pointing to rpmforge if we can put together some >> documentation that won't result in complete nightmares from version conflicts >> from all the different repos, but I'm not sure this is possible, can we craft a >> meta package that helps nail down the specific versions to use, or to somehow >> blacklist all but a small list of packages from rpmforge? In regards to VLC, to >> be honest, I'd skip it completely, it adds little value and doesn't work great. >> The one you want to get working is libav or ffmpeg built against x264. The >> trick is you'll need to audit the versions of all these things you are talking >> about updating and figuring out if the upgrades are even actually necessary >> Please note that libav will need to be rebuilt for sure so its built against >> our version of libvpx, and if not already done, some other libs will need to be >> rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be >> updated to our versions. Additionally some of the libs in our tree may exist in >> other distros, but ours are actually different api/abi but have the same name, >> and the ones in the distros are broken. For example libilbc. I have not yet >> audited to see if ours has enough backwards api that it could be updated in >> distro repos to replace their broken one. Most of the version limits that are >> in place are those versions based on thats what we have in debian jessie that >> is tested and confirmed working. Its likely you can use older versions, but >> functionality will need to be tested to confirm on a library by library basis. >> >> Hi, >> >> ----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com ha scritto: >> >>> for things like nasm, is that newer version out there for example in epel? that >>>> would be the best case. Sure, the work I've done is already based on epel, so >>> what is in epel is not built again. >> >> I've rebuilt some epel packages only when a newer version is needed. >> >>> Backup would be to take a source pacakge from something > newer and just rebuild >>> in a way that doesn't require any modifications, > fallback we can put the src >>> out on our download servers and create a job for > it. As for x264, we will not >>> be putting that in our repo, you'll have to find > some way to get that into >>> some official repo that we can reference, maybe see > if you can get it into >>> epel? The best case would be to get as much as possible > directly into epel so >>> it leaves us having to manage as little as possible. The main "source" of deps >>> (and troubles) is vlc 2.2, which needs a lot of stuff. >> >> I've taken some packages from rpmfusion and rebuilt them, updating when needed. >> >> So while epel is needed for deps, rpmfusion is not because all needed rpmfusion >> packages have been rebuilt by me using same sources/specs (if not updated) >> >> I don't know if epel will ever accept all packages, because some are also >> updates >> to base system, like opencv which is present on CentOS base but too old and >> ImageMagick, to name few. >> >> So the picture is: if you want to have video under CentOS 6 without hosting >> something (mainly vlc stuff and it's deps), you're out of luck since FS >> requirements are on very recent packages. >> >> Just a quick list of stuff needed: >> >> base CentOS updates not present anywhere: >> ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated) >> >> ** from rpmfusion: >> a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated >> for vlc 2.2), >> xvidcore >> >> ** from epel (rebuilt because different version) >> libmpv2(updated), libshout(updated) >> >> ** from Freeswitch SD: >> g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, >> soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!) >> >> This is the list (should be almost complete, I'm not in the office right now) >> of what I've rebuit to have video running. >> >> Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is >> wanted or not. >> >> I think that epel will never accept updates to packages that are already into >> base distro. >> >> And don't know about vlc and its deps... if rpmfusion exists maybe is because >> patents >> does not allow it into epel? >> >> What do you think? >> >> Matteo >> >> >> >> >> On Jun 25, 2015, at 1:45 PM, Michael Jerris < mike(a)jerris.com > wrote: >> >> for things like nasm, is that newer version out there for example in epel? that >> would be the best case. Backup would be to take a source pacakge from something >> newer and just rebuild in a way that doesn't require any modifications, >> fallback we can put the src out on our download servers and create a job for >> it. As for x264, we will not be putting that in our repo, you'll have to find >> some way to get that into some official repo that we can reference, maybe see >> if you can get it into epel? The best case would be to get as much as possible >> directly into epel so it leaves us having to manage as little as possible. >> >> On Thursday, June 25, 2015, Matteo < mbrancaleoni(a)voismart.it > wrote: >> >> >> >> I know how specs works, I'm maintaining a private repo like epel with tens of >> packages since years, using the same tools used by fedora ( koji, mock, mash). >> >> My intent is not to create a custom build of freeswitch, but a repo like epel or >> rpmfusion with only the needed build deps. >> >> What is not clear to me is the flow to add a new dep. >> >> Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a >> few. >> >> Which is the correct approach to fit into Fs build structure? >> >> Mat >> >> Inviato da iPhone >> >>> Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto: >>> >>> You know in the spec files you can if things for specific versions... You'll >>> just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse >>> >>> >>>> On 6/25/15, 11:03 AM, "Matteo" wrote: >>>> >>>> Ok, >>>> >>>> since some packages are only centos 6 specific updates, how do you plan to >>>> handle them? >>>> >>>> For example, nasm is a required update to CentOS 6 in order to build other >>>> stuff, >>>> but is not needed for debian or CentOS 7 >>>> >>>> Right now in the repo I don't see anything distro-specific . >>>> >>>> >>>> Regards, >>>> Matteo >>>> >>>> _________________________________________________________________________ >>>> Professional FreeSWITCH Consulting Services: >>>> consulting(a)freeswitch.org >>>> http://www.freeswitchsolutions.com >>>> >>>> Official FreeSWITCH Sites >>>> http://www.freeswitch.org >>>> http://wiki.freeswitch.org >>>> http://www.cluecon.com >>>> >>>> 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 >>> >>> -- >>> Ken >>> http://www.FreeSWITCH.org >>> http://www.ClueCon.com >>> http://www.OSTAG.org >>> irc.freenode.net #freeswitch >>> Twitter: @FreeSWITCH >>> >>> >>> >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> 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 >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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 Uhm, while I get more informations, I get more confused :) Or, at least, seems to be that is not possible to have a 100% working install on CentOS 6. Both rpmforge and rpmfusion has mpg123 and lame, so mp3 functions can be kept. Dropping mp3 support is just not feasible imho, since is a heavily used format. If rpmfusion is not very trusted (nothing for el7 yet) there's handbrake repo which is heavily focused on video ( http://negativo17.org/repos/HandBrake/ ) and has (updated) x264 stuff. x264 stuff on rpmforge is just too old. ( handbrake is a really powerful video transcoder, so for me can be trusted :) ) Combining both we may have a full mp3/h264 support. What do you think? libpng 1.6 and freetype2 compiled against it is a different story. Even CentOS 7 does not have libpng 1.6. And since is a quite "basic" lib I think is not sane to try to update it. How do you handle them in jessie ? With two separate packages that do not overlap with system one and pointing FS build to it? (I see that also jessie has libpng12 and freetype linked against it) So, to sum up, right now I see this: * include 2 new repos: rpmforge and handbrake for mp3+h264 . The question is if both are trusted enough. Of course testing is needed. * try to build a separate freetype2+libpng16 and out that into SD repo for CentOS * regarding mod_imagick, I'm still testing the situation, while I've already updated ImageMagick for fax conversion purposes since months without issues in production, I need to check it better with the new Fs module. What do you think? regards, Matteo PS: just for curiosity, why you do not want to host mp3 and h264 code? You already host openh264, is not the same issue? ----- Il 25-giu-15, alle 22:23, Michael Jerris mike(a)jerris.com ha scritto: >> On Jun 25, 2015, at 4:02 PM, Matteo <mbrancaleoni(a)voismart.it> wrote: >> >> well, rpmforge is even older than rpmfusion. >> >> Rpmfusion is well known, but if vlc is going to be dropped (will it?) we can >> skip it entirely and reduce the number of packages. > > It's not getting dropped but it is of limited value, mod_av does nearly > everything mod_vlc does, and does it better, the only thing it doesn't do is > play youtube videos by youtube url. Seems a minor feature for a massive > dependency chain. I'd say just don't bother trying to include it. In regards > to mod_av, you only get the functionality people probably want (and same for > vlc) if its built against x264, which again, we may have issues finding a > package in a reputable repo. > >> >> Imagemagick is needed to be updated only for mod_imagick, otherwise is not >> needed. > > mod_imagick supports playing pdf files like videos. Its useful but your call. > >> >> If we limit everything on what is on SD repo (and exclude vlc+mod_imagick) well >> I think >> (but must check) that epel is enough and only few stuff must be added >> (mpg123, lame?, libshout, libmpv2 and maybe nasm). >> But I need to recheck it since I tried to have everything fs 1.6 needs, with the >> correct >> versions. > > Just to be completely 100% clear, we will not be serving up mp3 or h264 binaries > from our repos. > >> >> there's one dep on freetype2 is FS which is not really needed, I'll file a pull >> rq for it, >> so we can avoid updating it. (you need 2.4.something but with 2.3.11 compiles >> and works ok) > > We for sure need freetype to support a bunch of features that have to do with > putting text on video, and it will require rebuilding it against libpng 1.6 for > some basic functionality, while these are already optional, this will > significantly impact some conference functionality. > >> >> About libpng: I've used the CentOS shipped one and seems to work ok (version >> 1.2.49) to me. > > libpng1.6 is required for some transparency functionality that we use heavily. > It will build with older versions, but functionality will be significantly > diminished. > >> >> So, I think most of the work is around vlc: you say that does not work well, >> what will be it's destiny? > > We are not getting rid of it, but my recommendation would be to not try to build > it. I already spend significant time telling people to use mod_av instead. > >> If is just an experiment I can try to rebuild everything without it and check >> what is needed again >> in order to shrink that list (it will be a lot shorter) and report back. >> >> I'm not sure about mod_imagick, not tested it yet. >> >> Another question about mp3 code: what about mpg123/lame that is needed by FS? > > These can't go into our repo, but any moderately recent one should be fine. I > think the api is stable. The issue with using older versions would be if it > will cause stability issues and crashing, as there has been a long list of > buffer overflow issues in that code over the years. > >> If you're not willing to add it to your repo, how mp3 files are handled ? using >> libav ? > > If there is no other place to get packages for that library, the module simply > wouldn't be built, and that feature would not be available. > >> If yes, another dep can be removed. >> >> matteo >> >> ----- Il 25-giu-15, alle 21:22, Michael Jerris mike(a)jerris.com ha scritto: >> >>> I have no issues rebuilding some packages for never version in our repos... The >>> big issues are, we will not put binaries of any of the mp3 or h264 code in our >>> repos, and we are not going to include documentation pointing to non-reputable >>> 3rd party repos. I'm open to pointing to rpmforge if we can put together some >>> documentation that won't result in complete nightmares from version conflicts >>> from all the different repos, but I'm not sure this is possible, can we craft a >>> meta package that helps nail down the specific versions to use, or to somehow >>> blacklist all but a small list of packages from rpmforge? In regards to VLC, to >>> be honest, I'd skip it completely, it adds little value and doesn't work great. >>> The one you want to get working is libav or ffmpeg built against x264. The >>> trick is you'll need to audit the versions of all these things you are talking >>> about updating and figuring out if the upgrades are even actually necessary >>> Please note that libav will need to be rebuilt for sure so its built against >>> our version of libvpx, and if not already done, some other libs will need to be >>> rebuilt against libpng 1.6 or greater. Those 2 libraries for sure need to be >>> updated to our versions. Additionally some of the libs in our tree may exist in >>> other distros, but ours are actually different api/abi but have the same name, >>> and the ones in the distros are broken. For example libilbc. I have not yet >>> audited to see if ours has enough backwards api that it could be updated in >>> distro repos to replace their broken one. Most of the version limits that are >>> in place are those versions based on thats what we have in debian jessie that >>> is tested and confirmed working. Its likely you can use older versions, but >>> functionality will need to be tested to confirm on a library by library basis. >>> >>> Hi, >>> >>> ----- Il 25-giu-15, alle 19:45, Michael Jerris mike at jerris.com ha scritto: >>> >>>> for things like nasm, is that newer version out there for example in epel? that >>>>> would be the best case. Sure, the work I've done is already based on epel, so >>>> what is in epel is not built again. >>> >>> I've rebuilt some epel packages only when a newer version is needed. >>> >>>> Backup would be to take a source pacakge from something > newer and just rebuild >>>> in a way that doesn't require any modifications, > fallback we can put the src >>>> out on our download servers and create a job for > it. As for x264, we will not >>>> be putting that in our repo, you'll have to find > some way to get that into >>>> some official repo that we can reference, maybe see > if you can get it into >>>> epel? The best case would be to get as much as possible > directly into epel so >>>> it leaves us having to manage as little as possible. The main "source" of deps >>>> (and troubles) is vlc 2.2, which needs a lot of stuff. >>> >>> I've taken some packages from rpmfusion and rebuilt them, updating when needed. >>> >>> So while epel is needed for deps, rpmfusion is not because all needed rpmfusion >>> packages have been rebuilt by me using same sources/specs (if not updated) >>> >>> I don't know if epel will ever accept all packages, because some are also >>> updates >>> to base system, like opencv which is present on CentOS base but too old and >>> ImageMagick, to name few. >>> >>> So the picture is: if you want to have video under CentOS 6 without hosting >>> something (mainly vlc stuff and it's deps), you're out of luck since FS >>> requirements are on very recent packages. >>> >>> Just a quick list of stuff needed: >>> >>> base CentOS updates not present anywhere: >>> ImageMagick (updated), nasm(updated), libvncserver(updated), opencv(updated) >>> >>> ** from rpmfusion: >>> a52dec, faad2, gpac, lame, vlc(updated), libmad, mpg123(updated), x264(updated >>> for vlc 2.2), >>> xvidcore >>> >>> ** from epel (rebuilt because different version) >>> libmpv2(updated), libshout(updated) >>> >>> ** from Freeswitch SD: >>> g722_1, broadvoice, libav, libcodec2, libsilk, libvpx, libyuv(updated), opus, >>> soundtouch, openh264, flite, ilbc (epel has a newer one, pay attention!) >>> >>> This is the list (should be almost complete, I'm not in the office right now) >>> of what I've rebuit to have video running. >>> >>> Is possible to reduce by 6 packages if rpmfusion is added with repo. Dunno if is >>> wanted or not. >>> >>> I think that epel will never accept updates to packages that are already into >>> base distro. >>> >>> And don't know about vlc and its deps... if rpmfusion exists maybe is because >>> patents >>> does not allow it into epel? >>> >>> What do you think? >>> >>> Matteo >>> >>> >>> >>> >>> On Jun 25, 2015, at 1:45 PM, Michael Jerris < mike(a)jerris.com > wrote: >>> >>> for things like nasm, is that newer version out there for example in epel? that >>> would be the best case. Backup would be to take a source pacakge from something >>> newer and just rebuild in a way that doesn't require any modifications, >>> fallback we can put the src out on our download servers and create a job for >>> it. As for x264, we will not be putting that in our repo, you'll have to find >>> some way to get that into some official repo that we can reference, maybe see >>> if you can get it into epel? The best case would be to get as much as possible >>> directly into epel so it leaves us having to manage as little as possible. >>> >>> On Thursday, June 25, 2015, Matteo < mbrancaleoni(a)voismart.it > wrote: >>> >>> >>> >>> I know how specs works, I'm maintaining a private repo like epel with tens of >>> packages since years, using the same tools used by fedora ( koji, mock, mash). >>> >>> My intent is not to create a custom build of freeswitch, but a repo like epel or >>> rpmfusion with only the needed build deps. >>> >>> What is not clear to me is the flow to add a new dep. >>> >>> Let's say I need to add a bunch of new libs, like gpac, nasm, x264, to name a >>> few. >>> >>> Which is the correct approach to fit into Fs build structure? >>> >>> Mat >>> >>> Inviato da iPhone >>> >>>> Il giorno 25/giu/2015, alle ore 18:08, Ken Rice ha scritto: >>>> >>>> You know in the spec files you can if things for specific versions... You'll >>>> just have to figure out the correct Ifs for Cent7 vs Cent6 vs say Suse >>>> >>>> >>>>> On 6/25/15, 11:03 AM, "Matteo" wrote: >>>>> >>>>> Ok, >>>>> >>>>> since some packages are only centos 6 specific updates, how do you plan to >>>>> handle them? >>>>> >>>>> For example, nasm is a required update to CentOS 6 in order to build other >>>>> stuff, >>>>> but is not needed for debian or CentOS 7 >>>>> >>>>> Right now in the repo I don't see anything distro-specific . >>>>> >>>>> >>>>> Regards, >>>>> Matteo >>>>> >>>>> _________________________________________________________________________ >>>>> Professional FreeSWITCH Consulting Services: >>>>> consulting(a)freeswitch.org >>>>> http://www.freeswitchsolutions.com >>>>> >>>>> Official FreeSWITCH Sites >>>>> http://www.freeswitch.org >>>>> http://wiki.freeswitch.org >>>>> http://www.cluecon.com >>>>> >>>>> 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 >>>> >>>> -- >>>> Ken >>>> http://www.FreeSWITCH.org >>>> http://www.ClueCon.com >>>> http://www.OSTAG.org >>>> irc.freenode.net #freeswitch >>>> Twitter: @FreeSWITCH >>>> >>>> >>>> >>>> >>>> _________________________________________________________________________ >>>> Professional FreeSWITCH Consulting Services: >>>> consulting(a)freeswitch.org >>>> http://www.freeswitchsolutions.com >>>> >>>> Official FreeSWITCH Sites >>>> http://www.freeswitch.org >>>> http://wiki.freeswitch.org >>>> http://www.cluecon.com >>>> >>>> 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 >>> >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> 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 >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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 _______________________________________________ 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

1 0

Re: [Freeswitch-dev] [Freeswitch-users] FreeSWITCH Friday FreeForAll Reminder!
by Michael Jerris 10 Jul '15

10 Jul '15

> On Jul 10, 2015, at 2:38 PM, jungle Boogie <jungleboogie0(a)gmail.com> wrote: > > On 10 July 2015 at 10:34, Brian West <brian(a)freeswitch.org> wrote: >> >> Stop by anyone wishing to help on Tuesdays call, I want to get an outline prepared for testing / automation call. >> >> https://docs.google.com/document/d/1C460sc0SkKvrKrqOXcnmO0NAVhzjoUDdUR7KL9P… >> >> I've started to jot down some things please join me. >> >> /b > > > Looks like this is read/view only. > > Does freeswitch use some kind of automated build process like jenkins > to test builds? > > The freebsd group uses jenkins: https://jenkins.freebsd.org/ > > If a build fails, an email is sent out to the list with a link to the > log so it can be corrected, and then another email reporting the build > is back to normal. > > We use a product from Atlassian called bamboo. Our instance is at https://freeswitch.org/bamboo . This is the automated system we use to build all of our packages and tarballs currently and will be the system we use to run any automated tests (as well as being able to run them manually). Mike

1 0

FreeSWITCH Friday FreeForAll Reminder!
by Ken Rice 10 Jul '15

10 Jul '15

FreeSWITCHers, Do not forget to join us at 2PM CST for the FreeSWITCH Friday FreeFor All Visit http://ift.tt/1n3h0Pf and Click Call 888 with your WebRTC enabled Browser and headset, Call sip:888@conference.freeswitch.org or see http://ift.tt/1prwIZL for access info! -- Ken FreeSWITCH.org ClueCon.com OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH @ClueCon

2 1

sofia_reg_handle_register_token - exp possibly always false
by Podrigal, Aron 07 Jul '15

07 Jul '15

Hi, According to grep the function sofia_reg_handle_register_token is called from a single place src/mod/endpoints/mod_sofia/sofia_reg.c:2305 <https://freeswitch.org/stash/projects/FS/repos/freeswitch/browse/src/mod/en…> where the argument *v_event* would always be NULL at that time. So I'm wondering what the line at src/mod/endpoints/mod_sofia/sofia_reg.c:1297 <https://freeswitch.org/stash/projects/FS/repos/freeswitch/browse/src/mod/en…> if (v_event && *v_event) pres_on_reg = switch_event_get_header(*v_event, "send-presence-on-register"); is suppose to do, won't this always evaluate to false? -- Aron Podrigal - //Be happy :-)

1 0

mod_shout and mod_sndfile are not loaded
by S.Mohammad Emami Razavi 05 Jul '15

05 Jul '15

I‌ have problem with loading this two important modules in version FreeSWITCH Version 1.7.0+git~20150626T195140Z~2a1195e55d~64bit I have installed them: [root@voip freeswitch]# make mod_sndfile-install make[1]: Entering directory `/usr/local/src/freeswitch' /usr/bin/mkdir -p '/usr/local/freeswitch/lib' /bin/sh /usr/local/src/freeswitch/libtool --mode=install /usr/bin/install -c libfreeswitch.la '/usr/local/freeswitch/lib' libtool: install: /usr/bin/install -c .libs/libfreeswitch.so.1.0.0 /usr/local/freeswitch/lib/libfreeswitch.so.1.0.0 libtool: install: (cd /usr/local/freeswitch/lib && { ln -s -f libfreeswitch.so.1.0.0 libfreeswitch.so.1 || { rm -f libfreeswitch.so.1 && ln -s libfreeswitch.so.1.0.0 libfreeswitch.so.1; }; }) libtool: install: (cd /usr/local/freeswitch/lib && { ln -s -f libfreeswitch.so.1.0.0 libfreeswitch.so || { rm -f libfreeswitch.so && ln -s libfreeswitch.so.1.0.0 libfreeswitch.so; }; }) libtool: install: /usr/bin/install -c .libs/libfreeswitch.lai /usr/local/freeswitch/lib/libfreeswitch.la libtool: install: /usr/bin/install -c .libs/libfreeswitch.a /usr/local/freeswitch/lib/libfreeswitch.a libtool: install: chmod 644 /usr/local/freeswitch/lib/libfreeswitch.a libtool: install: ranlib /usr/local/freeswitch/lib/libfreeswitch.a libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/sbin" ldconfig -n /usr/local/freeswitch/lib ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/freeswitch/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- make[1]: Leaving directory `/usr/local/src/freeswitch' make[1]: Entering directory `/usr/local/src/freeswitch/src/mod' making install mod_sndfile make[2]: Entering directory `/usr/local/src/freeswitch/src/mod/formats/mod_sndfile' make[2]: Leaving directory `/usr/local/src/freeswitch/src/mod/formats/mod_sndfile' make[1]: Leaving directory `/usr/local/src/freeswitch/src/mod' and i configure: [root@voip freeswitch]# vim /usr/local/freeswitch/conf/autoload_configs/modules.conf.xml and i have uncommented <load module="mod_sndfile"/> but in fs_cli when i call module_exists it prints false or calling load mod_sndfile results: freeswitch@internal> load mod_sndfile +OK Reloading XML -ERR [module load file routine returned an error] 2015-07-05 17:30:11.737311 [INFO] mod_enum.c:880 ENUM Reloaded 2015-07-05 17:30:11.737311 [CRIT] switch_loadable_module.c:1520 Error Loading module /usr/local/freeswitch/mod/mod_sndfile.so **/usr/local/freeswitch/mod/mod_sndfile.so: undefined symbol: sf_writef_int** 2015-07-05 17:30:11.737311 [INFO] switch_time.c:1411 Timezone reloaded 1781 definitions freeswitch@internal> My OS is CentOS Linux release 7.1.1503 (Core) Any idea?

3 2