 Good morning, everybody. My name is Jean Monnier. I'm software engineer since 1999. And I'm mainly involved in the Linfon project since 2010. So in a few words, the Linfon project is the voice of our IP software developed for Linux in very early 2000. So what I'm going to talking about is how to use the voice of our IP technology to build an intercom system for the entry. OK. So the presentation will first start to introduce the use case, so what it is about when you want to build this kind of system. What is the voice of our IP technology that we suggest to use and how to build a very simple voice of our IP network using Raspberry Pi as an example and with the Linfon software and what would be the next things. OK. So the simple use case is like this. So you have an intercom doorbell in front of your building and you want to open the door. So in the past, the very simple solution is to have a camera in the front of the building and to use a simple coax cable to link the camera to the home screen. OK. So it's pretty cool, but now if you want to have multiple displays at home, like the home screen, but also why not a mobile device or a PC. So we start to be in the multi-display use case. OK, so same thing. I have the coax, but what if I want to bring the video to a mobile device, for instance. So it's become much more complex. And what we can also imagine that the same kind of use case, so you want the video to be display at home, but also in the street on your mobile device if you want to know if something is happening in front of your home. So the good thing is that we can leverage on digital infrastructure to do this kind of thing. So no more analytic audio or video, but we can use IP to carry audio and video packets from the door entry panel to the home screen or even a mobile device or even a mobile device connected to the public internet. And when it's about IP, voice over IP is a good idea. And especially to protocol, which are SIP, SIP, and RTP for real-time transport protocol. So voice over IP technology that I'm going to use for this presentation are based on two main IETF standards. The first one is SIP, Session Initiation Protocol. And the second one is real-time transport protocol. So SIP, well, in a few words, it's a text-based protocol that is inspired from HTTP standardized in 2000. There are two main components in the SIP network, the SIP user agent and SIP proxy, which are about writing SIP messages between different clients. And RTP in short, basically, the idea is to send audio and video in a packetized way over internet. OK, so now we want to use IP. We will use SIP and RTP. So what we need is a SIP user agent located in a door entry camera and a SIP user agent in the home screen for the software. For the hardware, at the door entry camera level, what we need is to be able to capture audio, video. And for the home screen, we need just to be able to display video and capture the audio, because most of the time there is no screen in the front door. So for the software, what we need is what we propose is to use VIN phone, which is a SIP user agent with RTP capabilities. And for the home screen, so we can do exactly the same. OK, so now we have the hardware. It can be Raspberry Pi or any small hardware running ARM or any other processor display, a cable. And on the software base, we can use the Raspbian distribution of the Raspberry Pi with Linux with LIN phone on both parties. OK, so at the door entry camera level, what we can use is a command line is LIN phone demo, which is a command line interface for being able to place or receive call with early media feature. I'm going to explain what it is about. So early media is a specific way of initiating calls. For a regular call, you wait for the call to be established before exchanging media between the two endpoints. In the case of early media, the idea is to be able to send the video before answering the call. Because when someone is in front of the door, you want to be able to see this video. It's a kind of preview, but not necessarily accepting the call. So LIN phone demo, it's an open source project derivative from LIN phone. It's available on our public git repository. And also, something interesting for the embedded case, we provide some Yocto recipe to integrate LIN phone demo within a Yocto distribution. OK, so how it will work? Just a button connected to the GPIO. I just start LIN phone demo in the background with a unique spike. And with a couple of lines of Python, it's pretty easy to handle the button and just to open the socket, communicating with the LIN phone demo and to initiate a call. That's it. On the display side, it's almost the same. You can just start LIN phone demo in auto answer mode. And it will automatically display the video. So it's for the very simple use case. So now, if you want something a little bit more complex, you want to be able to distribute the video, not only to the home screen, but to the home screen and to another equipment, which can be, for instance, to a mobile application. You need to add another equipment in the SIP world, which is the SIP proxy. The purpose of the SIP proxy will be to route the call on both the SIP and actually the agent which is in the home screen and on another user agent, which can be a mobile application, for instance. So now, we suggest to use another equipment, which is called the SIP proxy. As I said in the beginning, it's the matter of the SIP proxy is to route the calls. And with a special feature, which is the early media call for hacking, because as I said at the beginning of the presentation, what we would like is to have the video coming from the Doron 3 system to the home screen or to the mobile application before establishment of the call. So we need a SIP proxy, which is able to duplicate the audio stream in order to be displayed on both devices. It's what is called the early media call for hacking, than the video previews, from the collisator to all ringing devices. OK, so FlexSIP, it's a simple process running on Linux with a very small configuration file, so just a couple of sections to authenticate. I need to set the domain of my house and a smaller configuration file with the password in order to authenticate the user. If we want to go in deep into the SIP protocol, so I have the smartphone app which is registered to the home screen, to the home screen SIP proxy, the home screen panel, which is registered as well. And when the Doron 3 camera want to invite a call, the invite goes to the SIP proxy, which fork the invite to both the smartphone application and to the home screen. And the RTP with the video can be displayed on both devices at the same time. OK, so now if we go a little bit in deep in the complexity, I want the video of my Doron 3 system to be seen on my home, but also if I'm outside, it would be cool if I could be able to see who is pressing the button in front of my house. So now what we need is two cascades, two SIP proxies, one at home and another which can be located anywhere on the internet. So we can do it with FlexiSIP the same way. So we had a small configuration file which explained which state where to fork the call on the public internet. So as you can see, we have a first SIP address, which is everyone at my house, which is fork to home screen and to bob at sip.info.org, which is an IP address available from the public internet. OK, so more or less it's the same. Just the end is different. The SIP proxy from the home screen is forwarding the invite to the public internet SIP proxy. And at the end, the video can be seen on the local network and on the device connected to the public internet. Security consideration, so it's very sensitive data, which is coming from your apartment and from the doorbell. So make sure to use SIP TLS and SRTP everywhere to secure the communication. And also if you put some password in the local network, it's still better to hash the password. OK, so it was for the presentation of a very big network for the video intercom system. What next? We can also imagine to do the opposite. I mean to call the door entry panel from a smartphone. It's also something which can be doable. It's also possible to add action to the system. I mean if you want to be able to open the door, you can, as an example, use DTMF to pilot some switch at the door entry panel level. An interesting thing that you can also use is MDNS to be able to automatically discover the door entry panel or the home screen without having to configure IP addresses. Another interesting topic that we could discuss is how to use push notification to be able to wake up mobile application when someone is pressing the home entry button. This is something which also is available from the FlexSIP proxy. Another interesting point is interworking with existing door entry camera. I'm pretty sure that on your building there is a door entry panel. And what we experience is that most of them are using SIP as the protocol to bring the audio and video from the door entry panel to an equipment in the house. So if you want to be able to use existing equipment and just to change the display, it's something which is possible as they follow the SIP standard. And the last thing is, in my presentation, I introduced Linfundiman, which is a command line tool. But if you want to have deep control of the application, you can use the library version of Linfundiman to do the same. It's available on C, C++, and on many other languages, even on Python. OK. Thank you. I think I'm three minutes ahead, so if you have questions. OK, any questions? Yes. OK. Thank you for the presentation. So is that a commercial project or is that your personal hobby project? In fact, there is no real project for this kind of application yet. I would say that I'm part of the Linfund team and there is a company backing the Linfund project, which proposes this kind of service. But there is no currently, there is no project dedicated to this kind of application. It's more a usage of Linfund and PlexiSip for this kind of application than a real project dedicated to the entry system. Was it your question? The question was really like you were talking about having your proxy and then sip on the stationary tablet to display the incoming call. So would you put proxy on the same tablet as? Oh, the proxy which is in the home? Yeah. Yes. The idea is to use the same hardware for both the home screen and the sip proxy. OK. So let's say you're streaming the video to proxy and then it goes to the tablet itself and mobile phone. How do you deal with video decoding? Is that hardware supported on both phones and tablets? Or can proxy do recording? Or how do you do this? Video decoding? Video decoding is a diamond software. Is it hardware decoding? The proxy is not decoding the video at all. It's the same RTP stream which is forked to both the home screen and to the mobile application. And the mobile application is supposed to be able to decode either H.264 or VPH depending on the protocol which is used. Most of the time it's H.264 because it's possible to leverage on the hardware implementation of this kind of codec which is available either on Raspberry Pi or many other embedded hardware. OK. Cool. Thank you. You're welcome. So how is a link phone compared to other web softwares like Zivo and Elastics? The question is, is there any? Zivo. Zivo, yes. It's an open source project around Asterix. I would say that we have no experience in this kind of scenario with Zivo but link phone works with Zivo for regular phone calls. So as Zivo is based on Asterix and Asterix is following the same protocol, I don't see any kind of issue to use a Zivo with this kind of deployment of link phone within the doorbell. On the type of hardware that you've been talking about here, what sort of latency do you get between somebody actually pressing the doorbell and a mobile phone getting an image? And then what's the quality of communication between the two ends like in terms of delay between one speaking and the other hearing? Oh, I would say it's a matter of network quality. So if the quality is good, if it's a wire cable, if it's cable, there is almost no delay. You have the encoding time at the doorbell level. But if it's hardware encoding, it's good. And it's a ping time or more or less. There is no, I would say 50 milliseconds, 100 at maximum, but not more on the local. If you are speaking about the public internet, it's a little bit more complex. But on local network, there is no problem at all latency. Thank you for the presentation. My question is, I use voice over IP product like a service from a service provider for a few years ago. And I have it always connected in my Zuiper or something. Have you considered giving the doorbell, for example, a connectivity directly to the internet or through some proxy with some general voice over IP telephone number so that I will only set the telephone numbers of me and my family members and it will act as a standard voice over IP video call in their mobile clients? Why not? Why not? I don't see any issue with that. As I said, it's standard SIP. So if your network provider, your SIP network provider follow the standard, you can simply configure the SIP address that you have and directly connect the doorbell to your public. So if the provider keeps all the standards and supports DTMF, everything would be possible using a standard client. OK, thank you. OK, this has all the time we have now, so thank you very much.