akalsey

A co-worker mentioned they had a desk at the end of their driveway with a free sign on it for over a week with no takers.

I told them to put a $10 sign on it and someone would steal it.

It was gone the next morning.

My wife runs an estate sale company, helping families dispose of property. Sometimes the family wants her to give something away. She hates that. It’s way more work for her than selling it for even $1.

She says, “There’s no one more entitled than someone you’re giving something to for free.”

People responding to an ad for a free item will ask her to deliver it, load it, store it, repair it, and warranty it.

My theory is that folks who seek something out because it’s free tend to have more time than money. And that means they don’t value time very much.

You should never accept the caller id of a phone number that called you as identity verification. It is trivial for anyone with a VoIP line to set caller id to whatever they wish.

Company the size of AT&T working in highly regulated areas, everything's a subsidiary for various accounting and legal reasons.

AT&T Mobile and AT&T UVerse are two different companies. They probably have different operating entities for different states, even. But they roll everything up into a single brand for ease of sales and marketing.

We think it would be neat to do this sort of thing with existing numbers, too. That's why we released Ameche a couple of months ago. http://voxeolabs.com/ameche/overview/

Built by the same folks as Tropo was, so the couple hundred thousand Tropo developers will find the Ameche API familiar.

As it gains carrier support, you'll be able to do all this with your existing mobile number.

Thanks. As you can imagine, we're all amped up.

AT&T does have some APIs for interacting with MMS. Those have actually been around for several months. The MMS API they offer at https://developer.att.com/developer/basicTemplate.jsp?passed... is restricted to working with AT&T mobile numbers only, though.

Not exactly. Instead of white labeling our APIs in our cloud, AT&T is running their own APIs in their own network, just like our previous announcement with Deutsche Telekom in Germany. We (Voxeo Labs) provided the technology to them, and licensed the APIs.

Applications developed on the Call Management APIs do not require approval by AT&T. The APIs offered by AT&T that require approval tend to be those that interact with subscriber devices. If you can take over a mobile handset with it or grab someone's private info, AT&T wants to approve your code.

Yes, Call Management is cross-carrier. Don't worry about not understanding the press release. Those aren't ever written to be understood by humans.

The only protection a hotel operator gets here is protection of their business model. Governments should not generally be in the business of favoring one business model over another, or of passing laws that protect models from the march of time. See also: Uber, copyright extension act.

Tropo has Australian numbers. And 40 other countries. Has for years. http://tropo.com (disclosure, I'm the product manager).

But really, if all you're doing is dialing out, then you don't actually need a local number. Just use whatever service you want (us, Twilio, Plivo, someone else, etc) and set the caller ID to a local number or make the call as a blocked caller ID.

WebRTC is a w3c standard - it's part of HTML 5 - so getting browsers to support it isn't going to be as big of a problem as you suspect.

Browsers today (even with HTML5) are mainly consumers of media. There's great ways to get audio and video to a browser, but no capabilities for getting access to a user's microphone and camera and no way of sending media from a browser to elsewhere. WebRTC fixes that.

A phone call has two halves, there's the signaling (where does this call go to, is it still active, did the other party hang up, etc) and the audio (the "media" in telecom parlance). What Phono is doing in this demo is connecting the media and the signaling from an early WebRTC implementation to the public phone network. Using the audio capture from the browser and letting you make and receive real phone calls with it.

Automobile manufactures will tell you to use factory parts, too. Doesn't mean there aren't other compatible options.

OpenVBX would run on any platform that emulates Twilio's API. That includes Twilio (of course), Plivo, an Teleku (disclosure: now owned by us). There may be others out there as well.

The core that actually runs your applications is open source. Runs on any java SIP servlet app server. You can run Tropo apps without touching Tropo.com at all or paying us for anything. There are a number of companies doing this today.

We did this precisely because we wanted to prevent lock in. We want your business, but if we suck, you should be able to go elsewhere.

VoiceXML and CCXML are suited for most telephony apps. We've seen conference calling, dating, virtual Number services, notifications, and lots more on XML telephony platforms. Twilio and Tropo Apis are each subsets of what Vxml & CCXML are.

Vxml and CCXML are more complex, sure. And for that reason they may not be suited for the same developers targeted by cloud Apis.

Prism, the app server platform Tropo.com runs on, is not open source. But because Tropo core is written to the JSR call control and media server standards, Tropo will run in any server that implements those. Mobicents and Sailfin are two open source options.

If you're looking for more options, there's a LOT out there. Think of all the automated voice systems you interact with on a regular basis.

In the open source world, you could install Asterisk yourself and use something like Adhearsion to develop your apps. Adhearsion is an open source framework for building Asterisk applications in Ruby. http://adhearsion.com/

Whistle from the 2600hz project could be of interest, too. http://www.2600hz.org/whistle/

To build telephony applications in Java, you can use SIP servlets, a Java standard (look up JSR 289 and JSR 309). Because the Java standard is extremely low-level, we open sourced the framework we use for building Java speech applications. See Moho at http://labs.voxeo.com/moho/ or https://github.com/voxeo/moho

You can also take a look at at VoiceXML, a W3C standard for building telephony apps. VoiceXML is how the big boys build telephony applications. There are a number of commercial and open source VoiceXML products, and tons of hosting companies. A search for "VoiceXML Hosting" will turn up several thousand options. Many of which will work internationally.

And of course Tropo, as already mentioned, has an open source core as well as a ton of other fun open source stuff. See http://tropo.com/ and https://github.com/tropo/

Changing the root web service URL for OpenVBX requires that you change one line of code. No need to even fork it.

It's not a service -- it's open source software you download and run on your own servers. Their web site or ability to keep it online has nothing to do with the product.

Tropo provides phone numbers in 41 countries, including the Netherlands. We have a large number of Dutch customers. We also provide Dutch text to speech and speech recognition.

One reason is that we want our developers to be part of a technology community. Attending (and presenting at) industry events, meetups, bar camps, and local user groups. There's a lot more opportunity for that if you're located in certain parts of the country than others.

I'm sure that Buffalo, Oklahoma is a fantastic place to live, but we prefer you be somewhere you can hang out with, learn from, and teach other geeks.

That said, if you're unbelievably awesome, hit me up anyway. We like smart people regardless of their location.

We're hiring Java wizards to work on the core of Tropo. http://tropo.com/

We're a distributed team (China, London, Orlando, Philly, Phoenix, and Bay Area) so we're adept at working remotely.

Somewhere in the Bay Area preferred, but we'd also love to talk to you if you're located near any other large US city or technology hub (Seattle, Boulder, Austin, Chicago, Boston, NYC, Philly, etc).

Job description at http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.aspx?...

We're hiring Java wizards to work on the core of Tropo. http://tropo.com/

Bay Area preferred, but we'd also love to talk to you if you're located near any other large US city or technology hub (Seattle, Boulder, Austin, Chicago, Boston, NYC, Philly, etc). We're already a distributed team (China, London, Orlando, Philly, Phoenix, and Bay Area) so we're adept at working remotely.

Job description at http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.aspx?...

We're also looking for a NOC engineer in Las Vegas. http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.aspx?...

We're a very distributed company, with some projects being worked on by people in a dozen locations, so some form of IM is needed.

I'm a big XMPP proponent (and Voxeo acquired my xmpp-based company) and we do use XMPP for a lot of things inside Voxeo (like Phono, our jquery softphone: http://phono.com/).

Every voxeo employee has an XMPP ID, but they don't tend to get used. People gravitate to Skype naturally. It's the user experience on the client side of XMPP that keeps people from using it extensively for internal communications. At any given time I've got 40+ group chats going on and we create and destroy group chats many times a week for specific needs. The ability to make a voice call to one or more participants of the chat is also a winner.

The fact that everyone on the planet has a Skype ID also helps. We can easily pull partners and customers into chats as needed. They're already on Skype, so we don't need to teach them anything new.

It's a lesson in usability, certainly. Create a client that allows users, without any assistance, to create groups, move seamlessly between text, voice, and video, and has a foolproof signup and setup process, and folks will use it.