The world's first HTML5 SIP client | Hacker News Reader

The world's first HTML5 SIP client

code.google.com

217 pointsvamsee58 comments

Wow, they've built ragel state machines for the entire SIP protocol. Bravo guys.

http://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2...

This is amazing! I've been regularly using sipdroid on my phone, but hadn't been able to find any working solution for my desktop.

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!

I am not expert, but GPL v3 terms means that I can't use it in commercial product if I do not attach all my source code? Am I right?

yes that is correct

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).

But this is JavaScript to be run on top of WebRTC, which is a client-side API. So won't your code by definition be client-side if you use this?

But then again isn't all client-side JavaScript open source?

No, you can see the source, but thats not the same as "open source".

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.

Exactly. Think of it like a book. You can see the source code of a book (i.e. the individual letters), but you cannot copy it (without permission)

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.

GPLv3 (the license used here) applies for web services as well AFAIK and imposes the same requirements for distribution.

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.

Interesting. I was not aware that this was contained in the draft and then removed. Tnx for clarification.

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 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.

Looks cool, but... what is SIP?

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.

So, is this technology built in to the browser or should we look out for a client or something?

This is likely to be built into web pages

http://en.wikipedia.org/wiki/Session_Initiation_Protocol

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.

Heres an example of a SIP packet:

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.

> SIP looks like HTML

I think you mean HTTP.

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.

You can also jabber for the session initiation, but don't, it's slow.

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.

ICE will always work if you use a TURN server to act as a media relay in case none of the other candidates succeed.

Can somebody enlighten me please. Would this allow me to capture & process mic input client side?

There's no way to capture mic input with HTML5 now.

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.

JavaScript is definitely included when people talk about HTML5

HTML5 implies JS.

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's what getUserMedia[1] provides

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-n...

That's not true. Create a PeerConnection and feed it a getUserMedia stream object.

Actually...

HTML5 Media Capture[1] provides extensions to input tags to allow access to camera and microphone devices, eg:

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/

semicolon-delimited attr value, and "camcorder"!

Great to see that the future is being ushered in in a coordinated, organized, well-thought-out manner. Ugh.

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

I would like to try the client using FreeSwitch/mod_iSAC as the webrtc gateway.

I can't even imagine the abuse this is ripe for. Think chat roulette, but without the video.

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.)

How do I get it to work with Chrome 19? (the demo. it says not WebRTC support)

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.

FaceTime? You mean that proprietary protocol that Apple uses only for their own products? And what does that have to do with WebRTC?

Commercialized and "polished" the whole video-conference field.

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.

What will change? Before was Flash, now is HTML5?

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.

Reply on news.ycombinator.com