sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
SIP uses a cryptographic algorithm called MD5 for authentication however MD5 was invented in 1991 and since that time a number of flaws have been exposed in it. The US Computer Emergency Readiness Team (US-CERT) issued a vulnerability notice in 2008 that included the quote below.
Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use.
Does that mean SIP’s authentication mechanism is vulnerable? While not necessarily so, at least in relation to the MD5 flaws, the real answer is it depends on how much your password is worth to an attacker? For example if your SIP password only uses alphabetic characters and is 7 characters or less in length it can be brute forced for less than $1!
Read the full article here.
There’s been a bit of buzz around the VoIP ecosystem lately with the news that Voxalot are closing down their service from the 31 Dec 2011. I’ve put together a guide for all Voxalot users considering SIPSorcery as a replacement service. I’d strongly encourage any existing Voxalot users to check the guide out and here at SIPSorcery we are hungry for your business.
One feature of SIPSorcery that some Voxalot and other users have mentioned as being a problem is the need to construct dial plans in Ruby script. To those of us that have a programming bent the ability to use Ruby scripts allows the creation of almost infinitely powerful and flexible dial plans but understandably for those without a programming bent that just want a few speed dials or custom rules it can all be a bit daunting. Voxalot provides a much more limited way to express dial plans but also a simpler way at least up until now.
I’ve been working for a while on new dial plan wizards for SIPSorcery and the latest one which I’ve baptised the “Simple Wizard” is my attempt to combine the power of the SIPSorcery Ruby dial plans with a much simpler wizard like interface. The new wizard is in the final stages of development and I hope to release it later this month but given that Voxalot users are currently weighing up their options I thought I’d give a preview. In the sections below I’ve included a screenshot of the Voxalot way of doing things and compared it to the SIPSorcery Simple Wizard way of doing things.
Add Speed Dial
List Speed Dials
Add Smart Dial Rule
List Smart Dial Rules
As well as being able to use the Simple Wizard to construct dial plans for outgoing calls it will also be possible to construct incoming dial plan rules. For incoming rules the pattern gets applied to the From header. The incoming rules can be applied to an individual SIPSorcery SIP account or all SIP accounts.
There is a lot more detail to come with the Simple Wizard but for Voxalot users considering their options I’m confident that it will make building SIPSorcery dial plans simpler and more flexible than the various Voxalot screens.
There was an announcement a while ago on the xmpp.org site about Google’s adoption of the official Jingle standard. The same announcement was posted by Peter Thatcher a Google engineer to the Jingle mailing list. The announcement got a bit of attention and I originally came across it on Hacker News. After spending a fair bit of time looking into what the upgrade means as far as integrating with Google’s XMPP service the conclusion I’ve come to is not much at least not yet.
The original reason I, a SIP person, started messing around with XMPP and Jingle was to see if there was a better way to integrate with Google Voice. I made a few blog posts at the time and ultimately the investigation didn’t end up yielding any fruit because of a peculiarity in the way the Google XMPP server deals with the RTP media streams which would preclude it working with standard SIP devices (very briefly it requires that STUN packets are exchanged on the RTP sockets before the RTP can flow).
So fast forward 8 months and I finally found some time to delve into the Google XMPP service again to see if there’s any chance of getting SIP interop, or more correctly RTP interop for SIP devices, working. The other thing that spurred me on a bit was Google + and specifically the integration of the Google Talk Gadget into the Google + application. The Google Talk Gadget is not new it’s been in Gmail for quite a while but the integration looks a lot more interesting with Google +, specifically being able to call from a SIP phone into a Google + Hangout (a web based voice/video conference call) would be cool.
As alluded to above the results of my latest little adventure into Google XMPP land haven’t been very fruitful. Yes Google now appear to be sort of using Jingle for their call set up but the media side of things doesn’t appear to have changed at all and in fact the original email from Peter Thatcher did state the work on XEP-0176: Jingle ICE-UDP Transport Method, which is more down to the nuts and bolts of the RTP side of things, is ongoing. In the meantime the XMPP call set up mechanisms used by Google are a combination of Jingle and Gingle (Google’s original implementation of a Jingle like protocol) and crucially the media layer is still Gingle.
My hope is that when Google get the Jingle ICE-UDP transport implemented they will also implement the XEP-0177: Jingle Raw UDP Transport Method which should allow RTP level interop with SIP devices which will in turn allow SIP Proxy services like SIP Sorcery to make and receive calls with Google’s XMPP network. Some SIP servers that proxy media such as Asterisk and FreeSWITCH are already integrating with Google’s XMPP network by implementing the Gingle/XEP-0176 STUN connectivity check mechanisms on the RTP sockets. In SIP Sorcery’s case and also for other non-media proxying servers such as Kamailio the integration is not possible because it then needs the end SIP devices to do the STUN connectivity checks and until ICE support becomes widespread they wont be able to.
Unfortunately this is another example of the really painful issues caused by NAT. If NAT had never been invented and the World had been forced to upgrade to IPv6 the internet would be a much better place :). In the meantime communications protocols like SIP and XMPP end up with as many addendums and extensions to deal with NAT as they do to deal with their core functions!
I’ve had a couple of requests from people who made a previous donation to the SIP Sorcery project regarding whether the donation would count towards a payment for a Premium account. The answer is that yes it can. I’m happy to apply a pro-rata basis for all donations towards a Premium account. In fact all types of previous payments including donations and the eBay auctions are treated the same. If you would like to take advantage of this offer please send an email to admin@sipsorcery.com with your sipsorcery username and if your PayPal payment came from a different email address please include it or a copy of the payment receipt.
In recognition of the valuable feedback and in some cases assistance to other users that Beta users have provided I have created a special offer for anyone that wants to convert to a Premium account. For a $50 once off payment (no subscription required) Beta users can purchase 2 years of a SIP Sorcery Premium service. This compares to the normal price of $35/year and represents nearly 30% off.
The Premium service has unlimited SIP Providers, SIP Dial Plans and access to all Dial Plan functions. From the 1st of Aug 2011 Beta accounts will be treated the same as Free accounts and subject to a single SIP Provider, a single SIP Dial Plan and not able to access some Dial Plan functions.
Please note the offer will only last until the 31st July 2011. After that date any Premium account upgrades will be at the normal price.
The link to the offer is below. Note you’ll be prompted to login and the offer will only show up for Beta users:
Free accounts have been re-enabled on sipsorcery.com as part of the move of the service to a freemium model.
The free accounts come with:
There are some limitations attached to the free accounts to limit the resources they can consume and also to reduce the ability of the accounts to be used for fraudulent purposes which unfortunately occurs quite a bit. The limitations are:
Due to free accounts being available on sipsorcery.com the demo.sipsorcery.com system has been shut down.
Enjoy!
As part of the recently announced changes to the sipsorcery service I’ve decided to get the web site re-designed (actually that should just be designed since my initial effort doesn’t deserve to be called a design). I’ve commissioned a contest and got feedback from family and colleagues as I don’t trust my own judgement much when it comes to design type things. However so far the feedback has been confusing. A couple of colleagues swear one design is a real stand out but my wife thinks it’s rubbish and that a different one is the bee’s knees.
Instead of that approach I though I may as well ask people who are likely to visit the site on occasion rather than those making a choice based on aesthetics alone. So if anyone has got a spare minute I’d appreciate any feedback at http://99designs.com/web-design/vote-qf6uz1.
A couple of months ago I got inspired to muck around a bit with Google’s Analytics service thinking it would be a good way to collect some interesting statistics on the sipsorcery service. So I wired up a handy little .Net library called GaDotNet into the sipsorcery application servers and started collecting the host portion of each SIP URI. In this day and age of highly sensitive privacy concerns I realise that may worry some sipsorcery users but I have made sure the tiny bit of information collected is anonymous and if an IP address that didn’t belong to a SIP Provider showed up in any graph I would not publish it.
The Google Analytics graph illustrating the 10 most popular call destinations for sipsorcery for the last month is shown below.
It’s not particularly exciting but it’s interesting for anyone who may want to track their own statistics or events from their sipsorcery dialplan. If there is any interest I can add a new method to the sipsorcery dialplan. It does take a little bit to work out how Google Analytics works for event tracking so for anyone considering it be aware there is a little bit of research to do.
I’ve been half heartedly seeing if any softphone makers are interested in supporting the pseudo ICE mechanism that GTalk uses when setting up the media on an XMPP call. It doesn’t look promising at this stage. Google did make a change around the start of this month to their XMPP call set up mechanism, which broke the ability for Asterisk 1.8 to place outgoing calls through GTalk, so maybe they are working on the service and will have full Jingle support soon which in theory would allow ICE compatible phones such as Counterpath’s softphone range and others to be able to place SIP calls through sipsorcery and have them terminated via GTalk/Google Voice’s XMPP/Jingle service. That would be neat as it would be a validation of SIP and XMPP signalling working together and interconnecting two technologies which both support a large number of users.
However Jingle for GTalk isn’t here yet and in the interests of encouraging any developers that are involved with writing softphones to look at supporting the Google STUN requests on the RTP sockets I’ve created a prototype application that shows how to do it. The application is written in C# and hosted on codeplex here. What the application does is listen on a socket for a SIP INVITE request and when it gets one translates it to an XMPP request which it sends off to GTalk. As well as handling the SIP and XMPP signalling the prototype application also fires up two media sockets, one that talks to the Google XMPP end and one that talks to the SIP phone end. The media sockets are needed so that the STUN requests and responses required by the Google XMPP end can be handled correctly and that’s the bit that’s missing from the softphones.
Recently Tropo very generously donated a hosted server to the sipsorcery project. In the intervening period I’ve been testing out different ways to see how to make best use of the server. The initial plan I’ve come up with is to have a separate service running under demo.sipsorcery.com. The demo system is identical to the main sipsorcery system except for these caveats:
1. There is no registration agent running so SIP provider registrations are not supported,
2. There is a daily call limit of approximately 25 calls for any 24 hour period enforced,
3. Accounts are going to operate on a revolving door policy. Once the capacity of the server is reached a new account signup will result in the oldest account being turned off.
The motivation behind the caveats comes primarily down to preventing fraudulent SIP behaviour and to have a service that will allow new users to test out the sipsorcery features.
When the original sipsorcery server was open for new accounts I was spending more and more time detecting and shutting down accounts that were trying to crack SIP provider passwords or were being unfriendly with their call traffic. That time has pretty much been reduced to nil now that people have to purchase an invite code. This is not surprising as a PayPal/eBay transaction will leave more of a trail than fraudsters generally like to leave so the sipsorcery service is not that attractive for their activities anymore.
The registration and daily call limits on the demo.sipsorcery.com service are because I don’t want to go back to a situation where I spend more time being a policeman than a programmer!
The details of the demo system are:
SIP Server: demo.sipsorcery.com
Web Page Portal: http://www.sipsorcery.com/demoweb/portal.html
I do expect a few teething issues so if anyone encounters any problems please post on the forums.
And again a big thanks to Tropo for providing the hardware and support for the demo system and hopefully allowing a few more people to get a taste of sipsorcery.
