agranig

Yes!?

Blue is so facebook, and everybody hates facebook at the moment, so we are grey/yellow for now. Has some potential for pivoting though.

And since customer satisfaction is everything, we published our progress on https://twitter.com/doublestealth/status/220277242935246848 just for you.

Writing great code means making it easily readable and understandable by other developers. If you want to show off your quirky syntax skills, for god's sake play perl golf or attend at obfuscated code contests.

What was your reason to do both a Ltd in UK and a GmbH in Austria?

We've registered an Austrian GmbH couple of years ago and haven't had any issues with that so far. The break-down of voting rights and shares are directly bound to how the common stock (usually 35k€ in AT) is being split. When it comes to investment rounds, the investors either increase the common stocks or buy it from the other shareholders for the nominal price (the percentage of the common stock value). The whole process is strictly bound to a formal process (a notarial act), which can get quite expensive, which is the only down-side in the long run.

On the other hand, Ltds still have some shady smack for some reasons over here (one is that you're seen as being cheap), so when you're an Austrian or German company, I bet you gonna need to explain as a small startup why you have gone the Ltd path when talking to big potential customers, and I think this is something you want to avoid at that stage ("act like how you want to be seen, not like who you are", and each serious company here is a GmbH). I understand that it's a big turn-off for young founders to put in 17.5k€ in cash from the start (which is the minimum amount to be provided when founding), but it pays off when it comes to reputation, at least when acting in the B2B business.

This is pretty cool, thanks! Setting "double_buffer yes" prevents it from flickering in Ubuntu.

As for the command-line VoIP app, you can use "linphonec" included in http://www.linphone.org/.

The tips at http://www.webupd8.org/2011/04/things-to-tweak-fix-after-ins... solved a lot of pain points for me.

Vienna, Austria

Sipwise - http://www.sipwise.com

Sipwise develops and integrates open-source VoIP soft-switches for Europe's biggest Cable operators.

We're hiring full-time, on-site Perl developers and VoIP engineers, check http://www.sipwise.com/news/jobs/sipwise-is-hiring-perl-web-... and http://www.sipwise.com/news/jobs/sipwise-is-hiring-voip-engi... for details. If you need to relocate, we'll of course assist you in finding a nice place.

The VoIP and System engineer positions are full-time and on-site jobs, no exceptions here. If you're an experienced Perl/Catalyst hacker with a good track record, we would also consider telecommute and/or contracting.

@Sipwise in Vienna/Austria

- Web developer: Perl/Catalyst/MySQL and HTML/CSS/JS

- VoIP engineer: OpenSER/Kamailio/OpenSIPS and >3 years of experience in SIP routing

- System engineer: HA/Scalability/Mass-Deployment using Corosync, Pacemaker, Git, Perl

We develop and integrate carrier-grade VoIP systems for 100k-1Mio end users each at major European ISPs. Send an email to agranig at sipwise dot com.

I've launched http://fonoso.com/ a couple of weeks ago, which takes your idea a step further and records full phone calls and could be used for podcast recordings over the phone, or any other use case where you want to archive and/or share a phone conversation.

I didn't put any time or efforts into polishing or marketing it, so if you (or anyone else) wants to team up, contact me at agranig@fonoso.com. Instead of twilio or something similar, I use my own SIP trunks to carriers, so for inbound calls, no fees are charged. It's easier to offer something for free with this approach :)

OpenSIPS is the sister of Kamailio, both being the result of a fork of OpenSER. Sipwise actually uses Kamailio as the core routing engine, and provides (as Open Source) all the building blocks like provisioning APIs, billing and rating systems, web interface etc. to create a fully fledged telephony system from start to end. Asipto's founders are the core contributors and co-founders of OpenSER/Kamailio, so Asipto provides the core competence in SIP routing and Sipwise offers the know-how of building highly available and scalable SIP systems.

Yes, OpenSIPS is used at telcos to create SIP services. Just be aware that it's more or less the same as Kamailio, which we use as SIP routing engine, and that it's only around 20% of what makes a telephony soft-switch.

For the first 100 sign-ups, I'll top their accounts up to 1€ in order to place test calls :)

We at Sipwise implement VoIP switches at major ISPs in Europe, and the most uncomfortable question, which is ALWAYS asked (mostly just as a side-question, like "Btw, I suppose you support it anyways, so how does your solution work in that regards?") is the one of lawful interception.

There's a specification defined by the PacketCable consortium (http://www.cablelabs.com/packetcable/downloads/specs/PKT-SP-...), and I'd say that almost every major vendor has implemented it in one way or the other in order to be deployed at cable ISPs.

It's a matter of fact that every vendor of telco equipment has to provide a lawful-interception interface when doing business at a serious scale (say, enabling services for >10k end-users). That holds true in countries with questionable political systems, but even more so in Central/Western Europe and especially in the US. It's really just how the technology is handled and used.

Regarding conspiracy theories: there's a popular saying in the telco/network industry, going like "Nobody has ever been fired for buying Cisco equipment". It's just a matter of taking personal risks for your CTO.

When operating in the B2B landscape, it's pretty common. Large corporations take time from the first pitch until signature (sometimes >6 months), and during that time you can iterate over concepts based on their feedback. If you are realistic when estimating the probability of signing the deal and thus realistic of taking the risk, negotiate the payment terms wisely (e.g. 50% after signature, 25% on delivery, 25% on acceptance) and manage to survive until first payment, it can be a great approach for boot-strapping.

It helps having a reputation at the first clients beforehand (e.g. due to free-lancing for them, or being introduced by others), otherwise large corporations might have doubts working with a start-up anyways.

It worked well for my start-up, where I felt uncomfortable with that approach also as a first-time founder (it's pretty awkward sitting there and listen to your sales guy promising what-not to the client when nothing is there in fact), but I've learned a lot from him since then :)

The problem is not really specific to your company, we've been in the same situation also, although we were quite experienced, and I guess it happens to lots more companies. Fortunately we managed to turn it around.

We've started our company ~4 years ago and got our first customer immediately without even having a product. We build carrier-grade VoIP platforms for internet service providers, so it needs to be really reliable, and it needs to handle hundrets of thousands of customers. So we started out building the platform on a tight time-line (~6 months from nothing to go-live), taking all actions necessary to deliver. It was a great success, but it was really tailored specifically to that customer. Immediately afterwards, we did another project of that scale, and then another one. All of them worked really well, we've always been profitable, but it was quite hard to maintain them, let's put it that way. Beside that, it was next to impossible to scale the business in a reasonable way while keeping up the product's quality.

In order to fix this issue, we decided to make a bold move and planned to release the product as open-source (we're quite deeply involved in different large open-source projects, so we know the business behind it quite well). This forced us to convert the platform into a stage that literally everybody can install and maintain it. We hired two people to help us ripping apart all the different parts, review, package and document them, re-put them together in a standardized way and create a software bundle which allows reproducable builds (there are like 100 different software components involved, half of them from other open-source projects, half of them from us, and they need to be integrated with each other really tightly).

The result was a clean, well-documented platform, which now can be installed within 15 minutes with very small manual intervention. It now also allows seamless software upgrades, and we can plug different commercial modules on top of it to still have a viable business model. We're going to release it to the public next week, so we definitely succeeded cleaning up our mess. It took us 18 months to do so though, so it's hard, it costs a lot of resources (money, time, dedication of the people behind it), but it's definitely possible.

We did a presentation (sorry, German only, but you'll still get the idea I guess) about the concepts of it, see http://glt09.linuxtage.at/slides/hochverfuegbare_voip-system...

Mantis http://www.mantisbt.org/ works very well for us. Easy to use and to customize.

you are aware of the fact that 'accidantely' leaking secret information is and has always been part of Steve's game, aren't you?

For these kinds of SIP scenarios you could just use sipp (http://sipp.sourceforge.net/) and craft a simple scenario file like http://sipwise.com/reg_srv.xml.txt instead.

Start with "sipp -sf /path/to/reg_srv.xml -i <local ip> -p <local port>" and you're done.

For most of the questions, I as an entrepreneur would answer like "does this really matter?". You normally have other problems than that...

From a pragmatic point of view, if you need to "reinvent" stuff for some reasons, e.g to implement them in C or whatever, prototype it in perl as generic as possible and just translate it to C or your language of choice... look how they did it in perl (there's next to nothing they didn't implement by now), then implement the algorithm in "your" language. It saves you really lots of time.

Which might not be a problem for servers in most cases.

Most startups i read of here, try succeeding in getting famous with a service known by millions of people. But, the market for startups trying to pitch products to well-established companies is not only big, it's also quite worth the effort, compared to direct-marketing. In most of the cases, startups don't have financial resources to reach out for residential customers, no matter how interesting your product might be (ok, you still might dream about succeeding like $youtube, $facebook, $whatever, but reality is you need some revenue to pay your rent, regardless what enthusiasts tell you.. and they won't pay your rent, unless they sign some investment thing - at least, here in Europe we tend to think like that).

However: large corporates often either lack innovation, or they try to lower costs by implementing something which is open-source. There is your chance. Go implement something based on open-source which is competitive to some commercial product, and you'll see you can sell for 1/5 of the price of big vendors.... and a lot of companies are really sick of being dependend of big corporates like Cisco, Nortel, whatever... you "just have to get your foot into the door" of such companies... and for this task, you have to have a great sales person.... you don't make it as a technical kind of person... I tried it... forget it... it's a completely different world... the important thing is: respect it... these sales-guys sell your late grand-mother, but they keep you going... No-one on the street will ever recognise you, and no-one on the street will have heard of your company, but does that really matter if you deliver to a big corporate which pays you some ten thousands of dollards a month to satisfy THEIR customers? Think about it, before wasting just another 10 men months to something RESIDENTIAL customers might like.

I'd like to see a web service and plugin for Mozilla Thunderbird to synchronize message filters, junk settings, mail box settings etc. among different Thunderbird instances (running on different computers or on different OSes) - similar to foxmarks for Firefox bookmarks.

Then you should try http://wazee.org/ as streaming radio.