In anticipation of this transition to hangouts, We have added WebRTC support to FreeSWITCH, our Open Source Telephony and Voice application framework. We have had support for Jingle for many years allowing communication with google voice and I suspect we will be able to use our new WebRTC functionality to connect Google hangouts to any voice applications you can make using FreeSWITCH http://www.freeswitch.org/
We are featuring WebRTC applications in August at our ClueCon conference http://www.cluecon.com/
I'd be surprised if they were really completely dropping it. It probably has more to do with rush to market on latest features than some attempt to slam doors on people's feet. XMPP for voice really is not all that great, I've implemented it myself.
We've supported Googleifyed xmpp jingle in FreeSWITCH [http://www.freeeswitch.org] since 2006. Its never really looked like something that would scale since the signaling protocol was over an already high level transport designed for chat. XMPP offers one really good feature, you can reach users directly using a user@domain.com style address and there is no NAT or any other networking or lookup issues to reach that user. The downside is it won't scale due to the fact that xmpp servers are heavily rate limited and not designed at all for tons of messaging at heavy rates. So Google luckily had the best super cluster of xmpp services in town and that allowed them to build on that for the voice stuff but I bet it became clear to them quickly the challenges with trying to exponentially keep up.
I would gather more info and look for the whole story before passing judgement. If they have some goal to use some fancy new audio and video services, there is a chance they can focus on that first and make sure it scales and it should be trivial to gateway that back to xmpp for existing topology.
Coming from a telephony background, I am more concerned with the tunnel vision towards paradigm shift at any cost that threatens people who still use telephones from being disenfranchised by this attempt to reinvent communication too drastically too quickly. Balance is key when it comes to legacy vs new wave in communication technology.
I have been working on the open source softswitch FreeSWITCH http://www.freeswitch.org/ for almost 6 years now. During that time I have seen SIP continuously evolve to try to cover its own shortcomings which all stemmed from the simple concept of "If we base it on HTTP, we can use proxys and never have to worry about media" Of course this is not true and the amount of complexity that is put into each SIP device is much too great which is probably why Cisco prefers its own lighter "skinny" protocol. Sadly they own Sipura and Linksys and have SIP on their devices using countless hacks that make interop a nightmare. I am sure you can do many of these same attacks on any brand of phone. There are much better reasons out there to curse Cisco for being involved in VoIP. =D
We work on an open source softswitch called FreeSWITCH http://www.freeswitch.org/ Blocked ports and content filtering can mess up Voice over IP traffic running on your broadband line which can be used as a free alternative to the "Digital Phone" services many providers offer. Some entire countries already do this type of thing like China for instance. There are ways around it using secure packets so the payload cannot be sniffed and other workarounds but it would be a huge pain if we had to do that inside the US.
We have an Open Source project called FreeSWITCH http://www.freeswitch.org/ that allows you to do this sort of thing with any computer running Windows MAC or most UNIX. It can be paired with traditional phones with a small analog adapter or a hardware telephony card from Sangoma http://www.sangoma.com./ But you could just get a software phone for free as well and play around with it.
When you create closed source code you have a much higher chance of flaws because your code can not tested nearly as much as open source can. As the leader of an open source project, FreeSWITCH http://www.freeswitch.org/ , I am fortunate to have a very large crowd of beta testers who help ensure our releases are as stable as they can be. If you are selling the application and never letting anyone see the source you run a very high risk of missing something in Q/A and releasing buggy software. When people pay for it the will get angry so I am not surprised such a suggestion is being made but I find it unpractical to enforce since if it "works right" is hard to judge in some cases besides maybe medical equipment or other situation where human lives are at stake. Blue screens of death are hardly an excuse to sue anyone.
Our project (FreeSWITCH) uses the MPL for the main application and BSD for satellite libraries that we create that can be used by other projects etc.
Once you decide to have open source code, it's more logical to stick with the fact that at least the core code is FREE and come up with ways to develop a product on top of it if you want to have something to sell. Otherwise it sounds like an "open source tax" and businesses do not like uncertainty. If they choose to use a code base they need to know it will always be available.
Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)
I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.
2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."
Yep, like i said, it's a shame, The idea is that we would use it in our project which is a telephony server that runs much better on 64bit, that's really the only show stopper from our being able to try it instead of the spidermonkey library we use now.
since it's open source, you can add 64-bit yourself. That's the whole point of open source.
The whole point of open source is for projects to work together and combine their efforts to make better software. As I said I am the author of an open source software. It has over 300,000 lines of code of it's own then a large list of dependency libs that added up account for about 2.5 million lines of code see: http://fisheye.freeswitch.org/browse/FreeSWITCH A library developer makes a library for other people to use. Adding 64 bit support to someone else's library is an exercise best left to the lead developer since it's his decision to support it or not.
I was looking at using v8 in our open source soft-switch/pbx/telephony application server FreeSWITCH http://www.freeswitch.org/
We currently are using spidermonkey from Mozilla and it has it's ups and downs in the scalability department since it was not designed for thousands of concurrent sessions in a single process. The documentation for v8 was impressive but sadly, 64 bit is not supported. It would be nice to get 64 bit supported so we could experiment further with it because it looks really well written.
Several years ago I wrote a javascript module for Asterisk open source PBX More recently I added it for my own project FreeSWITCH ( http://www.freeswitch.org/ )
We actually also support LUA, Python, Perl, JAVA and MONO as ways to script telephony apps.
It's quickly becoming a great new way to prototype and deploy audio driven apps for your phone system.
This is one of the main reasons I decided to stick with a threaded model for concurrency in FreeSWITCH. There are many alternatives cropping up to obtain concurrency in your applications but if you stick to a threading model you will gain the benefits of more cores on faster CPUs and better schedulers in the kernels. The number of concurrent instructions are going up much faster than the actual speed of a single CPU these days.
It's bad enough that a 2 million line program written from scratch would suddenly be infected by the GPL by including a 1 line file, but now we are supposed to propagate the virus with our web servers? I am perfectly happy to allow the GPL and its descendants to exist but I am reluctant see its roots dig deeper into the minds of ill-informed developers who do not realize the only goal of this license is to see how far it can spread. Before anyone tries to flame me be aware I am simply expressing my opinion, if you disagree, disagree with objectivity. I myself am an open source developer and I practice what I preach http://www.freeswitch.org/ I release my code under the MPL and BSD licenses which are actually much more liberal licenses than GPL but all the propaganda would have you believe otherwise. If you are going to write free code and give it away, then stop worrying about how other people are going to use it. When someone takes your code and makes a service out of it, don't you think they put any of their own work into it building an infrastructure etc?
I used to do quite a bit of stuff with Asterisk and I happen to run 7 production machines across a DS3 circuit each responsible for up to 4 T1 worth of traffic (92 calls in our current configuration of PRI with 1 DCHAN per span) I am somewhat skeptical about what the boxes would do if they really ran all 92 channels at once It think we have never had more than 2 of the T1's full on a given machine so it's a good thing we load balance them.
I decided I was not happy with this situation so I began work early this year on my own open source soft switch called FreeSWITCH http://www.freeswitch.org/
You may have a point, we should stick to ITU codecs
like perhaps, g722
http://www.umiacs.umd.edu/~desin/Speech1/node3.htm l
Oh waddya know! its a wideband codec! yay does that mean we can use it now????
Not exactly pointless, You can do conferencing, ivr, voicemail and media proxy calls from a SIP phone all at 16khz
Mostly only client applications have been able to operate at this rate. Now we actually have a switching platform
that will allow people to interact with the calls. The goal is not to make the pstn 16khz it's to make devices that are better than legacy phones able to do all of the same things *without* the PSTN.
Please send us your name and email address and we will send you instructions on how to download our unquestionably open source code without having to provide any information.
Well sure,
VoIP is digital audio over the internet. It contains all of the same properties as any digital audio.
It can vary from CD quality down to unintelligable static.
The more quality, the easier it is to perform detection algorithms for things like speech recognition, and yes you can notice the difference as long as the audio was generated digitally by a microphone+soundcard or with something like cepstral that defaults to 16khz for a reason.
FYI:
20ms of 16khz audio (the typical size of 1 RTP packet)
encoded with the Speex Codec http://www.speex.org/ is 43 bytes.
20ms of 8khz audio encoded with the Speex Codec http://www.speex.org/ is 29 bytes which is only 1.4 times as big as it's 8khz counterpart.
20ms of 8khz g711 is 160 bytes so with speex at 16khz, you can still fit 3 calls in the same amount of bandwidth that it takes for one 8khz call.
The biggest overhead in VoIP is the various headers on each RTP packet per level of encapsulation, not the size of the payload.
Yes, you are correct. The benefit comes when both ends of the call are using a 16khz device. Situations where you are connecting to the PSTN would obviously be better suited at 8khz. The media description on the pstn gateway would advertise only 8k so the client would know better than to operate at a higher frequency.
As pointed out by someone else there are not very many details to go on in this article but I would venture to say the author's use of the term "Software vendors" implies he is talking about commercial distribution of software. That would suggest he wants companies who sell or license software to be responsible for it not necessarily the authors of the code.
If so, OSS contributors would not be risking anything unless they were also somehow licensing or selling the code for money. I run an open source project at http://www.freeswitch.org./ If someone turned my free code into a commercial product and started selling it, I would certianly want to see disgruntled customers suing *them* and not me =D
Slashdot Mirror
I guess nobody realized that hangouts is migrating to use WebRTC. If so my comment would not be moderated.
In anticipation of this transition to hangouts, We have added WebRTC support to FreeSWITCH, our Open Source Telephony and Voice application framework.
We have had support for Jingle for many years allowing communication with google voice and I suspect we will be able to use our new WebRTC functionality to connect Google hangouts to any voice applications you can make using FreeSWITCH http://www.freeswitch.org/
We are featuring WebRTC applications in August at our ClueCon conference http://www.cluecon.com/
I'd be surprised if they were really completely dropping it. It probably has more to do with rush to market on latest features than some attempt to slam doors on people's feet. XMPP for voice really is not all that great, I've implemented it myself.
We've supported Googleifyed xmpp jingle in FreeSWITCH [http://www.freeeswitch.org] since 2006. Its never really looked like something that would scale since the signaling protocol was over an already high level transport designed for chat. XMPP offers one really good feature, you can reach users directly using a user@domain.com style address and there is no NAT or any other networking or lookup issues to reach that user. The downside is it won't scale due to the fact that xmpp servers are heavily rate limited and not designed at all for tons of messaging at heavy rates. So Google luckily had the best super cluster of xmpp services in town and that allowed them to build on that for the voice stuff but I bet it became clear to them quickly the challenges with trying to exponentially keep up.
I would gather more info and look for the whole story before passing judgement. If they have some goal to use some fancy new audio and video services, there is a chance they can focus on that first and make sure it scales and it should be trivial to gateway that back to xmpp for existing topology.
Coming from a telephony background, I am more concerned with the tunnel vision towards paradigm shift at any cost that threatens people who still use telephones from being disenfranchised by this attempt to reinvent communication too drastically too quickly. Balance is key when it comes to legacy vs new wave in communication technology.
I have been working on the open source softswitch FreeSWITCH http://www.freeswitch.org/ for almost 6 years now.
During that time I have seen SIP continuously evolve to try to cover its own shortcomings which all stemmed from the simple concept of "If we base it on HTTP, we can use proxys and never have to worry about media" Of course this is not true and the amount of complexity that is put into each SIP device is much too great which is probably why Cisco prefers its own lighter "skinny" protocol. Sadly they own Sipura and Linksys and have SIP on their devices using countless hacks that make interop a nightmare. I am sure you can do many of these same attacks on any brand of phone. There are much better reasons out there to curse Cisco for being involved in VoIP. =D
We work on an open source softswitch called FreeSWITCH http://www.freeswitch.org/
Blocked ports and content filtering can mess up Voice over IP traffic running on your broadband line which can be used as a free alternative to the "Digital Phone" services many providers offer. Some entire countries already do this type of thing like China for instance. There are ways around it using secure packets so the payload cannot be sniffed and other workarounds but it would be a huge pain if we had to do that inside the US.
We have an Open Source project called FreeSWITCH http://www.freeswitch.org/ that allows you to do this sort of thing with any computer running Windows MAC or most UNIX. It can be paired with traditional phones with a small analog adapter or a hardware telephony card from Sangoma http://www.sangoma.com./ But you could just get a software phone for free as well and play around with it.
When you create closed source code you have a much higher chance of flaws because your code can not tested nearly as much as open source can. As the leader of an open source project, FreeSWITCH http://www.freeswitch.org/ , I am fortunate to have a very large crowd of beta testers who help ensure our releases are as stable as they can be. If you are selling the application and never letting anyone see the source you run a very high risk of missing something in Q/A and releasing buggy software. When people pay for it the will get angry so I am not surprised such a suggestion is being made but I find it unpractical to enforce since if it "works right" is hard to judge in some cases besides maybe medical equipment or other situation where human lives are at stake. Blue screens of death are hardly an excuse to sue anyone.
Our project (FreeSWITCH) uses the MPL for the main application and BSD for satellite libraries that we create that can be used by other projects etc.
Once you decide to have open source code, it's more logical to stick with the fact that at least the core code is FREE and come up with ways to develop a product on top of it if you want to have something to sell. Otherwise it sounds like an "open source tax" and businesses do not like uncertainty. If they choose to use a code base they need to know it will always be available.
Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)
I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.
1) Chrome does not support 64 bit builds
2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."
Yep, like i said, it's a shame, The idea is that we would use it in our project which is a telephony server that runs much better on 64bit, that's really the only show stopper from our being able to try it instead of the spidermonkey library we use now.
since it's open source, you can add 64-bit yourself. That's the whole point of open source.
The whole point of open source is for projects to work together and combine their efforts to make better software. As I said I am the author of an open source software. It has over 300,000 lines of code of it's own then a large list of dependency libs that added up account for about 2.5 million lines of code see: http://fisheye.freeswitch.org/browse/FreeSWITCH A library developer makes a library for other people to use. Adding 64 bit support to someone else's library is an exercise best left to the lead developer since it's his decision to support it or not.
I was looking at using v8 in our open source soft-switch/pbx/telephony application server FreeSWITCH http://www.freeswitch.org/
We currently are using spidermonkey from Mozilla and it has it's ups and downs in the scalability department since it was not designed for thousands of concurrent sessions in a single process. The documentation for v8 was impressive but sadly, 64 bit is not supported. It would be nice to get 64 bit supported so we could experiment further with it because it looks really well written.
Several years ago I wrote a javascript module for Asterisk open source PBX
More recently I added it for my own project FreeSWITCH ( http://www.freeswitch.org/ )
We actually also support LUA, Python, Perl, JAVA and MONO as ways to script telephony apps.
It's quickly becoming a great new way to prototype and deploy audio driven apps for your phone system.
This is one of the main reasons I decided to stick with a threaded model for concurrency in FreeSWITCH. There are many alternatives cropping up to obtain concurrency in your applications but if you stick to a threading model you will gain the benefits of more cores on faster CPUs and better schedulers in the kernels. The number of concurrent instructions are going up much faster than the actual speed of a single CPU these days.
It's bad enough that a 2 million line program written from scratch would suddenly be infected by the GPL by including a 1 line file, but now we are supposed to propagate the virus with our web servers? I am perfectly happy to allow the GPL and its descendants to exist but I am reluctant see its roots dig deeper into the minds of ill-informed developers who do not realize the only goal of this license is to see how far it can spread. Before anyone tries to flame me be aware I am simply expressing my opinion, if you disagree, disagree with objectivity. I myself am an open source developer and I practice what I preach http://www.freeswitch.org/ I release my code under the MPL and BSD licenses which are actually much more liberal licenses than GPL but all the propaganda would have you believe otherwise. If you are going to write free code and give it away, then stop worrying about how other people are going to use it. When someone takes your code and makes a service out of it, don't you think they put any of their own work into it building an infrastructure etc?
Don't hold your breath.
I used to do quite a bit of stuff with Asterisk and I happen to run 7 production machines across a DS3 circuit each responsible for up to 4 T1 worth of traffic (92 calls in our current configuration of PRI with 1 DCHAN per span) I am somewhat skeptical about what the boxes would do if they really ran all 92 channels at once It think we have never had more than 2 of the T1's full on a given machine so it's a good thing we load balance them.
I decided I was not happy with this situation so I began work early this year on my own open source soft switch called
FreeSWITCH http://www.freeswitch.org/
If you wish, you are welcome to operate at 44khz. We support any speed we just tested it with 16khz.
You may have a point, we should stick to ITU codecs like perhaps, g722 http://www.umiacs.umd.edu/~desin/Speech1/node3.htm l
Oh waddya know! its a wideband codec! yay does that mean we can use it now????
Not exactly pointless, You can do conferencing, ivr, voicemail and media proxy calls from a SIP phone all at 16khz
Mostly only client applications have been able to operate at this rate. Now we actually have a switching platform
that will allow people to interact with the calls. The goal is not to make the pstn 16khz it's to make devices that are better than legacy phones able to do all of the same things *without* the PSTN.
OMG, actually, we can actually operate at any sample rate we want! 16khz was just a logical test because the phone we tested it with supported it.
Dear entitlist,
Please send us your name and email address and we will
send you instructions on how to download our unquestionably
open source code without having to provide any information.
Well sure, VoIP is digital audio over the internet. It contains all of the same properties as any digital audio. It can vary from CD quality down to unintelligable static.
The more quality, the easier it is to perform detection algorithms for things like speech recognition, and yes you can notice the difference as long as the audio was generated digitally by a microphone+soundcard or with something like cepstral that defaults to 16khz for a reason.
FYI: 20ms of 16khz audio (the typical size of 1 RTP packet) encoded with the Speex Codec http://www.speex.org/ is 43 bytes. 20ms of 8khz audio encoded with the Speex Codec http://www.speex.org/ is 29 bytes which is only 1.4 times as big as it's 8khz counterpart. 20ms of 8khz g711 is 160 bytes so with speex at 16khz, you can still fit 3 calls in the same amount of bandwidth that it takes for one 8khz call. The biggest overhead in VoIP is the various headers on each RTP packet per level of encapsulation, not the size of the payload.
It's ok if you are not interested but there are some who are. Here is an article about some of the benefits. http://www.analogzone.com/nett0307.pdf as well as a wiki entry from http://www.voip-info.org./ http://www.voip-info.org/wiki/view/Wideband+VoIP
Yes, you are correct. The benefit comes when both ends of the call are using a 16khz device. Situations where you are connecting to the PSTN would obviously be better suited at 8khz. The media description on the pstn gateway would advertise only 8k so the client would know better than to operate at a higher frequency.
As pointed out by someone else there are not very many details to go on in this article but I would venture to say the author's use of the term "Software vendors" implies he is talking about commercial distribution of software. That would suggest he wants companies who sell or license software to be responsible for it not necessarily the authors of the code.
If so, OSS contributors would not be risking anything unless they were also somehow licensing or selling the code for money. I run an open source project at http://www.freeswitch.org./ If someone turned my free code into a commercial product and started selling it, I would certianly want to see disgruntled customers suing *them* and not me =D