 So now we are going to be listening to SIP-based group chat with Limfone, Simon Morla. Okay, thank you. Okay, is audio working good for everyone? Yeah, okay. So I'm Simon Morla, original author of the Limfone software. So Limfone is a software that you can run on now any platform to make audio and video codes over the internet and you have instant messaging as well. So just to give you a bit of history about the project, so I started to write this project in 2001. It was a spare time activity and I was finishing my studies, actually. And so I did this because it was lacking something in Linux to make audio calls. So I released the very first release, very basic audio calls under GPL v2 license and the minimalist GTK interface. And then I continued the project on spare time and in 2006 I added video calls and I ported the software to Windows operating system. In 2010 I had the opportunity to create a company that I called Belldown Communication whose purpose was to dedicate full-time development effort on Limfone software. So the basic business model is dual licensing, GPL and proprietary support to our customers and developing specific development or customizations for our customers. And then the development went very fast in the next years and in 2011 we ported the software to iOS and Android with video call. In 2012 we launched a free SIP service that could be used as a reference to run Limfone. It's based on a new software that we have introduced that is called FlexiSIP and it's a SIP server, I will tell a few words about it later. During the years, in the next years we largely improved the user interface of mobile editions of Limfone. We added IM with delivery notifications and many security features. And last year we launched a brand new interface of the Limfone application for the desktop Mac, Linux and Windows based on Qt. This year we're about to launch new releases for Android and iOS incorporating GroupChat and that will be my focus today because GroupChat is not something that has been widely used, widely implemented over SIP and I think Limfone will be the first in the open source world. So GroupChat, what it means, it means that you're able to create multiple participants to designate administrators, you can later add or remove participants. GroupChat has an undefined lifetime. Of course on the server side you have to deal with store and forward because the client are not always connected to the network. You need delivery notification, file transfer and in some cases you want to have a high level of security and then you need end-to-end data protection. So this is basically what applications like WhatsApp or Messenger are doing in the use case actually. So when starting this project we of course knew that most of this was already done in XMPP so we have this question of course of why not using XMPP for doing all that stuff and so actually I did this slide to give you small elements of comparison between the two protocols. They were born I would say around the same years in the early 2000s but XMPP targeted at first instance messaging and so it is very well established in this field. On its side XMPP was a protocol for initiating any kind of session but in practice most implement patient targeted audio and video calls and it was very well established in audio and video call fields. So XMPP has evolved lately to instant messaging and I would say that there are some attempts for proposing RFCs about how to implement instant messaging but for the moment it's quite confusing about what to use. SIP has the advantage of being quite modular on server side while XMPP has a rather monolithic design and finally XMPP has now audio and video but it's quite new actually. So our choice was to continue with SIP for many reasons. First of all it was that our company has many clients and also an end user base that expects Linfone to run on top of SIP. The idea of mixing an XMPP stack and a SIP stack within the same software had several drawbacks to earth. So first of all the dramatic increase in the amount of code to include in the project and the duplication of TLS connection to communicate with the two protocol. The authentication management, username and password would be duplicated to the server infrastructure would have to be duplicated and for us as a company we will duplicate some expertise to be able to troubleshoot the full system. So we considered that they were actually at IETF and also the specification made by operators GSMA RCS for each communication system. Both of them offer solutions for group chat so we pick up ideas from that and we have implemented their recommendation. So finally one of the next reason we have for keeping SIP is that we have heavily invested on SIP for simple instant messaging between two participants and so we don't want to lose this work and it's actually working pretty well. And lastly if we were able to perform a conference for text we'll be also able to leverage on the code to perform audio and video conference. So here is basically how in SIP we can expect to do group chat so of course SIP is responsible for session establishment so we'll use the very famous invite request to create the conference. So basically it's a dialogue between a client and a conference server. There is an RFC called conferencing for user agent that gives very interesting call flows in order to set up a conference on a conference server. There is an RFC that expresses the way to give a list of participants to a conference server. The RFC called Grooze helps in identifying devices which is absolutely required for end-to-end encryption. For group chat we need a way to notify the client about evidence of the group like somebody has joined the group, somebody has left the group, somebody has been designated administrator and for this we have two RFCs published at ITF. So first one is the generic subscribe notify SIP request which gives the basic behavior for subscribe notify like PubSub in XMPP actually. And SIP event package for conference states gives an XML dialect to represent the state of a conference. For message transport there is the MSRP protocol that is recommended to send text and files. There is also the SIP message request but it's considered as obsolete and the RCS specification defines a simple protocol with HTTP post and get in order to exchange files between two clients. And finally we need a few more RFCs for auxiliary messages so message format with metadata with CPIM instant message disposition notification which is in other words the fact that you are able to see that someone you send a message to has received the message and later has read the message. An indication of message composition that we call is composing the fact that you know when someone is typing some text. So in green what we have implemented the Red Cross is actually for MSRP so we decided not to go for the moment with MSRP because yeah it has some advantages like being very simple it has built in store and forward capability and it allows to separate signaling path from the message transport path but for us it was yet another protocol to implement yet another connection the client has to make. We need to have integration with push notifications services as well for MSRP because actually now mobile devices are not able to have permanent connections with servers so you are required to go through push notification service in order to wake up a device to receive something. And our FlexiCIP software remember FlexiCIP is our CIP proxy server actually does all the job we need for transporting text over CIP message so we decided to leverage on this and move forward. So here is the big picture about our architecture so here we see that we have a free client Bob, Alice and John that are connected to a FlexiCIP proxy server which is over CIP TLS so the proxy main task is of course user authentication DOS attacks protection, registration, integration with iOS and Android push services and of course a proxy has to route any kind of request to the user agent or to other proxies. This proxy is connected to a registration database which for now in our case we choose the radius distributed hash table and our FlexiCIP conference server then runs on a protected network behind the FlexiCIP proxy server and this is the part that will manage all the conference so it needs of course a persistent database in order to store information about the groups that have been created by the clients and all the related events of the group about participants that entered or leave the conference. So I will finish this presentation by give you a few examples of CIP messages so that you can basically understand how it works. So this is an invite request that is created by a user called Mary that wants to initiate a group with Lore and Pauline so this invite is sent to a special CIP address called conference factory which is the address in order to create new conference. So it says that Mary wants to initiate a conference whose subject is about colleagues and he sees the list in some XML dialect that says that there are two people invited in this conference which are Lore and Pauline with their CIP addresses. The server immediately responds by saying that okay I allocated a new chat room a conference room for this user whose CIP UI is given here and note the ease focus parameter which is the standard way in CIP to signal to a user agent that is now contacting a conference and be part of a conference actually. So finally a new invite is sent this time to the newly allocated conference and saying that Lore and Pauline are invited and later if we want to add more participants we can put more people in this list. Of course the conference server has to inform Lore and Pauline that they are invited, that they are requested to join this conference so for that we use the refer message, the refer request of the CIP protocol with a refer to header that gives to Lore and Pauline the unique CIP address of the conference. In order to receive information about what is happening in this group each client sends a subscribe message to the unique conference address in order to receive events about the conference. Then the server, the conference server is expected, oh it's a bit small a notify message in which it will give a description of the conference this is a full description but later for participant being added or removed then there will be partial notification. So this XML dialect gives the subject, gives the list of participants, Mary, Lore and Pauline and we can see that actually user Pauline has two devices with different IDs and so every client has a full visibility of which other participants and devices are part of the conference. In order to leave a conference you say bye like in any CIP session. So here is our roadmap for the next month so we'll be releasing iOS and Android on the betas on the stores so it's open to every user and then we'll make, if everything goes well, the final release around March we plan to add device, well device to device data protection so encryption of text what we call line V2 for LinFone instant messaging encryption around May we release the full source code of the Flexi-CIP conference server under FAO GPLv3 around July and we plan around in September a new release of the LinFone desktop application incorporating group chat as well. And lastly we have in mind some future work so optimization work in order to better handle connection and disconnection which are frequent in mobile environments and we want to minimize the number of CIP requests being used to perform these conference use cases and we have in mind to write down the kind of best practice RFC that we could submit to IOTF in order to propose our solution to the world. Thank you very much for your attention. Actually, let me say the question again. The question is about which kind of techniques or standards we are going to use for end-to-end data protection in the messaging. So our idea, so first of all we conduct a study of what existed like in a signal protocol and we found as well the OMEMO standard which is used by XMPP and it is an XCP being currently engineered at XMPP level and then we decided to go with a very similar approach with I think exactly the same curves which don't come from the NIST so I would say there's nothing very original in our solution but it I think has never been implemented with CIP so this could be part as well of an RFC or something we could document to the world. Yes, of course. The question is, is there any way to connect to our servers infrastructure or to have Linfone being able to connect over WebSocket which is actually the transport being used by WebRTC and JavaScript CIP stack like GS CIP. So the answer is no, our FlexCIP proxy does not have any WebSocket transport but this is something that we are sometimes asked by our customers so maybe it will happen someday. I would say that our company is quite small, we are around 12 people and we have lots of work to do with Linfone, our FlexCIP and all the media streamer engine that is running with it and so we don't have much expertise on WebRTC. Any other question? So the question is about the compatibility between Linfone and other kind of CIP servers. So the answer is that for audio and video calls Linfone is compatible with CIP and is then by consequence compatible with any kind of CIP server which is specific to the conference service, chat conference. I would say that for the moment, at my knowledge there is no at least open source implementation of conference server being able to do instant messaging so I think it's too early to answer this question but the idea is that with Linfone and FlexCIP we will put on the table the reference implementation and CIP workflows that practically work for doing IM conferences and so we expect that other CIP proxy or CIP server implementation will follow a path similar to us. Thank you.