 So I'm really happy to be here. I've been doing voice-over IP software, open-source voice-over IP software for a really long time. But for me it feels really long time. And mostly I've been doing technology, like working on the big-stress media server and working on the technology itself. But today I want to present something different, which is an application. A couple of technologies, a couple of open-source technologies to one project, which is really interesting. And I think it should be really interesting to people here for two reasons. One is that the organization that I've had the chance to work with are really doing really, really cool things. And the other thing is that it's also a really interesting application of technology, which should be even useful or interesting to many people who are building voice-over IP networks. As I said, the organization I was able to work with is Resomatica on the left, CESA, Altamundi and TICRC. What is Resomatica? As an organization we have a representative here who can get into touch with Keith. They support communities who need or want to build and maintain self-government and self-on-telecommunications infrastructure. So they help people to come together and build their own phone network, like GSM, real GSM phone network. As you can see here, that's an antenna in the village. And so they are really putting up, or they're helping communities to put up phone masts. And in this beautiful atmosphere here, that's in near Oaxaca, in the south of Mexico. And this is communities where they are currently running these open-source telephone networks. Here is a bit zoomed in, east of Oaxaca and why is there many? You see here the reason. This is a map of the mobile phone mast beta assist in the area. And you see that here in these mountains, there's almost none. There's very, very few, so people don't have coverage. No commercial operator just goes there because commercial operators are driven by money and there's not so much money to be made. So a different way is that people come together and build their own community networks as alternative to the established commercial ones. And so beautiful can look like. Another partner in this project is Seisel. They are more research and development company and they have been operating a phone network in Pearl Lagoon in the south of Nicaragua or in the east actually of Nicaragua on the Caribbean coast. So how do these communities connect to the cellular networks? How do they connect to the PSTN? Because if you have these communities, the cellular networks in a village, they can freely talk to each other. But then, and they can also independently of an internet uplink, they can talk to each other. But then if they want to call their relatives or friends in the city or the people in the city want to call them, then you need some interconnectivity to the PSTN. And if you buy DRDs, phone numbers for everyone, then it's really expensive. Everyone has to pay two dollars or one dollar per month for the phone number only. And so how does it work normally? You have an uplink to a data center. You have a zip trunk and usually you have one inbound access number. And if someone wants to call, they call this access number and then they enter the extension in an IVR and then only then they connect. And they have to pay for this inbound, to make a call outbound. And SMS isn't possible because they don't have SMS number and there's no SMS peering. So as people in the city have internet, or if they have internet, the goal would be to connect directly. To connect, we can use the internet. The data center is already in the internet, so we can connect directly from the cellular network to the users. And I was thinking I can just simply show the app here. So this is the result. It's an update runs on the mobile and on the laptop as well. Here I can see my number. And if we are lucky, it's a little bit dangerous demo now, but just for the fun of it, I type in my number. Maybe because it's a, yeah. So calling here now established and might even have an echo. So after the call, here's a, how is the call? It's really excellent. I have a comment. Oops. For us then, yeah. When you build such an app, the requirements for it, for this application is it should be really easy to use. There shouldn't be many options. People don't usually use us. They don't know what is the SIP server and the port and is that TLS or whatever kind of thing and nubs and stuff. It should be lightweight. So it also works on old phones. And it should be, if possible, work on smart phones and on the desktop. And if possible, we do make an implementation which is accessible so people can actually join the project. You don't need to have years and years of experience in telecoms to join the project. So for a VoIP app, it should work on a smartphone. It could either build a native app or a web app, right? Nowadays, so we're thinking and are still thinking about adapting an existing VoIP app. But then we would also have to maintain one native app, like for example, CSIP Simple for Android, one maybe for iPhone and how about the desktop then as well. Also it involves a lot of testing and probably a lot of low-level technology to be able to build a native app. If you build a web app, so we went this way in this project and we are using web technology for the user interface and web RTC for the VoIP stack. In this case, we made a progressive web app, which is just, actually it's just like a normal website with JavaScript. And if you do some bits to it, you have this add to home screen function with which you can make it look on the phone like a native app or like a normal app. And it has some features which make it work well for offline, which is caching so that it loads immediately. It doesn't have to download all the code. Service workers, for example, if to control the cache or for push notifications, and you can obviously use all the other functionality of browsers like in browser database, local storage and all that. We used web RTC, which is I think a really excellent VoIP media stack, like one of the best or if not the best open source media stack that you can get. And it's in the browser. It's basically maintained by Mozilla and Google. And it gives the encryption, nut handling, jitter, buffer management, really good one, echo cancellation and all that. And we used the excellent jzip library from Jose to make it easy to do interop with the zip service that we have. So the whole system looks like this. We have one gateway and it acts as registrar for zip. And it also has to handle push notifications and SMS messages can be sent to the BCS message. So it's simple, simple. In more detail, what we did was we used Camelio and RTP engine. They work very well together to do a really good web RTC gateway. And the web phone JavaScript app, which is downloaded from server with a lesson script set, talks over web sockets to the Camelio server. And the media stack talks detail SSRTP to RTP engine. And on the other side, we can talk zip TCP or zip TLS or UDP and unencrypted RTP or other from the encryption. And we are using actually the Camelio user database as the central database. If you install the app, if you load the app on your smartphone, if you just type in the web page, it makes them sign up to just a script, just called allocate number, just simple thing that actually calls Cam CTL to create a user entry in the Camelio database. So, as you see, very simple putting things together so that it works. Push notifications are a bit more involved. At the moment, we have implemented Google GCM. So when the app is sleeping or isn't open, then you need to somehow wake up the app and make the registration to the Camelio so that you can send the call from the Camelio, you can send the invite to the app. How that works is first the JavaScript app actually registers its device identifier with the web push server. And then Camelio uses this mix in this separate component call to this web push server and sends the message to Google and Google wakes up the phone and then the phone registers and you can send the call there. So that's based on Federico's and others push notification implementation. Then we thought, okay, now we are building this, but it's really quite involved to set up all this backend stuff. So if others want to join the project, it's really difficult for them. So what we thought would be better if we have a Docker containers and then, sorry, oh, we can't hear. So we thought maybe it's better if we do that all as Docker containers so people can just in one line or more or less one line, people can install the whole thing and can start adding things to it or fixing things in it. So the target is to have a complete install with one line, but at the moment it's actually not 100% working. So this way to build a VoIP app is a little bit different than what we used to do traditionally. And I think a pure web app has still quite some limitations. So, for example, you can't access the phone's phone book. So we are using a separate phone book in the app. Or you can also, for example, on my mobile, you can't select which speaker, whether you're on speakerphone or on the normal earphones. Also the push notifications, to be honest, I'm not 100% sure whether it really works all well. And maybe in the future we might consider or someone maybe contributes a small native rapper around it with a web view in it so that we can still use the same technology, but have all the functionalities of a native app. But I find it also interesting to see now a day is how far in reality is this all this web technology in order to build this really relatively complex and relatively involved apps. Another challenge is to be honest to combine the web and the telco worlds because in the web worlds it all goes much faster and much the development goes much faster and many more versions and all that. And I think kind of agile development style was quite good because we had very often, we actually had to interact between the development of the application, how does this work and the SIP infrastructure back end basically. But to make a really polished user experience is actually not that easy. I find so that's one of the things you need even if the product looks very simple. You need a lot of, there's quite some complex technology behind and it needs a lot of testing to make it really work well. In the future we want to make it work well for offline deployments. So even though we will probably not need all the SIP gatewaying infrastructure, still we have most of what's necessary and actually the application is the biggest development part of it. So we thought we'd use it also for offline deployments. And then what I'd be also interested in is having an alternative to the Google push notifications. Maybe if someone knows how to do that properly without draining the battery, I'd be really interested to hear. And then for texting it's one of the main goals for the Resomatica network. The UI development just has started but it's not there yet. So I would like to invite you to join this. I think if you're running a, for example, also if you're running a VoIP network and want a web app to have your users call into the app, then this is a really cool starting point. Or you can just use it and extend it and join the project. And yeah, I put some links here. They have a new mailing list on the button which if you're right there you also reach me. And as I said, the docker compose of the server so you can start setting it up yourself. Or you can just write out pelsal.webph.one. It's the URL for the pelsal version or webphone.resomatica.org. Maybe I have some time for some questions.