It's one piece of the technology you need to run an VOIP phone service. You could use this, for example, as a building block to get push-to-touch voice livechats on your site.
There are 2 main VOIP protocols right now you can choose from. H323 and SIP. H323 was developed my the telecom industry and its a binary format so its more of a pain in the ass to develop form.
SIP looks like HTML where all the commands it uses, like to register, call, hangup, add someone to the conference, all are in ASCII and are human readable.
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
If you were looking at the data of a SIP REGISTER it would look just like that, whereas H323 would just be a bunch of crazy gibberish without the proper decoding.
What it gains in readability it looses through its typical consortium designed over engineered standard. Same old feature bloat. Just skip to the point where it discusses NAT.
video is actually available as is file sharing. this opens myriads of opportunities (or rather: now we can do with HTML5 what we could do with flash 2 years ago.)
Don't forget that web services are a great way around the gpl. Just slap a subscription fee on there and don't distribute the server-side code and you can do whatever you want with it and/or charge whatever you want for it without being in violation or giving a competitor a chance to copy you. worked for Google.
gpl client-side code of course you cannot protect in this way (except your trademarks).
this is an important distinction. Everything on the web is copyrighted and you can't just go and grab images/html/css/javascript without permission from the copyright holder.
And view source isn't going to show you much when looking at sites like Gmail where the code is generated by a compiler that makes it as obtuse and unreadable as machinely possible.
GPL requires that users have access to the preferred form for modifying the work. If you're using coffeescript or a state machine graph or whatever, the generated javascript is more like object code than maintainable source.
There was a draft of GPLv3 that included such a clause. This was dropped with the development of Affero GPL license. The final version of GPLv3 dropped all language regarding web services. If you want to use a GPL-like license for a web application, then the AGPL is the license to use.
Any open source software (gpl3, gpl2, bsd licence, mit licence etc etc) cannot be distributed in a commercial or noncommercial manner without also providing the source code. (there are some other requirements aswell as this, notably with GPL that your software must be GPL licensed aswell.).
There is nothing special in any open source/free software licence about commercial vs noncommercial use. All OS/FS treat commercial and noncommercial the same.
As for requiring source code distribution, the GPL 3 is essentially the same as the GPL2 (which is ~20 years old), you have to do it under gpl2 and you have to do it under gpl3.
False.
The whole point of the bsd license is that you are not required to make source available, but that if you do that you need to preserve the bsd notices about the copyright of the orIginal code. I'm over simplifying slightly but gpl is the one with the mandatory code resharing. MIT and bsd do not have that
The MIT and BSD licenses do allow distribution inside of commercial software without providing source code. The only real restrictions are that the MIT license requires you to include their copyright notice somewhere and the BSD license is similar.
I believe the ZLIB license also permits commercial distribution.
Off the top of my head it's only the GPL licenses that require source distribution no matter what.
What? No. You can distribute binaries you compiled from open source code that is licensed under the MIT or BSD licenses, in both commercial and noncommercial contexts. Read the license text, they only require you to include the license with your distribution. Not the source code or any of your modifications.
I might be a bit wrong here, esp. with BSD. :P Mea cupla.
I know that BSD, unlike GPL, does not require that derived code be BSD licenced. And when I was talking about "source code" I was thinking of the original code (not the derived work), but I was wrong about BSD not requiring that you provide the source. Many big users of BSD code (e.g. Apple) provide the BSD source code they use, so I thought it was required.
However, for GPL, "commerical" vs. "noncommercial" is irrelevant.
The code should be made available. It doesn't actually have to be distributed with or "attached to" the product. The option to post the download link elsewhere or available on CD for media cost only.
What amuses me is that most of the replies are "How to bypass the GPL so I won't have to give away the source"
Then we have threads against the GPL in other posts and how BSD is great because its morefree and that has nothing to do with "being able to keep the modified source".
Well if the author decided to make it GPL one should respect the choice of the author, on top of not being unethical capitalists.
Anyway this thing relies on javascript too, which I thought was a stretch to call 'pure html5'...so depending on your needs, Flash (which can use mic input) might be just as acceptable as javascript...then again, it might not be.
If you count all of the new javascript APIs as part of HTML5, which most people do, then it is true that you can capture mic input with webRTC which is part of "HTML5".
That syntax came from MIME and has been present in email, newsgroups and the web for as long as I can remember. The server sends content-type headers delimited with MIME attributes, the browser sends accept headers and inside the pages one will often find a meta tag with its content attribute delimited that way.
This itself does not provide the mic-capturing technology. That is provided by WebRTC, which this is built upon, and is quickly being implemented by all browser vendors except Apple and Microsoft.
Yes, with the webmedia audio object (maybe present in chrome 20). A dialog bar will appear asking the user if they want to allow access from javascript for their audio (and video) devices. There's some good examples on google+ search for webRTC channel
This is what I did on my dev Chrome to enable WebRTC:
- Type "about:flags" on the address bar and press enter
- Enable the "Enable MediaStream" option
- Click on the "Relaunch now" button at the bottom of the screen
FaceTime on the web is the new black. I been following closely webRTC and this is it. Ride the wave, it'll be pervasive, some will even make money with it. Face to face customer service? Video conferencing? Doctors appointments? Livecasting? Sports? Events?
Downside is, if everybody starts live-casting an apple event, the web will go down in flames.
Ok, but it's just the same things that we could do for some years with Flash. What will change? Before was Flash, now is HTML5? So, what? Just technology? Many users does not notice even what technology you are using
Doesn't Flash webcam video or streaming require proprietery Flash streaming servers that are quite costly? Not to mention probably no longer (actively) supported.
It's doing the same thing, but in a very different way. Flash video uses ancient, terrible codes; requires proprietary Adobe servers (although there's been some good work on this from Wowza, Red5, et al); doesn't use open protocols like SIP.
What will change? Maybe nothing, but it's definitely interesting work. One could, for instance, use this as the endpoint of a SIP PBX without serious effort, which is not the case for a Flash endpoint.
More like non-standardized parts which currently are working drafts only.
But seeing how just saying "this is standard HTML, really!" again and again and again worked for the What WG, I guess there is nothing wrong in browser-vendors attempting to do the same to get their proprietary extensions embedded into the standard as well. At least it's not much worse.
Idea: Don't use ICE for NAT traversal (it will not always work). Don't use a third party SIP server. Traverse the NAT by having your own reachable IP address running a supernode. Run your own _private_ SIP server, e.g., for just your friends and family.
Having all this stuff running in a browser is neat. But just remember that one company may end up with monopolistic control over the browser.
All this stuff can run just as well outside the browser.
Idea: Do not use ICE for NAT traversal (it will not always work). Do not use a public SIP server controlled by a third party (ever heard of spam?). Traverse NAT by getting a reachable IP address and running a supernode on it. Run your own _private_ SIP server (e.g. for just friends and family).
It's neat that this can all be made to run in the browser. But keep in mind that one company may end up with monopolistic control over the browser. It's certainly looking like this could happen. Again.
All this stuff runs just fine outside the browser. Supernode and SIP server can run as daemons.
60 comments
[ 2.8 ms ] story [ 112 ms ] threadThere are 2 main VOIP protocols right now you can choose from. H323 and SIP. H323 was developed my the telecom industry and its a binary format so its more of a pain in the ass to develop form.
SIP looks like HTML where all the commands it uses, like to register, call, hangup, add someone to the conference, all are in ASCII and are human readable.
Heres an example of a SIP packet:
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
If you were looking at the data of a SIP REGISTER it would look just like that, whereas H323 would just be a bunch of crazy gibberish without the proper decoding.
I think you mean HTTP.
gpl client-side code of course you cannot protect in this way (except your trademarks).
And view source isn't going to show you much when looking at sites like Gmail where the code is generated by a compiler that makes it as obtuse and unreadable as machinely possible.
There is nothing special in any open source/free software licence about commercial vs noncommercial use. All OS/FS treat commercial and noncommercial the same.
As for requiring source code distribution, the GPL 3 is essentially the same as the GPL2 (which is ~20 years old), you have to do it under gpl2 and you have to do it under gpl3.
I believe the ZLIB license also permits commercial distribution.
Off the top of my head it's only the GPL licenses that require source distribution no matter what.
I know that BSD, unlike GPL, does not require that derived code be BSD licenced. And when I was talking about "source code" I was thinking of the original code (not the derived work), but I was wrong about BSD not requiring that you provide the source. Many big users of BSD code (e.g. Apple) provide the BSD source code they use, so I thought it was required.
However, for GPL, "commerical" vs. "noncommercial" is irrelevant.
Then we have threads against the GPL in other posts and how BSD is great because its more free and that has nothing to do with "being able to keep the modified source".
Well if the author decided to make it GPL one should respect the choice of the author, on top of not being unethical capitalists.
[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-n...
HTML5 Media Capture[1] provides extensions to input tags to allow access to camera and microphone devices, eg:
<input type="file" accept="video/* ;capture=camcorder">
<input type="file" accept="audio/* ;capture=microphone">
It isn't widely implemented though (just in the Android Browser, Chrome on Android and Firefox Mobile).
The recommended way is to use the getUserMedia Javascript APIs. http://www.html5rocks.com/en/tutorials/getusermedia/intro/ is a good guide.
[1] http://dev.w3.org/2009/dap/camera/
Great to see that the future is being ushered in in a coordinated, organized, well-thought-out manner. Ugh.
Chrome also has it, behind a flag.
(the parent comment originally asked when browsers would support getUserMedia)
I couldn't make it work on my normal Chrome even after setting the MediaStream stream flag, but it worked on the Canary build.
However, it still doesn't work, my mouse pointer keeps being a spinning wheel, and the login button seems disabled. However, it's a great idea!
Downside is, if everybody starts live-casting an apple event, the web will go down in flames.
What will change? Maybe nothing, but it's definitely interesting work. One could, for instance, use this as the endpoint of a SIP PBX without serious effort, which is not the case for a Flash endpoint.
More like non-standardized parts which currently are working drafts only.
But seeing how just saying "this is standard HTML, really!" again and again and again worked for the What WG, I guess there is nothing wrong in browser-vendors attempting to do the same to get their proprietary extensions embedded into the standard as well. At least it's not much worse.
All is good in browser-wars and love, etc.
http://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2...
Having all this stuff running in a browser is neat. But just remember that one company may end up with monopolistic control over the browser.
All this stuff can run just as well outside the browser.
It's neat that this can all be made to run in the browser. But keep in mind that one company may end up with monopolistic control over the browser. It's certainly looking like this could happen. Again.
All this stuff runs just fine outside the browser. Supernode and SIP server can run as daemons.