 What's up? I'm Jason Ostrom. Can you guys hear me back there? Cool. This is Bill Borske. Hello. We flew in yesterday from Dallas and unfortunately our third speaker Carl Finehauer couldn't make it today. So first of all I want to thank all the friends and peers of myself and Bill for being here in the room. I really appreciate it. We appreciate it. This is a really, really special talk to us. We're really passionate about this stuff. Let me give you guys kind of an idea of what we're going to talk about here. Islands of Voip is something I could talk about for two hours. It's something that really excites me. So what we're going to do is we're going to talk we're going to at a hacker conference you would want to see like a live hacking demo. So we didn't bring that. But we have some surprise UC vendor research that's a major manufacturer that we're going to take a look at some potential vulnerabilities. And that's a surprise. If you guys stick around a little bit, Bill's going to show some technical details on that. And I'm going to talk to you guys about something that's really important to me. And what I want this to be is an exploration of an idea. And I think it could change the way we communicate in the future. And I want you guys to be a part of that. And I'm going to give this away to the community because it's something that you guys could be involved in. So this is a community effort and we're releasing two open source tools in addition to the vendor research and a configuration for something special. So let's go ahead and jump into this. First of all, a small little disclaimer here. This doesn't necessarily represent the opinion of our employer. And just because we stand up here doesn't make what we say exactly right always challenge what's being said. We're here to explore an idea. And the idea could be disruptive to the traditional business of incumbents to the status quo. So what is Viper? Viper stands for voice over IP exploit research. Two main missions we have. We do VoIP UC pen testing and we have a security research lab that we look at vulnerabilities in VoIP and UC. Okay, so islands of VoIP. What am I talking about here with islands of VoIP? What I've done here is I've kind of shown an architecture drawing of this idea that I've come up with. Islands of VoIP has been something that a lot of people talk about. And what it means is I started doing this pen testing really with SIP like in 2008. And I've wanted to present this for like a long time. If you look at enterprise A, what was going on in the mid-2000s is lots of companies were using VoIP internally on their network and reaping a lot of business benefits from using VoIP. But they weren't actually using SIP trunks. They were doing, they would have a VoIP gateway that would translate from IP to TDM and would use like a PRI trunk and they were going through the carrier. So the idea islands of VoIP, what this means is we have many different disconnected separate VoIP networks where enterprises and organizations are using VoIP, but they're not connected together. They're not reaping the major benefits of VoIP. And so they actually all end up going through the PSTN and you end up paying costs going through the PSTN. So that was enterprise A was the first one. And then what we're seeing more and more here in like the late 2000s is companies doing SIP trunking. And so the predominant architecture for this that I see a lot and we do a lot of these VoIP pen tests, we go into the internal enterprise of the customer. We'll either have enterprise B and enterprise C doing a private IP MPLS network connected to a large carrier doing SIP trunking. And what's so ironic is that these two enterprises are they could be connecting directly to each other with VoIP yet they have to go through the carrier and pay the carrier for the cost. So what's ironic is that you don't do this with email in your HTTP traffic, right? You advertise yourself in DNS why should we be doing this with VoIP? It's something to kind of think about. Why do you have to go through your carrier to do your voice communications? Here's another representation of the islands of VoIP idea. So one thing that people are talking about with connecting the islands of VoIP is using Enum. And Enum is basically a special resource record where we map e.164 telephony numbers to a SIP URI. And so it solves the problem of interconnecting the islands of VoIP because you can look up the number and you can go over two different SIP networks can connect to each other directly by dialing by number. So that fits when you're still thinking in the terms of dialing by number. One of the issues with Enum is it hasn't seen widespread adoption and there's political economic barriers to this because the carriers, it requires the consensus of too many competing carriers on this. So we did an Enum experiment and this is actually how this all started with Enum. What we did is we wanted to look at the privacy considerations for publishing ourselves into Enum into the directory. So we took some numbers and started putting ourselves in and we found we couldn't add ourselves into this. This is the e.164 org directory. So it kind of was just seeming like I wanted to do this experiment with a registrar in the UK called Nominet and I wanted to basically create a tool that could do an Enum lookup on every single number in the UK and see if there were privacy considerations where I could actually connect to that point SIP device just by having a range of telephone numbers. So that was kind of how this whole thing started with this Enum. So there's got to be a better way and so there's got to be a better way of doing this and this is what we're, Enum hasn't proven itself to work because of these too many barriers. So the superior solution SIP peering using DNS SRV. If you've read this abstract everything that we're talking about here is in this abstract. We're just going to be filling in some details. So we dial by name and SIP address we peer directly using SIP DNS SRV routing. So this is how it works here. We can interconnect all the islands of VoIP directly using DNS. DNS is built for high availability and load balancing. It's already supported. It's a resilient protocol that's lasted for a very long time. So we can call via your SIP URI call via your SIP your email address. So not calling by your number and no more dialing by number and it's easier to remember and it matches your email address and your SIP URI. There's a large cost savings of direct SIP peering using this method and not having to pay your PSTN carrier and then the PSTN will be increasingly diminished. So the special DNS SRV records RFC 2782, RFC 263 specifies this usage for SIP. And so SRV service location, it has already built for fault tolerance and load balancing. This is a sample record here. So we have service protocol and name which is the DNS domain and the service returns the priority weight, port and target. So what we can do here, here's a sample zone file record. When we have all 10 for the priority, then we match it up with the load balancing group. So then you add up the numbers 60, 20, 10 and 10 and so 60% of the traffic will go to big box, 20% to small box. So we have automatic and it's just like MX records for mail transfer agents for matching. It works the exact same way. So why aren't more people doing this? We started thinking of this like why are all these companies directly connecting to the carriers and not doing this method. So here's a, let's look at a sample architecture for this. So Jason is connected on example.com and his SIP service with his enterprise is connected on the edge of his network. So he sends a SIP invite and the DNS SRV look up for food.com. So he wants to call bills organization and then the record returns. So then he routes the traffic directly to bills organization and the invite comes in via the AOR, the address of record for bills SIP user agent, knows the IP address with his registered user agent and routes the call directly to him. So we have a fault tolerant high availability method of routing SIP traffic, bypassing the PSTN, which can be managed by each organization. The important thing, it brings the power back to the organization, back to the enterprise and not having to go through, rely on the carrier for this. Then the carrier, you can use the carrier more for the network transport. So then Voight becomes another application on the network, just like email and HTTP and this is the way it was meant to be, in my opinion. And so then we, we set up the, we answer the SIP invite and then we have RTP media directly between the SIP servers anchoring the media. So we started looking at this as a research goal. We want to measure the growth of SIP on the internet over a period of time. So the first idea is, Bill and I were out in, we were out in another country doing a Voight pen test for four weeks so we ran out of time to do everything we wanted to do. But we want to look at the DNS SRV plotted over time, how it increases. We wanted to look at the proliferation of enum records on the public internet and then we wanted to do scan the internet for the number of listening SIP services. So I'm releasing a new tool that I had the idea to do like a long time ago. I finally released it and it's on the website right now on Sourceforge. It's enumerator.sourceforge.net What is enumerator? Enumerator, it's written in C. I'm the author, Carl, the other guy that's not here, helped out with it and it can be used for R&D purposes like we did. It can also be used for Voight pen testing in the recon phase. We've wrote some special features that can look for organizations for the existence of SIP services. It's optimized for Voight. The DNS SRV lookups can be for a single domain or for a text input list. It also supports MX record lookups because we wanted to compare SRV to MX and plot this over time and see how SRV was catching up with MX records as far as the, for all top level domains. So that was a part of the experiment and we support ENU in enumerator and that was one of the things that we were initially looking at. So what did I do here? What did we do with the research? We had to get special permission from network solutions in ORG to get all the top level domains for COM, NET and ORG and we wanted to find the number of SRV enabled. So we collected this data here about five gig, 292 million domains and so we had to do some benchmarking to figure this out. Once enumerator was coded, we basically split up, we decided to split this up into 11 different servers and then we benchmarked this to basically split enumerator into 800 separate processes and to parse a single large log file into 800 chunks and so each of the 800 enumerator processes would basically do its workload in parallel on the host. And so we benchmarked this at 140 domain queries per second was the fastest we could get this and four SRV queries per domain and I'm going to tell you what those queries are. It's those queries right there. This is the most standard way to host an SRV record. The last one is Microsoft specific for federation. So here's the results. 3.30% of domains on the public internet, COM, NET and ORG support SRV. So it was 8.7 million domains and those are the states. That's the what it looks like there. So enumerator in action, let's take a look at just a couple of screenshots here because we have a domain, the DNS SRV look up for a single domain and it returned the records there, the targets. And then when we can do the input domain list right there and the MX records as well and here's what it looks like for the input list. So if you have a large file, it'll just start querying through and that's what it looks like until it gets to the end at 100% and then it displays all the statistics. So here's what the enum support looks like. Minus E minus R, you can look up a range of numbers. So we didn't get to the point where we were going to scan. We were looking at all the North American numbers or all the numbers in the UK. So here's a single number. So this is what the enum looks like. It looks up the number and it finds it of that SIP URI right there, enum-test at sip.nemox.net. So here's another view of doing a range of addresses and you know it calculates some statistics at the end of its little enum scan. So I've already released this like I said and the tool, you can go into SRV.C and these are the lines right here. If you want to modify the code and add your own SRV look ups enumerator can measure the usage of UC federation services or SIP enable DNS on the public internet. So we're giving this away as a research tool and as we do more, find more SRV record types we can add this into enumerator. So now we're taking a transition into UC federation. Naturally as our research we were looking at public SIP DNS SRV peering we started hearing about this term UC federation. What is it? It basically allows business to business communication and collaboration the same way between organizations that you do it within your organization. So HD voice and video between different domains, collaboration tools like white boarding, desktop, application sharing between companies. It's the next killer app with UC that everyone's talking about. You can go out and google UC federation and this is what we started looking at and this is the next thing we're going to talk about. It does promise many business benefits and so we looked at two vendors initially. We looked at Cisco and Microsoft. I love Cisco. We have friends in the room here with Cisco. The Cisco solution uses the PSTN initially to do the federation connection and it builds like a hash of the two users and then after that they can use TCPIP. We wanted to focus more on for a couple reasons on the Microsoft because we like the way Microsoft does the UC federation. So surprise, Microsoft is the surprise vendor that we ended up doing research on and it looks like their solution is really taking off so we're really interested in it. What's going on here in the industry? If you look at this guy here, Matt Landis, he's published a public federation directory and so what they're doing, they want to create education and awareness around with other link users, with other Microsoft UC users to let other people know who's doing federation. So he published this directory and we actually with Carl and Bill and myself, we set up our own like Microsoft UC Honeypot. We built our own installation of Microsoft link which is the solution we're going to talk about. We published our, we got a root CA domain, we purchased a domain and we published ourselves into this directory. We tried putting ourselves into this directory but this guy wouldn't allow it. So he didn't publish us into the directory because we wanted to study and see like what would happen. Now this is really interesting because you can download his spreadsheet and you can go download it and you can see the top three countries are Canada, USA, and Norway and with 9,700 domains. So this directory is a second directory that we found. It's linkdirectory.com. It's a public directory. You can go look at that. We're able to add our test UC federation deployment in this directory. They granted us into this. I think we had something to do with the certificate that we initially had. We went out and purchased a real certificate and we advertised ourselves the right way. So we went back, we'd probably get into that other directory. But it is really interesting because there's more and more awareness about this federation. You can go out and look this up and companies are trying to communicate to each other using this peering, using DNS SRV. It's opening up a lot of business opportunities but it also introduces risk in the environment because you have the balance between security and usability. I'm going to hand this over to Bill. He's going to talk a little bit about the specifics of the Microsoft solution. This is a really high level overview of how link architecture looks. You have edge servers and that's how people connect through the public internet. And behind that you have the link front end servers for internal users. The front end servers really just negotiate authentication for the back end. And it still works the same way with DNS SRV lookups. So Gilgamesh can call, I didn't write these names, these are kind of ridiculous. Gilgamesh can call Marco Relius at his organization. And just like he said before, he just looks up the record and then the IP address for the other link company using link comes up and then they can talk. But what's different is there's a TLS tunnel between the two edge servers and it's pretty secure. The way they set it up, if you want to add anything to that. You have to go out, you have to buy a real certificate. When they negotiate a TLS handshake, if you have a certificate that doesn't match your domain, the connection gets rejected. We did a lot of research on this. We did a four week long security assessment for a customer that had this solution. So we were testing in our lab and we were actually testing against the customer. So we found all this stuff about the way this works. And also if you talk about the white listing, two edge services, they have public IP addresses and you can look them up with DNS SRV so you can find any one of these companies using this. And so these ports are open on the internet so this is an exposure point and it introduces risk where in the future you're hacking web servers and email servers. You can hack UC servers now on the public internet. So there are different types of federation. There's dynamic which just uses SRV discovery and that means anybody can connect to your infrastructure if they have a valid domain and a CA. They can connect and send your, they can enumerate users, they can send anybody messages which can be obviously dangerous. The next level would be the black list which you just put in there, a black list of servers that you don't want to be able to contact your federation. And then the best way to do it is a white list that has a list that just has trusted partners that you want to federate with. We started working with the dynamic setup because it's the easiest to attack. So that's what this shows here. So my co-worker Carl, he worked in C-Sharp to develop this code to make a custom link client so we could send our own messages through. And he worked for a few weeks on this and he used the official Microsoft documentation, but almost everything in the documentation was wrong. Yeah, everything from how they did NTLM authentication to everything. And he just used the logging engine on the link server and just kept sending messages and sending messages and he finally got it working. And we started sending and we looked and it just sends HTML over a special SIP message packet and that's how you do IM and we started looking into it and it looked like we could get something done, some people release something before we got a chance to get that deep into it, but the safe HTML issue that was Microsoft made a patch for just recently. We were getting right there, but we had to leave and we didn't really get much done, but it was a long process getting this working. And here's what this code is. This is actually how you send a message. It's a standard SIP message except for you have to do TLS negotiation and then you have to use, if you want to be an authenticated user, like we said before, you don't actually have to be authenticated on someone's domain to send people messages, but you have to negotiate TLS and then you have to authenticate with NTLM but a weird NTLM and this is essentially how you build a message, it's just a string and then you send it over. So, he made two tools out of working with this and one is called Link Spoof and the other is Federator. Link Spoof allows you to just act as a legitimate link client and send messages, but you can modify the messages and you can modify the fields, which can be pretty handy in this field. And Federator acts as a federated link client and you can connect to someone's federated infrastructure and do things like enumerate users or send high rates of messages to lock up link clients. So, we'll show you a couple videos here of both these tools going. Okay, video one first. So this is the Federator tool. I'm going to start it right now. Okay, so I don't know if you guys can see this, but you enter your local domain, it has to be a real domain, and then the domain name is the link server and he's opening up a word list for users. So, this is a user enumeration attack. So, on the internet you can use this tool when SRV discovery and you can basically enumerate all the target users in Active Directory on a UC hosted customer. So, open the file and this is going to send SIP invites and the differential response from the invite packets will tell you if a user exists or not. And this can be kind of damaging because as I said before, these are used in TLM authentication so these are likely domain accounts. So, from if you have open federation someone can just enumerate a list of user names. And if they use the other part of the link client then they can do a word list attack against the authenticators on those user names that were discovered. Yeah, so that federator was for when dynamic SRV discovery is enabled, that federation type. And anyone can do this in attacker. So, there's a, while it's good for like discovery, it's not so good for security. Here's video two. This is federator again. This is just a different attack. Yeah. So, he's doing an IM message. He's basically doing a spoofed IM message. So, you see that everything that's sent over is just in div boxes and they have, you have the ability of controlling the style inside the div. So, you can do things, you can still do things like CSS expressions and whatnot. So, here's sending just an href. And so, this could be kind of damaging if you make a domain that sort of looks similar to a trusted domain and send someone a link, click it. It's just a social vector really. Yeah. So, it's like a targeted VoIP spear phishing attack is what it is. When you have SRV dynamic enabled, you could federate to that. You do a malicious federation connection. You can put a fake link and the link client on the customer end doesn't sanitize the HTML. So, if you, so you could actually trick them into clicking on a link that could be like a spear phishing attack. Correct? All right. That's exactly it. Video 3. This is the link spoof where he, Carl did basically a malicious link connection and he basically reverses near the NT Landman authentication. So, this is the code. There's no real interface for this. And right now he's doing a flooding attack by sending a high rate of sip messages. And over here, you can see that the client is just locked up because by default and we asked Microsoft about this and they said that there are ways to sort of prevent this, but there's no real way to do it. You actually have to write code on the link server to make it rate limit the messages, but the UI of the link client is just completely hosed. Completely crashed. You can't, you have to go to the process manager and kill the process because it's done for it. So, that's a real vulnerability with a malicious link client and what it is is you have to be authenticated user. So, you're one, you have to have someone's credentials. You connect as that user, but that user can target all the other users and do a targeted DOS via the attack you just saw. That is a real vulnerability. And so, Microsoft, you know, their response was you, well, you can create a filter on the server to rate limit the traffic and that was basically their response is you can do security best practice, but by default, that is not enabled on the server. So, every link deployment is vulnerable to that issue. Yeah, and it's also not just an option. You have to write your filter and install it on the link server. Okay, let's get back to the slides. Thank you, Bill. So, we're doing good. So, here's what we're looking at on the SRV discovery stuff that I told you about with that enumerator tool. We kind of looked at what's really cool about, I really like this Microsoft link client. This is what it looks like. You have automatic configuration or you have manual configuration. This is the UI. With manual configuration, I can put in my different SIP servers if I want a different one, my internal versus external. And then automatic uses DNS SRV. So, basically link is like hard coded to look up certain SRV records, right? When you use your email client, normally you have to like put in the actual, you know, pop or mail or whatever. But what's interesting is you can kind of take advantage of this from a DNS attack surface for any customer. And so the enumerator tool could actually look at all the domains that support the Microsoft version of SRV discovery. See like SIP internal TLS and .domain.com. So, I haven't added support yet for enumerator for this, but we could actually have a special project where we could scan all the domains just for Microsoft enabled U.C. Federation. These are the two special records. And then this is another one that shows for like the Office 65, the hosted version of Federation, which you can do with link. That's the, these are some of the records. So, you could create like a tool that scan for like the CNAME records that resolves to Microsoft's online service. This is like their online hosted U.C. Federation in the cloud for link. So, we didn't touch this stuff, right? I mean we're not going to do any type of research or attacks against Microsoft's public web service, but you know you have that Office 65, that hosted U.C. solution. These are the actual servers that they use for this, for hosted customers, right? So, people need to start thinking about this, because as U.C. Federation takes off, all these customers, you know, for a recon perspective, they have to be locked down because these domains are like wide open as far as finding certain domains to attack and companies to attack. So, it's always the balance between discovery versus privacy. While it's easier to, when you turn on this Federation, it's easy to be discovered, but it's also easier to get attacked. Now, let's look at U.C. Federation technically. You know, we do have this Cisco way of doing it, but from a Microsoft U.C. Federation perspective, what it means is SIP signaling and control plane, SIP for signaling, RTP for apps requiring real-time communication, and then DNS SRV for service discovery. So, in the future you could have new records that you create to use for new U.C. communications and applications. Microsoft appears to be the market leader in this U.C. Federation. They have a strong default security with SIP TLS and SRTP. In our research, it was very difficult to peek into the encrypted SIP TLS messages, because the first thing we want to do is we wanted to we wanted to actually, you know, look at the SIP messages and we couldn't see them. So, Carl, you know, reverse engineered this, just using the link server logging tool on his own, but after the fact we started saying, well, we should be able to decrypt this. And so we started looking into this and we like to understand, we want to see these messages. So we wrote a SIP TLS proxy tool and we're able to peek into the messages. And so we're releasing this to the community. We're releasing this to the community objective one. Thank you. Objective one was decrypt the SIP TLS message flow and learn how it works. That's complete. That's up on the numerator source forge website. You can go to numerator.sourceforge.net. Now we want to have a fuzzing engine is what we're working on where we can freeze the message, modifying it using a UI, re-sign it and send it to the server and see what type of fun stuff we can get into. So here's a screenshot from the Python. This is kind of what it looks like. That's the actual Python script right there, threadpy. And message me if you'd like to know details on how it works. It's not too complicated at all. But what you have to do with your Microsoft link client is you have to trick it into connecting to your proxy instead of the legitimate server. And how you do that is you modify your Etsy host record on your Microsoft windows and whatever the automatic discovery is set to, the SIP server, you just change it to be your proxy server and then save it and it'll automatically connect to your proxy server. And that's what it looks like when it's gotten a 200 okay and authenticated. That's compressed data in the SIP message. So we need to figure out also how we can read some of that compressed data. So here's what the I kind of explain how it works. The proxy decrypser traffic, we can inspect the traffic in clear text and then it negotiates a TLS handshake to the remote server, the legitimate server, and it encapsulates that in TLS. It uses the Python TLS module. I had the idea to do this. I worked on the networking code. I got the initial connection working. Then I had to go to Paris to do this pen test for four weeks. And so there was another engineer in Viper that finished this. So we're going to give him a big thanks for finishing this code. But here's the first message. It's basically a negotiate and it's negotiating the compression of LZZ7 8K. It's the only value that can be used. And so we can play with actually turning off that negotiation or that compression algorithm so that we can actually see the message once we get the 200 okay. So the Microsoft Edge server inspects the compression header, matches it, and then responds with 200 okay that it will support the compression. Then the third message out of the eight is the first register message sent by the link client. And so this is always a part of the application flow. So this is NT Landman authentication in SIP. So if you're familiar with NT Landman with HTTP, this is the same thing in SIP. You see the WW Authenticate headers. It supports TLS DSK and NT Landman. The TLS DSK is like a certificate that gets stored on the client. And it's actually really, really interesting. We encountered that on the pen test. And then that 401. So then the link client sends a second register with the authorization header in NT Landman. So that is the authorization. I see it there. Somewhere there. Yeah. There it is. Authorization in NT Landman. Then the server responds with 401 unauthorized with actually the challenge with the GSAPI data. And you see it there in the WW Authenticate NT Landman there and the data right there. So then the client, the link client just uses that data to create the proxy authorization header with NT Landman. And the data section there is actually a Base64 encoded NTLM packet. Cool. So then we get the message number eight, the 200 OK. And there we go. We've seen the whole flow. It's pretty cool. We get the 200 OK at the top. You can see SIP 200 OK. Message from the read from the server and sending to client. And then the rest of that is the compressed data. So we can play around with turning off the compression so that we can see the SIP message and then we can eventually start doing some fuzzing attacks. And this is a work in progress. This is the first phase. I'm excited to show this to you guys because I think that we're the first ones that are really looking into this and trying to give away this research to the community. So hopefully other people can pick this up. Everyone can start looking at this because it's pretty cool and exciting. I think this is going to change the way we communicate. Many thanks to Anil Mahali. So Anil is the Viper Researcher that finished this code. And this is our goal of building education awareness. And it's on enumerator.sourceforge.net. No. That is not an ad for OKCupid. That actually is a ViperLab Researcher. It's not eHarmony either. It's speaking of thanks. I also wanted to thank Carl. Carl's an awesome dude. He couldn't make it here like I said. He's a Windows developer and he actually picked up Linux really fast as well. He reverse engineered the SIP messaging of Link. He authored Link Spoof and Federator. The guy is somewhat of a mystery. I can't tell you a lot about him other than he's a pretty smart guy. But we were able to capture a secret picture of him. And here he is. That actually looks like one of his shirts. So perfect timing, man. Two minutes ahead of time. So you take it over. Alright. So as many of you know, there's a panel discussion every year about how DefCon groups can stay in touch. I think this would be a good way to do this using open source, UC Federation, using asterisk, and mobile phone applications. I was pretty surprised when I came here and saw these Ninja tell guys who pretty much did this, but just for DefCon. What the benefit of it is, it's out of band, so you control the end points, you control the media, and it goes over the internet, but I mean what doesn't go over the internet. So it can be used for audio, video, and instant messaging, and you can save money by instead of using your cell phone minutes to call out of country numbers. It just goes over the internet instead. And all the software is open source. Asterisk is a little buggy sometimes, but it's free. This is kind of the architecture. It's similar to Link, only you don't have the front end and back end servers. So you would have a guy in America called a guy in Amsterdam. It would just look up SRV record and place the call. The media would be anchored between the servers and you could have soft phones or hard phones or just soft phones on a cell phone. And it would just use your data plan. You can enable SIP TLS and SRTP for privacy, and then you have a whole kind of dark net group of voice communications that's out of the side of the realm of the PSTN. So it could be pretty useful to people. Asterisk Federation works pretty much the same way as the Link Federation. Again, it's not as complex though. You just put in the config to enable SRV lookups and when you're on your network you call somebody on another network, you just use the SIP URI like their name at domain.com and the server figures out the address of the other server and negotiates the call. There's no need for the PSTN. The SIP Trunks do all the work and that means no long distance fees, no international calling fees. So it's good. We have an open source federation project. We have them running on line nodes so we can bring them up or down in an IP range of any country we want at any time. And we set up fake companies with websites and they all have SIP servers tied to them, email servers and all. I'm not going to tell you what they are because we don't want people attacking them. This is part of our research and we can call one another using our cell phones and it works very well and I think it would be a good way for people here to stay in touch with one another. If you want to check out our configuration files you can go to the same SourceForge website we showed you before for the enumerator tool and we have some redacted copies of our federated asterisk configs. I'll take over here, thanks Bill. So as Bill said we wanted to basically look, we started taking our smart phones on iPhone and Android and we registered them using a SIP user agent on our phones, our smart phones to our line nodes, to our UC federation, our SIP servers. And we did a bunch of benchmarking tests and it was funny because everyone talks about IPQOS. We had really good quality of service on Wi-Fi or 3G, 4G actually. We could do calls all the time and we were using it to communicate with each other and anyone can do this right now. You can go out and do this right now and this is what we're tying in here on this conclusion. Let's take a look at this. A lot of people, Asterisk is a popular vendor, it's an open source IPPBX and that's the way it's advertised. But in reality we kind of changed this when we started looking at our research. If you move the PBX on your Asterisk server from the internal network, which is what a lot of companies do because they use it for voicemail and get all the advantages of UC, if you take that Asterisk server and put a public IP address and move it on the edge of your network to move it outside your network, it can do something what's called RTP media anchoring. So what it becomes is it becomes a B2B UA, a back to back user agent. So all your Asterisk user agents register to Asterisk. Asterisk will terminate the connection with the media and re-initiate to a remote peer, another Asterisk server. So it's what's called a poor man's SBC. It's a back to back user agent. So since we're vendor agnostic, Viper, we're only talking about open source solutions for this SBC. There are other solutions out there. But that's the way this works. And so Asterisk could function for your organization for $20 a month. You could use a line node and you could host your own VoIP for your organization, exactly like what we did. You can have all your desktop phones be SIP on your internal network, register to your SBC, and you can peer with other companies. You can also use your smartphone using DNS SRV to register to your SIP server and place calls to other people on their smartphones. Why aren't more people doing this? You can all use it with DNS. It's the way it was meant to be, right? So peer directly to other organizations. There's huge cost savings here, right? You don't have to pay your carrier. You don't connect to the PSTN. And now another thing here, you can still connect to the PSTN while you do this, right? So for the people that you want to talk to, DNS, you use your email address, you peer to them, you still keep your SIP tron connection. So you still connect to the PSTN. It's just whenever you want to dial by number, you go out your SIP tron to the PSTN with your carrier. Whenever you want to communicate with everyone else, you use the DNS. So you can, it doesn't go away, it doesn't have to go away. One more thing, this is pretty cool, linode.com, we found these guys. Gotcha. So create your own UC Federation and SIP DNS SRV peering service. We're giving this idea away to you guys. Go out and make some money. Go out and start playing around with linode.com and asterisk. Create your own new product or service. Create a hosted DNS SRV service in the UC cloud. See, more and more people can do this UC cloud service and then there could be peering out on the internet here and all we have to really handle is this IPQS problem. So carriers, the existing telcos, I mean I have a network engineering background. The telcos, you know, I mean there's a lot of incumbents, there's a lot of companies that will be threatened by the status quo with this business model, but you know I believe everyone can adapt to this. It's just that you'll be buying IPQS. The carriers in the future, mobile carriers or wired networks will become, will start selling IPQS networks. So they'll start selling IPQS for Federation, for SIP DNS to make sure that there's acceptable quality of service for video and VoIP and any data collaboration tools. And if you look at this, if you really look at this with the mobile carriers and the smartphones that's where this is really interesting too because with my smartphone, you know, we started calling all the carriers and we kind of researched this a little bit everyone in the US, it appears that you can't buy a date only plan on a smartphone. On a tablet you can, but not on your smartphone. Why is this? I was talking to some people and some insiders and I almost got the answer on this. I'm really curious, I mean to me it's some kind of regulatory issue, it's an issue that's hidden that we don't know about, but you know if I have to pay for voice, I mean that's why no one really wants to, there's no driver or incentive to go out and get VoIP on my smartphone unless I'm traveling internationally and use Skype, there's no incentive because I'm already paying for voice in the US. If I already have to pay my carrier for voice minutes in the US, why am I going to even be compelled to like set up a SIP user agent, you know, CounterPath Bria on my smartphone? There's less incentive unless they start unlocking this so we can buy data only plans on our phone. Then we can use VoIP as an app like we use everything else and then we can have presence. I see two killer apps right now for this. I see voice with DNS SRV and I see presence on smartphones. Video is probably, you're probably not going to use video as much on your smartphone. Data collaboration is not going to work as well on tablets like on the iPad. Data collaboration is really cool, right? But just voice and presence will be really cool between organizations for free, hosted by your organization. Take the power back into your organization. That's the way I think this stuff is meant to be. So we're giving away these ideas. Again IPQS for real time communications, GSM on cell networks. That's where you're going to run into problems and you know the carriers, they dominate the network so they can, if they figure out you're running VoIP, I'm not sure how that works. I'm not an expert in that area. But there's been rumblings of this. There was an article just a few weeks ago, AT&T hints of data only wireless plans on smartphones. So this stuff is about to happen. I mean there's a lot of disruptive things that are about to happen in this area and we live in a very exciting time. No matter what, even if I'm not right, like this stuff is about to happen, it is very interesting and this stuff is really changing right now. I don't know if you guys have heard of this Project Fish Goal. This is freaking cool stuff. All the stuff we're talking about, the NSA did a secure mobility package and basically is what we're talking about within one company using security. So they had two layers of security. There's IPsec, IPsec Android built into the SIP user agent on smartphones and then there's SIP TLS SRTP. So they're creating a whole architecture recommendation. But how can we do this with security between companies is what combined this with between companies, and this is exactly what Bill mentioned, the ninja telephone that he got, they have their own cell tower and they're kind of doing that security within the organization with their own cell tower. Last thing, last point here, WebRTC could be completely disrupted to this. HTML5 and JavaScript natively and Web browsers, take a look at WebRTC, this stuff could disrupt all of the SIP stuff. And then last, I don't know if you guys have heard of Metcalf's Law, but that's what I'm really talking to you guys about today. Metcalf's Law says the more people using a telecom network, the more valuable it becomes. Since everyone's using the PSTN, it gives a lot of power over VoIP. If you started using VoIP, the more it becomes, more people on it with DNS SRTP becomes more valuable to everyone. And that's the end of our talk. And I thank you for coming. You can reach out to Bill and I, Carl as well. A copy of this presentation is on the SourceForge site.