Subscribe to RSS
Archive for the ‘protocols’ Category:
Russian engineer claims to have reverse engineered older version of Skype
Via Dan York, we find a post on http://skype-open-source.blogspot.com/:
Skype protocol reverse engineered, source available for download
UPDATE: Here’s the Github page for it:
https://github.com/skypeopensource/skypeopensource/downloads
Closing of Gizmo5 / SIPphone, a sad day for open-standards VoIP
Gizmo5 (formerly known as Gizmo Project and SIPphone) will be shut down by Google April 3, 2011, according to the website. Google acquired Gizmo5 in November 2009, reportedly for around $30 million.
With the passing of Gizmo5, so goes one of the last and largest open-standards based VoIP services. Gizmo5 supported the interoperable SIP Internet standard protocol. That meant it worked with any SIP hardware, software, PBX, etc. Most VoIP services, especially the consumer-focused ones, including Google Voice, do not support standards, and instead require proprietary, closed, hardware or software.
As can be seen below, from a snapshot of the SIPphone.com site in 2004, the company started off being an advocate for SIP and open-standards, with an emphasis on free SIP to SIP calls, using any compliant device or software that you want.
Gizmo5 could be used with off-the-shelf hardware devices, ATAs, SIP phones, Wi-fi phones, and standard software on smartphones and PCs. Google Voice can’t.
In fact, back in 2008, Michael Robertson (CEO of Gizmo) wrote a long open-letter on the subject: Gizmo Project’s Michael Robertson Sounds Off explaining about how Skype was closed (it still is) and why being interoperable was a good thing for competition, etc. You could pretty much take that letter today, and replace “Skype” as the target with “Google Voice” – for instance:
If Skype truly believes there should be open competition then they should start by enabling other networks such as Gizmo5 to call Skype users in an official and supported capacity.
Reads just as well as:
If [Google Voice] truly believes there should be open competition then they should start by enabling other networks such as [Insert Third-party-Provider Here] to call [Google Voice] users in an official and supported capacity.
I guess it was convenient for Gizmo’s business objectives to “wave the flag of openness” back then, but it apparently isn’t so for Google and Google Voice now, who conveniently ignore competitors, as well their own customers’ requests for openness and interoperability.
It sucks. The suits won. I expected better from Google.
Maybe I’ll have more to say on this when I have more time.
Hands on with SipToSis SIP / Skype gateway
I’ve known about SipToSis for quite a while but I’ve never worked up the energy to experiment with it. I finally thought it was about time to do so.
When I first considered all the moving pieces to getting it working, I gave myself about a 25% chance of success. To make it even more challenging, I decided to try to set it up on an Ubuntu Linux VM running under VirtualBox on Mac OS X.
Well, to my pleasant surprise, the whole thing went swimmingly well. I followed the excellent SipToSis Linux Tips documentation on the SipToSis site and it all went smoothly. The first trick is to find a static version 2.1.0.81 download of Skype for Linux – to ensure compatibility with SipToSis. (I can’t put a link here because it moves around and I don’t think anyone is allowed to host it officially – you have to get Skype from Skype’s own website.)
Once the proper version of Skype is installed, it’s just a matter of setting it up to use the snd-dummy fake sound drivers and getting SipToSis installed and configured.
The Skype wire protocol is not open nor documented, so one cannot simply connect to Skype directly via the network from a third-party program. Third party apps can, however, interact with the running Skype (binary) process on the same machine via an inter-process communications API. So to use SipToSis, you first start the normal Skype application on the machine and then start the SipToSis application (on the same machine) – SipToSis then connects to the Skype application via the inter-process communications API (on the same machine) to manage calls on the Skype side via the Skype App, while speaking the open-standard SIP protocol on the other side directly.
In this basic configuration, there is one instance of Skype running, with one Skype username, which means it’s basically a one-channel gateway, one call at time. The call flow for a call from SIP to a Skype user looks like this:
SipToSis - SIP to Skype Call Flow
Note that SipToSis and Skype (representing the running Skype App) are shown inside one box because they are on the same machine, not connected over the network. The arrows inside that box, between SipToSis and the Skype App, represents Skype API inter-process communication – not network traffic. The other arrows in the diagram, the arrows between boxes, represent network traffic flows,where those elements could be on the same machine, or on a separate machine across the room or miles way. The Skype user SkypeUser will see an inbound call from the user that was used to sign in with the Skype instance that SipToSis is attached to. All calls will appear to originate from the same Skype user in this simple single-channel setup.
The SipToSis app talks SIP protocol directly on one side and uses the Skype App on the other side as a “black box” to speak the proprietary, undocumented, Skype protocol.
As shown above, I have SipToSis registering to a SIP proxy, where I can send calls from SIP to Skype via SipToSis – in this case, I have speed-dial codes that I dial from a plain handset that place Skype calls to specific Skype users, but depending on your SIP proxy/PBX capability (and your skills) you could setup click-dial or SIP uris, perhaps something like sip:skype-{username}@mypbx.com that ring through to the specified user on Skype.
Inbound calls from Skype work just the opposite of the diagram above, where SipToSis is configured to forward inbound calls arriving from Skype to a specified SIP address (if you’re connecting to Asterisk, that means an extension on the PBX).
As mentioned previously, my setup has just a single instance of Skype running and, therefore, provides only one Skype gateway channel, supporting just one Skype-to-SIP or SIP-to-Skype call at a time. The SipToSis website has documentation about running multiple SipToSis and multiple Skype instances and even chaining multiple Skype accounts so you can advertise a single Skype Userid and still take multiple incoming Skype calls. Based on my experience with SipToSis so far, I have no doubt this stuff actually works. However, it’s way more than I want to mess with – and Skype is a pretty heavy, resource intensive app – you would want to have a pretty beefy machine to run multiple instances of it. The SipToSis site has some information on performance on various hardware and OSes running multiple Skype users.
Overall, SipToSis is quite cool. Skype charges $6.95 per month per channel for a SIP PBX interface that only allows inbound calls (from Skype) and calls from the PBX to SkypeOut (paid calls) – it does not support calls from the SIP PBX to Skype users, as SipToSis does. Why Skype still doesn’t offer (preferably FREE) SIP support after all these years is just sad, but it’s nice to see third-parties like the SipToSis folks putting together practical solutions like this. The fact that it is cross-platform, and runs on Linux (and even under a VirtualBox VM), is very impressive and greatly improves the server-friendliness and cloud-based friendliness of SipToSis.
SipToSis is not quite for the mainstream, but it does work, and if one follows their excellent documentation, it’s not that hard to setup (assuming you already have the SIP side in place, or why would you want SipToSis in the first place). If you already have a machine available, why not run SipToSis rather than pay Skype $6.95 per month for the same thing (whether you use it or not) – plus, if you want to call Skype users from SIP, SipToSis will do that, where Skype’s own product won’t.
A few notes:
- Since you must have Skype running to use SipToSis, and Skype is a GUI app, you need X Windows setup on the machine where you want to use SipToSis. This was not a problem for my simple test case, but it could be an issue on a real server setup running in a data center. The SipToSis docs talk about running Xvfb in the “background” but I didn’t test that trick.
- I had to remove the pulseaudio drivers on my Ubuntu machine to get this working
- Because I wanted to test it on a lightweight setup, I only gave the VM 512MB of RAM – and it works – impressive
- SipToSis needs Java – I used Java 6.
An Answer for Twitter OAuth-pacalypse
For your smaller Twitter API projects, bash scripts etc, we have launched SuperTweet.net in case you don’t get OAuth implemented by the time Basic Auth goes away June 30, 2010. It’s a Twitter proxy – you use Basic Auth to talk to the proxy, and it uses OAuth to talk to Twitter.
SuperTweet.net Access Credentials
For example, to send a tweet, use the http://api.supertweet.net/1/statuses/update.format such as:
curl -u user:password -d "status=playing with cURL and the SuperTweet.net API" http://api.supertweet.net/1/statuses/update.xml
The password shown in the example above is never your real Twitter password, but a separate password you set up just for use with the SuperTweet.net API – As with Twitter OAuth, you can revoke, change, or disable that password without any impact to your real Twitter password or Twitter account. Also, you can deauthorize the SuperTweet.net API application itself on Twitter.com if you think it’s being bad, again, without affecting your real Twitter password or other Twitter applications.
Learn more: http://www.supertweet.net/
Wishlist for hypothetical replacement P2P Skype core
SkypeJournal speaks about the JoltID conflict. The post has lot a lot of good analysis of the legal battle and I encourage you to read the original post.
Phil also suggests it’s an opportunity for a new P2P core for Skype, listing a number of possible improvements. I second that list, but let me also add a few things I’d like to see in a new Skype P2P core:
- Published protocol specs, whether a open-standard or proprietary protocol, supporting network-layer interoperability (whether free or licensed).
- Less obfuscation, especially in terms of security.
- Ideally, open-source or or at least published peer-reviewed source.
Frankly, having the original founders of Skype out of the picture is probably ultimately a good thing for the Skype community and the Internet at large. It’s unbelievable that Ebay made a multi-billion dollar deal and still didn’t obtain control of the technology. I expect that will go down in textbooks some day as one of the dumbest (or smartest, depending on which side of the table you sat on) negotiations of all time.
Twitter #fixreplies and “intelligent” networks
A few weeks ago, I said “Twitter is a “Stupid Network” (the good kind)”. It turns out I was wrong.
Twitter created the #fixreplies problem (see here and here) for themselves when they decided to treat these tweets specially from the start, breaking the end-to-end principle.
These are tweets by people I follow – they are public tweets, not direct messages. They are in the public timeline. If I follow that person, they should be in my timeline like any other tweet from that person (whose tweets I follow), regardless of the content of that message.
I follow this person. That means I follow what they say, the updates they post. If Twitter never treated a post that starts with @ special in the first place, we wouldn’t be having this discussion. In that case, if I wanted to filter such tweets, I could do that in my client, at the “edge”.
Now Twitter has pulled those tweets out and so I can’t “filter” them – I have to go looking for them.
This is the kind of mess you get yourself in when you go around breaking the end-to-end principle all will-nilly.
Rejected by Skype
I didn’t make the grade. They’re not going to let me play with “Skype for SIP”.
I guess I’ll find a way to make it through another day, somehow.
Skype For SIP Beta
Via Pat Phelan, I signed up telEvolution Inc. for the Beta. We’ll see if we hear back or if they accept us.
It looks like Skype For SIP supports calling from Skype into a SIP PBX, but not calling a Skype user (free call) from a SIP PBX. It supports placing calls from SIP using SkypeOut, though, so we’ll see.
Skype For SIP now available in Beta
UPDATE: via Skype Journal, I see that “Skype for SIP” maps one Skype username to one IP address (SIP address?) – this is basically for “Skype Me” buttons and to let Skype users ring your PBX.
It also lets a businesses use SkypeOut for outgoing calls. As Phil notes, Skypeout rates are higher than what businesses can already get from typical SIP termination providers, so I’m not sure what the win is there.
So, all in all, “Skype for SIP” is not the SIP interoperability everyone is asking for. For better SIP/Skype interoperability, we still need to turn to third parties like OpenSky. On the other hand, while “Skype for SIP” appears to be a pretty small step toward Skype/SIP interoperability, it is at least a step, and we should give them some credit for that.
