The Changelog: Software Development, Open Source - Building Telephony Apps (Interview)

Episode Date: November 30, 2010

Wynn caught up with Chris Matthieu of Voxeo Labs to talk about Phono, Tropo, Adhearsion, and building telephony apps with open source tools.

Welcome to The Change Log, episode 0.4.1. I'm Adam Stachowiak. And I'm Winn Netherling. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at the changelog.com we're also up on github head to github.com slash explore you'll find some trending repos some feature repos from our blog as well as our audio podcasts if you're on twitter follow change log show not the change log and

i'm adam stack and i'm penguin p-e-n-g-I-N-N. Fun episode this week, but first, I guess, happy anniversary. Yeah, man, happy anniversary, Wynn. About a year ago, we cranked this thing up. I remember doing episode three for my in-laws at Thanksgiving, talking to Rob Pike over at Google. Rob Pike, Google, go. It's a great episode. If you haven't caught that one, check that one out. Did you have a good holiday?

I had an awesome holiday. How about you? Great holiday. It's one of my favorites. You know, to sit back and reflect what you're thankful for this year. I know we're both thankful for the guys over at GitHub. Got a great announcement, but we should mention who we talked to first. Who did you talk to?

Talked to Chris Matthew from Boxeo, Tropo, Teleku, pretty much all things telephony. He's a biz dev guy over there, puts the development back in biz dev, I guess it is. And we talked about Phono, which is a jQuery-enabled, what is it? jQuery plug-in allows you to do telephony apps, basically from the browser, kind of headless without having to have a server behind it. Tropo is your server.

And, you know, you can create all the crank call scripts to your heart's content. So these front end guys can now take jQuery and easily enable their websites to make phone calls. Can you believe it? You can order pizza right there from your browser. I can't wait to do it. What's this big announcement we've got?

We are partnering with GitHub. We're going to help them promote the, not just that they need any help really, but the job

board. Got approached by Chris Wanschroth to be their exclusive partner in promoting their job.

So we'll be reading GitHub jobs on air. So if you go to github.com forward slash jobs, you'll find some info there.

Upon the sign-up process, you'll be able to check a little box that says promote my job on the changelog. So we'll read those jobs for a hundred bucks, which is pretty inexpensive and a great gift for us really because the great GitHub guys have helped us out plenty and we're grateful for them. Now, this is pretty much a labor of love. So if you want to keep the changelog on the air, this is a great way to support it. Absolutely. It helps us keep the lights on. I mean, it's not a huge amount of money, but it's good to keep the lights going and helps us

travel and get out to the conferences we want to in the summertime or throughout the year. So this is a really good fit for us, and we're really thankful for Chris and the rest of the team at GitHub for giving us the opportunity to do it. It's awesome. Also thankful for the open source community. Without your projects, this whole podcast wouldn't be possible.

So shout out to everybody that's contributed anything we've covered in the last year and keep the open source bits coming. Yeah, special thanks for everybody who sends those emails into ping. We ping at thechangelog.com. We really appreciate the heads up on some of those cool projects we hear about. So keep those coming, keep open source going, and we'll all keep doing what we do. Make it do what it do, baby. Fun episode, man. You want to get to it?

Let's do it. We're chatting today with Chris Matthew from Rubyology and Voxeo Labs. So Chris, why don't you introduce yourself and kind of your role over there. Hey, Wynn. Thanks, first of all, for having me on the show. So I'm the director of business development for Voxeo Labs. And I was originally the founder of Teleku. So that's kind of how I came about this way.

So Voxeo Labs is part of Voxeo. It's a 10-year-old company, very mature company, 150 engineers, offices in Orlando, Beijing, Germany, and where all of the advanced next-generation technology has taken place for Voxeo. So Teleku, Tropo, and now Phono are all products of Voxeo Labs, and there's a few more in the pipe that we can't yet announce but are coming soon. Very exciting times in the life of telephony at the moment. So, yeah, we should mention Tropo is a telephony company, has a few products out there. So what's the state of open source telephony these days? Yeah, so we were talking earlier there, There's a lot of open source happening. I mean, Voxeo prides itself on being open sourced.

Just about everything we touch ends up being open sourced. So we mentioned Tropo a minute ago. Tropo is our cloud communications platform. It's almost two years old, and it's quite extensive in its delivery offering. It's a cloud communications platform that lets you build voice, telephone applications, SMS, instant messaging, and Twitter, all with a single API, which makes it really powerful from a communications perspective,

being able to talk to customers on all four of those channels and interchange channels. So you could talk in the voice, drop a message on SMS, and then send them a tweet, you know, all in one conversation. So that's pretty interesting. And that's open sourced on GitHub. If you go to github.com slash tropo, T-R-O-P-O, you'll find all the source code to that. Adhesion, we were talking about earlier. It's a Ruby library for building telephony applications using Asterisk.

That's open sourced and being maintained, and Voxeo is the official sponsor of that project now. So that's really cool. We can talk about that. And then Phono SDK, we just released a month ago at the JQuery conference, and we're getting a ton of buzz around that. In fact, a week or so ago, it was on Twitter's top tweets. So it's a telephone that runs in your web browser.

It can place and receive phone calls and even do some XMPP-based IM chat technology just by dropping a few lines of jQuery script in your web browser. So that's pretty amazing, and that's also open sourced on GitHub as well, github.com slash phono. Well, that's quite the lineup. Let's start with Adhesion. I remember seeing this, I guess, two or three years ago at Lone Star RubyConf. Jay was giving a demo of Adhesion. So this is a Ruby, I guess, framework more than just a library.

It's a Ruby framework. Does it sit on top of Asterix or related at all? Yeah, so it does sit on top of Asterix. And Jay Phillips was the original author. And Jason Gecki over the years has gotten more in control of contributing and steering that product. And Jay is kind of taking a break. He's focusing full-time at Pivotal Labs on day-to-day stuff. And Jason is the VP of Innovation.

What a title for Voxeo Labs. So he's actually my boss and still contributes to Adhesion. a guy by the name of Ben Klang who's actively involved on building and working through pull requests on features being added to Adhesion. What's even, what I find really cool, just to show you just how

techie, geeky all of these folks are, Jason being a VP at FoxAO Labs on the flight going to Lone Star RubyConf, he wrote a project that he calls Agitate. And what Agitate does is kind of a play on the asterisk AGI protocol. Anything that runs on AGI, which Adhesion does, you can point that seamlessly at Tropo. So for Ruby developers that are building on the Adhesion framework, instead of having to like stand up your own asterisk boxes and manage scalability that way, you could easily just take your existing

Adhesion app that you wrote and then redirect it to Tropo and then let us scale it for you to millions and millions of calls, whatever you need to accommodate your Ruby app. So Adhesion, I guess, is pretty much the stand-up, run it yourself, and then there's other offerings in the cloud such as Tropo? Exactly. So Tropo makes it very easy to scale applications because the thing about Tropo is it actually sits on Voxeo's network, global voice network, which is, you know, if you look at things like Amazon EC2 and those types of cloud, you know, what we web developers call cloud technology or cloud platforms, they're all optimized for really web traffic, not necessarily for voice. So in the voice world, the whole concept of QoS, quality of service, is very particular when it comes to managing packets of voice so that they get synced in the same order, that there's very low or no jitter of packets arriving in different formats or being assembled in the incorrect order. So Voxeo has seven data centers around the globe that are very focused on voice traffic,

delivering voice traffic and uptime. So Voxeo's evolution platform, it's 100% uptime guarantee SLA network. While Tropo, we've discounted the price significantly of what an enterprise customer typically pays for that service, but we don't offer the SLA that goes along with it. But at the same time, we're riding on that same network, which makes it pretty cool to be able to elastically scale to whatever number of ports or volume is required to meet our customers' needs. So Tropo has that luxury, if you will, of having one of the largest voice networks in the world at our disposal. Let's take a step back and give a little background here. I think the first time that I heard the term telephony was with the telephony API in Visual Basic way back in the day. You could drag the control to your form and now control your modem to make outbound calls,

which back in the late 90s seemed like the coolest thing. What sorts of applications can you write with these types of APIs and what types of services can you perform? Wow. Hey, yeah, we've come a long way since I think the TAPI. I think that's what they call it. It was like the telephony API. Right, TAPI. There's TAPI and MAPI. Remember, I think, the TAPI. I think that's what they call it. It's like the telephony API. Right, TAPI.

There's TAPI and MAPI. Messaging API, right? And then SAPI was their speech API. Yeah, we've come a long way. So really with Tropo and to some degree Adhesion, Adhesion really focuses

on just the voice side of calls where in Tropo you can do lots of other things like SMS, et cetera. You know, any of those, any of the applications you call like banking applications where, you know, you give it your account number and it can tell you balance, you can move money from one to another, those are just typical what we just call IVRs, interactive voice response systems. Those are kind of like old just call IVRs, Interactive Voice Response Systems.

Those are kind of like old school what you can do. Even until just recently, a lot of websites still – well, a lot of them still have what they call click-to-call. Like if you want to talk to a customer service agent, you're on a website. You can enter your phone number, and then what happens is the voice platform calls your phone number. Then it calls the agent, and then it bridges the calls together. That's a common click-to-call scenario. But with Phono, with the phone in a browser that we just recently released, when you hit the button to click to call, it's a phone in your browser. So it automatically just is your phone, doesn't have to call you, doesn't have to ask for your number, and it dials the agent with one step. So that's an example of advances that just happened a that typically come with telephony, things like speech recognition that we've been doing for a very long time where you can define grammars, words to listen for, phrases to listen for.

And that allows the customer to not only talk with their voice control the application, but they could always drop back down to touch tone if they wanted to. And things like transcription. So if you're building something where you want, like Google Voice, where you want it transcribed, the voicemail and sent to you, we have transcription services. and the ability to call many, many phone numbers at one time or receive many, many phone calls at one time is just a world of difference in the cloud world because in the old days, like a couple of years ago or a year ago,

when a company wanted to actually deploy an interactive voice response system, they would have to do all the math to say, okay, the busiest I think I'll ever be is a thousand simultaneous calls. So then they would go off and buy like a thousand ports of hardware, deploy it, you know, maybe they'd buy 2000 ports because they needed high availability, deploy it at multiple sites to architect something that could withstand that volume. And then on a typical day, they might only have 300 calls. So look at that wasted hardware and investment of just a port sitting idle.

And in today's world with Tropo, I mean, it's all elastic. So whether you're dealing with one call at a time or you get tech crunched or Oprah mentions your product, you know, now you can handle millions of calls without doing anything differently. We've come a long way since Tappy. It seems like the standard today, I guess, is the SIP protocol. SIP, absolutely. So, I mean, everything we do with all of Voxel's products is open standard. So that's why we're big on open sourcing. We want to give back to the community, contribute. Everything we do supports SIP. And SIP stands for Session Initiation Protocol. And it's basically used interchangeably with voice over IP. It's the open standard of communicating with voice over IP. So with Tropo, when you create an application, we give you a SIP address that can ring right into your application. We give you as many phone numbers as you want, toll free or local, or we have phone numbers in 41 countries we can give you

at that point of your application. We also give you a Skype address that you can call with Skype for free into your application and an INUM number as well, which is bigger in Europe. And the cool thing about SIP is that everything with SIP, since it's open, all telephony carriers typically talk SIP, so it's easy to chain one app to another app to another app so that you can create a best-of-breed solution. So if you like this one voicemail system, you could transfer your call from Tropo to a different platform running SIP and vice versa. And what's interesting is with Phono, we're seeing lots of – we first were looking at this – I mean, we just wanted to build the solution to let developers put phones in their web browser without really thinking or knowing what they would actually end up building. And while we were kind of thinking it was going to be click-to-call, where a consumer calls a call center, we're seeing interesting use cases where Fortune 500 companies now are building Tropo apps,

and then what they're doing is when you say you want to talk to an agent, they can actually route that call to another country over SIP and then ring the call in the agent's web browser using Phono, and they're bypassing all the long-distance tolls for sending a call to another country. Quite powerful. Yeah, and with Phono, I mean, it's in their web browser, so they have a little screen pop that tells them information about the call,

and then the phone being in their browser, it just transfers the call to their headset. I mean, that is like next-generation call center technology, you know, quite a long ways from TAPI. So we're talking over Skype right now. I know we're recording locally so we can piece this together, but the quality is actually better than a phone call. What's the quality like on these SIP calls? Yeah, so Skype, they've got several advantages over a lot of other solutions. What we're talking with now is what a lot of people consider wide band. So it's able to use more of the frequency range than a typical like analog call so that's why you're able to get like a high def sounding audio stream and the other

interesting thing about skype is that it installs locally and they've got more controls or hooks into the operating system that it's installed on, so they can cancel echo change how the bandwidth, if you will, of that conversation. So there's a lot of advantages to being a locally installed application. There's disadvantages too. I mean Skype's got it in a good position because millions of customers already have it installed. When we set out to build Phono, our goal was to create a browser-based telephone that could receive and place calls without any downloads. So the goal was a headless application that with a click of a button, it's, you know, 95% of it's jQuery controlled. So you can listen to events, you can control the telephone, like touch tones, mute,

hang up, all the controls of a telephone with jQuery commands. And the beauty is that there's no download, it's immediate, and you're online. The downside to that is you have to work extra hard to control echo and latency and all the things that go along with HTTP. That's the challenge. So let's talk about the phono plug-in under the hood, the jQuery aspect of it. So are you dropping a Flash movie, I guess, or a Flash SWF file? Is that how you're pulling off the audio capture? Yep. So until HTML5 supports audio or mic and camera controls, which it will next year.

I mean, we have a guy on the W3C board working through that. Google's on the board. Everyone wants to see this happen. So until it happens, we really only had two options. We have Flash and we have Java, like Java Media Framework. So when I talked about 95% of the app being jQuery, the other 5% is the Flash control that you have to give permission to to control the microphone. What happens under the covers is we also have

an RTP stack that handles the media inside of Flash. And it uses a protocol called Jingle instead of SIP. And the and it uses a protocol called jingle instead of sip and the reason it uses google voice by the way uses jingle also so it's also an open standard kind of goes hand in hand with like xmpp and um what jingle does it's a lighter weight protocol that can transport over HTTP audio. But what we do is we have these phono gateway servers that sit on the edge of our network that all their job is is translating jingle to sip and sip back to jingle.

So what happens is when you drop that phono object into your browser and it loads, you actually get a sip-looking address. So it's sip colon, this big long address, like a typical sip phone, cell phone sip number. In reality, it's a JID. It's a Jabber ID, which is Jingle. So it looks like a SIP address, and when it talks to our gateway servers, that's where the translation happens from Jingle to SIP. So when your browser fires up, it dynamically gets a JID that looks like a SIP address. That is a real SIP address. I mean, you can receive phone calls that second from any soft phone in the world in your browser,

and it rings. So now that Google has introduced Google Talk directly into Gmail, has Voice over IP finally arrived to the mainstream? I think so. I think it's getting more and more popular. And I know we've seen a lot of excitement around people, what they're doing with Phono and connecting it to Tropo. And interesting thing about Google Voice is a long time ago, we all forgot about this, but I think when they launched Google Voice, there was also a native plugin that we all kind of downloaded. And in their talk, their new like Gtalk voice client, it leverages that native plugin to

also reduce echoes. So, I mean, it's a pretty good sounding effect, but you as a web developer, you can't really do anything with it. Whereas with Phono, it's entirely skinnable with CSS and you can control what it looks like and the source code's up on GitHub. So you can extend it and send us pull requests. So hopefully what we've done is we've created a platform that's totally free, by the way. I mean, if you want to do browser-to-browser calls and use it in your application, even sell your application,

it's 100% free to do so. It's licensed under the Apache 2 license. So be our guest to do whatever you want with it. But if you're going to extend it, we'd love to get some pull requests to build a community around it. But what we think that's doing is it's really empowering web developers to make it easier to get into the telephony space to start building really interesting apps.

And I'll give you an example of something. When we launched a jQuery conference, we didn't even hardly get to see the rest of the conference. We had people in the audience hacking on it, and we had to regroup, and we were doing support for everyone hacking. And one guy built another interesting use case that we never thought of. So what he did was he put this talk button on a web page, and the web page had like web forms on it. And he used our speech recognition and text-to-speech to basically have a dialogue with someone sitting in front of the web browser.

And based on their dialogue, he was transcripting what they said in certain instances and pre-popping or filling in forms for them on the screen. And it kind of really got me thinking that this is so much bigger than a telephone app. It almost blurred the lines in my mind of what you would think of a telephony application because what this was is it was almost like a two-way browser conversation with this intelligent bot, if you will, and it was controlling the browser you and and even typing for you in the form so i was like wow that that's pretty interesting uh paradigm of of what you know a tangent of where this stuff could be going you know transcription is an exciting technology sometimes things get

lost in transcription have you seen gb wtf the Google Voice WTF site? Yeah, yeah. So there's some funny transcription errors on there, you know, and I get those occasionally too. I'm a Google Voice user, so you get the, it's probably 80 or 90 percent accuracy. How does it stack up on your end compared to what we get from Google? You know, I think that ours is better. And I need to say, you know, just right up front, we didn't write our transcription technology. We partnered with a company that's been in business doing transcription for probably about 10 years, maybe eight. And it's really good, believe it or not.

I mean, when it's totally automated, you can also opt in for higher quality transcriptions but the automated ones i find to be even much better than google which is um interesting i think google should buy them so you know it's interesting to see where all this technology is going because you know even google kind of kind of wonder what they're up to because um you know they had the the goog 411 service where they recently canceled that service like just a couple of weeks ago and um a lot of people suspected that that we were actually that they were actually uh using all of us to test some speech recognition technology that they were putting together you know where we were using

it as a free service but really really helping them test their speech recognition. So who knows what they're up to. Unwitting beta testers, as it were, huh? Exactly. So what's the difference, I guess, the main difference between Tropo and Twilio? Well, Tropo's, you know, really powerful. When you look at things like our ability to do instant messaging in Twitter and even SMS under the same API, Twilio's got a different API for SMS versus voice. Ours is all a single API, which is powerful because you build your application once.

And no matter if someone calls that phone number or texts that number, it creates the dialogue with the user. So that's really powerful from an application developer perspective. We also do speech recognition. And we not only just do speech recognition, which they don't, but we do it in nine different languages. And even with our text-to-speech, very elegant-sounding text-to-speech, very robust, it too is in nine different languages. And even with our text-to-speech, very elegant sounding text-to-speech, very robust, it too is in nine different languages. And it supports male and female voices that are controllable in all nine languages. You know, we also have phone numbers, you know, like I mentioned

in 41 countries around the world. We've got SMS that we can do internationally, which Twilio doesn't do international SMS. And let's see. I think there's just lots of little subtle differences besides scale. So I think that's the biggest one is what we see when they do outbound like DAO campaigns, they typically throttle it at like

a call a second where we can do millions of calls at one time. We have emergency notification systems that rely on our platform of services. So like if something ever happens at a school, God forbid, no one would ever want something like that to happen. But when something does, that's a pretty serious situation. And some of our customers, I mean, they send out tens if not hundreds of thousands of simultaneous calls across Tropo to get that message out in a state of emergency. You know, that's a very real scenario now with things that happened at Virginia Tech, I guess, a couple of years ago. Now when there's an emergency, there's really only a couple of technologies that you can get the word out in that kind of scale and who checks their email every two minutes. Yep.

And I was talking to Bill Schreier, the CTO of Seattle, and I mean that was what he was just excited about is that Tropos pay as you go. So there's no contracts. There's no monthly or minimum commitments. In fact, if you're a developer, we give you total free access. We even give you phone numbers and don't even charge you for minutes or messages. So we've got 200,000 developers in the whole Voxeo development community. So across all of 10 years' worth of Voxeo developers in the whole Voxeo development community. So across all of 10 years worth of Voxeo developers in the community plus Tropo, 200,000 developers. And Bill Schreier at Seattle was thinking, wow, what an opportunity to create a citywide or Washington in general

or even national emergency response system on the Tropo platform because you don't pay anything for it in the good times. And in times of disaster, it just spins right up to whatever you need it to do. It's a great use case for that type of communication. Are most of the applications that you're seeing being built, are they standalone telephony applications or is telephony just an aspect to an overall web application? That's a good question. I see a lot of like complementary apps that complement existing websites where they'll just put a voice aspect or an SMS aspect into it. But on the other hand, I do see ground-up telephony applications where that's all they do.

They don't do any web screens that supports HTTP, I've seen a lot of them that – even Fortune 500 companies are building purely telephony applications. And I should point out one more interesting difference with Twilio is that we have – we both have a web API, RESTful web API that's really simple. Where we also, where we really shine is we have what I consider next generation APIs. It's what we call a scripting API. And like Google App Engine, where you can write applications like in Python or JRuby and push them to the Google Cloud, where they actually run on Google's platform. You can do the same with your telephony applications using our scripting API. So we support five languages. You write in Ruby is one of them, Ruby, Python, PHP, Groovy, and JavaScript.

You write an application in any of those five languages. You push it to our cloud, and it's basically on the metal of our voice cloud. So there's zero latency. All the back and forths that typically go with API, like AJAX requests, all of that's eliminated, and your script runs in our voice cloud along with all of our SIP ports.

Our SIP ports are just crazy density. I mean, 20,000 ports on a single server, multiply that times seven data centers. I mean, it's fascinating what you can do with like a scripting API that's that responsive that you don't have to pay to host it anywhere. It's free to host it on the Tropo cloud, and it's just there waiting for an emergency situation or your app as you need it. I hadn't realized how many languages were supported here. The scripting API environment is incredibly, incredibly powerful, yet incredibly dangerous, I think. Yeah, dangerous in the hands of a 12 year old that wants to do prank calls. This is like a dream. Exactly, man. Or imagine like the political, you know, we just had the

election, you know, and I don't know if you were like me, and you got hundreds of calls from political advisors. I mean, would be Obama's dream. Whoever is running for president of the United States, to be able to push that type of volume and even automate it is totally at the hands of a couple of lines of code. Mail merge to TropoExport. Yeah, basically it. So I know you're a Rubyist. You run Rubyology. Absolutely.

I've been doing Rails for about four years, and we joke about being Microsoft-free for four years. I love Ruby. I know you do too. Yeah, Ruby is one of my favorites. I do like me some JavaScript. You also support on the scripting environment PHP and Python. I know those are extremely popular.

Yep, and with Node.js, I think JavaScript is cool again. jQuery and Node.js, a lot of people are building Node libraries, running them on Tropo, and it's getting a lot of coming full circle again, like they say with fashion. Right, everything's cyclical. Hang around long enough, it's going to make another pass. So what's the difference between the Tropo scripting environment and the Tropo web API? So not much. I mean, the API itself is pretty typical.

So it's just how you interact with the method calls. So not much. I mean, the API itself is pretty typical. So it's just how you interact with the method calls. So you don't have all the back and forth JSON that necessarily everything's more self-contained in the scripting. I can tell you one thing. A lot of people maybe don't – you have to kind of put your head around, you know, the scripting API differently than you would a typical RESTful API. Because when everything's, and it's just like Google App Engine, when everything's running on someone else's cloud, kind of in their, on their platform in their environment, you lose certain things like, you know, being able to write to a local database or, you know, how what a developer might be accustomed to having at his disposal,

his or her disposal. And you have to look at things a little differently. So like in the scripting environment, if you need to do data IOs, if you simply write a web service going back to your application that can look up data for you or write data when you need to write it, you can call web services from the scripting API externally. So that makes it really powerful where you can,

when a phone rings, you can come to your web service and look up based on the caller ID or the number they dialed, you know, or what information you want to do about the call, and then proceed with handling it the way you want to handle it. So it's just a little bit differently, you know, you need to look at how you want to do things. And we're always looking at ways to improve that. So we're kind of playing around with some,

with adding, like, a fetch method to our API that make it, you know, even easier to get data or push data, but extremely powerful. I mean, I write a lot of telephony apps in Ruby, and probably 90% of them now I'm entirely writing in the scripting API. So you're a podcaster. Yeah, that's right. Here's what I want as a, as a podcaster.

And you tell me how, how many years I'm going to have to wait on this. So I would like to be able to have all the guests dial in over cheap telephony, right? Uh, record multi-channel so that we can duck out audio when someone sneezes or a chair creaks or something like that. Uh, get the same audio quality that I would get if I'm recording locally and not have to install any plugins to get it and not have to hassle the guests with any downloads. Well, you're pretty much there today. So like with Tropo, it's probably a 5- to 10-line application that can do all of it

but one I'm kind of thinking off the top of my head you can create an application that just doesn't answer when you call it if you use Skype or SIP to call it you're going to get that wide band high quality high def audio sound

you after you answer the call you drop everyone into a conference. And you also, there's a record, start recording method that you can record individual calls or the conference itself. And then you can also, after it's done, you can submit the recorded file, which is already in MP3, which you can use for your downloading. Then you can submit it also to our transcripting API. Asyncripting, when it's done, it'll place a callback to the URL you provide with all the dialogue of the transcription.

Basically, with less than 10 lines of code, you could do all of that. The only thing off the top of my head is I think the way it's designed now, you typically just get the recording of the whole conference, not the channel by channel. But I think you could probably still – I think if you record at the phone level before you put it in conference, you might be able to do that. We'd have to play with it.

Definitely. Give me something to hack on when I watch the Saints beat the Cowboys this Thursday. I'm a Saints fan too. Oh, are you? Yeah. Good deal. Go ahead. Yeah.

So just to say, less than 10 lines of code, now web developers can basically build applications like that that they see fit. And especially in a development environment, it's totally free. I'd say hack at it. Hack on. I'll definitely have to do that. So this is the part of the show where we kind of turn it upside down and talk to the guests about what's got them excited about open source. So in the world of telephony or really anything out there, what's got you excited in open source that you just can't wait to bang on? Well, you know, I've been eating my own dog food. So I've been looking for, like, consumer apps, like examples that, you know, can use phono, uh, in, in, uh,

in what we deliver. And, uh, so I, I, in a couple of days I built what's called Facebook telephone and we call it that because we unbelievably, luckily, I guess we're able to get the application name from Facebook telephone. So it's literally apps.facebook.com slash telephone. And it's, it's a browser browser or browser to telephone number application where you can call your friends on Facebook using phono. And that's all open sourced. It's, you know, kind of an example app. It's up on github.com slash phono slash Facebook telephone. And what's funny about that is I just submitted it to Facebook, and they approved it the next day for their gallery. And it already has over a couple of thousand registered users, and we never did any promotion about it.

It's very similar to another project I know you have called Twelophone that does this with Twitter. So what's your feedback, I guess, in doing the Facebook APIs and the Twitter APIs? Well, you know, I've been doing Twitter APIs for a long time. I mean, with like Michael Blythe, you know, Oauth. From Intrudia, right? Yeah. I mean, he makes things just so simple to do with Twitter. I've been playing a lot with Twitter apps.

Telephone I wrote like in about a day. And, yeah, I mean, it just does no auth. It lets you do browser-to-browser calls with your friends on Twitter. And if you enter your phone number in there when you set up your account, if you don't answer on your browser, it does elevate and place a call to your mobile device for free or your home phone or whatever you have. And Facebook, that was my first time really playing with the Open Graph API. So, man, much, much better improvement over what they used to have. So that one took two days to build just to kind of get my head around the way they did OAuth 2, which was a little different and kind of quirky even on how they respond.

And open source, Twelifone up on GitHub also. So, I mean, I really enjoyed the Facebook one because it was a little bit more of a challenge. And the interesting factor, I think, is the viral factor. Facebook seems to be more viral in the way it spreads than what we've seen with Twelifone. Yeah, and maybe there's a more natural fit there in Facebook where people are connecting and messaging more than Twitter. It seems to be more of a broadcast medium. I know that's how I use each of those. Exactly.

Well, thanks, Chris, for joining us. Definitely putting the development in business development. Cool. Well, you know, when I really appreciate it, I love what you guys are doing on the change log and I'm, I'm honored to be on your show. So thank you so much. And, you know,

thanks for helping us get the word out about our products. And, you know, we love the Ruby community. We love really all the development communities. I think that speaks for all the, the various languages we support on scripting as well as the web APIs of our solutions and the open source we contribute on GitHub. So we'd love to hear what people are working on,

especially if it involves anything telephony related, especially a Tropo or Phono application or Teleku for that matter. So thank you very much, Wynn. We really appreciate your help in getting our word out. Definitely. We'll be sure and put all this in the show notes. Cool. Thank you.

Thank you. See you next time. For the first time, safe in your arms as a dark passion shines.