 Hey, oh Nice to have you here. Thank you for coming. So in case this is the first time you're seeing the same communicator name then I'll start with a short presentation. It is a communications application I'll allow you to do lots of interesting stuff on the internet starting with instant messaging We support most of the instant messaging Networks out there like MSN and Yahoo messenger, but above all we concentrate on the open and standardized ones like XMP PNC So a very important feature centric feature of the SIP communicator is its ability to do audio video calls That are by the way completely secure and encrypted using different mechanisms starting from SRDP for example an internet Specification and I believe we actually have the author of the specification in the room So thanks for working on that and we are also using ZRDP for negotiating The the encryption keys ZRDP is an encryption key negotiation system defined by Phil Zimmerman Specified by Phil Zimmerman. He's also the author of PGP. So I've also thrown in here a couple of screenshots displaying our file transfer feature we have an image preview here showing and Another feature that I'm particularly glad to talk about today is our desktop streaming Implementation that we've just finished this week. You can check it out over there In our stand in the A.W. building an important part of SIP communicator is an important aspect is the fact that it is completely very multi-platform you can use it on Linux Windows we have pre-built packages for macOS X Ubuntu RPN based systems. So we are using it on all these operating systems and We are using it daily for our work on SIP communicator itself and After we keep using it and we keep adding features that we need to see in there And now one feature that we particularly wanted is to have conference calls and That is not necessarily a difficult thing because most of the providers out there Give you the opportunity to give you the option of calling a certain number that acts like a rendezvous service that allows you to To meet with other people and then whatever you say everyone is hearing, but we wanted more than that we wanted to to see who else is on the call we wanted to have audio levels and We basically wanted it to act and feel a little bit like Skype our conference calls Not only because they look good, but because they're also useful It is it is nice to be able to know who's currently speaking how lovely Who's it who else is participating on the call and The one one big advantage about using open standards in your work is that whenever you think about a new feature That you would like to add to your application Well chances are that someone else has already thought of it and has specified it and has described a way that it should work And that's a good. That's a good thing not only because you know That the specification that you're going to be implemented is going to be working in different kinds of internet topologies and in different scenarios But also because if anyone else has implemented already or if anyone else is going to implement it in the near future Well, then your solution is going to work with theirs With just like that. Well and in theory at least because in practice You probably have to resolve a few bugs before it does but it's still a great advantage, right and In the SIP universe, which is the IDF standards and specifications are called RFC's and the RFC that deals with basic SIP conferencing is 4353 and For those of you who don't really know SIP, don't worry. This is going to be it's actually in principle a very simple protocol So right here we have Basic call one one call between Alice and Bob. It's always between Alice and Bob It's it's just it's just like no one else is calling on this earth so a call starts with sending an invitation Alice would send an invite message then Bob would reply by Sending status responses indicating that his phone is ringing and then a no care response to actually accept the call and after Alice acknowledges the call and they would start exchanging media whether that is audio video or both That doesn't really matter. So if at one point Bob would like to add someone else to the conference Well, he would need to do two things according to that specification. First of all, he would Have to re-initialize his goal his existing call with Alice so that she would know that this is no longer one-to-one call and this is important because Maybe she would like to know that whatever she's saying is potentially being heard by someone else and The second thing that Bob would do Is start a simple call just as the one like he's having with Alice with Carol Again, and he's going to indicate that this is going to be a conference call another one-to-one communication and after that They're all going to communicate now What is important here is that both Alice and Carol would be communicating with Bob only It is up to Bob to mix packets that he's getting from Carol with his own audio and then send it to Alice And it is again up to him to set to mix packets that come from Alice with his own audio and send it to Carol This is why Asians like Bob are often referred to as mixers. That's how I'm going to call him So we started by implementing this RFC and state communicator and this gives us basic mixing functionality But we wanted to go farther than that because we didn't have We didn't have the possibility to see who else is in the room. We didn't have the advanced user interface and interactivity That we were looking for so we moved on to implement in another RFC 50 45 75 Which allows us to do just that? So again, it's a simple principle Oh once a conference has been established between a number of participants They could all subscribe With the mixer with the centric entity so that they would get notifications. Whatever something changes in that conference And whatever the mixer is ready He would be able to send sip messages containing XML bodies Indicating if a who is on the call whether they've just joined or left or whether they've changed their status or name or some other information and At one point everyone in the code is going to have a complete view of the conference and be able to show it to their users now That was our second implementation step and that gave us The the notion of rooms people were able to see the list of participants in the conference go but we still didn't have that last part about audio activity and about the audio levels in a call and That was a tricky part because As you can see here all the agents in the call are only Communicating with the mixer and the only party here that is able to recognize who is actually talking at any given point Is the mixer? He's the only one that can analyze in the individual audio streams of all the participants so We were thinking that we decided that maybe we would need to allow the mixer give the mixer the opportunity to actually encode that data into the into the streams and Convey it to the other participants. So the protocol that is used in the better part of all VoIP applications RDP Is also an internet an IDF protocol. Here's it. Here's how a pocket looks. Here's how an RDP pocket looks and Obviously the most important part of that packet is the product conveys the audio that contains the audio But in addition to that we have a bunch of other fields that contain useful information like for example the sequence number Which would allow a user to determine whether or not Their packets are arriving in this order or the timestamp fail Which would allow you to synchronize your audio flows with your video flow. So do other useful stuff with it and In our case the fields that were interesting that were most interesting were these two the first one is called SSRC and It's an identifier every entity that sends RDP packets Generates a supposedly unique identifier to kind of sign their packets and So if I'm getting packets from Alice for example, I would see it All of them are signed with her identity with her ID So if I'm a mixer, I Would I could include all these in the list of CSRC identifiers? That's what it's meant for so that The participants in the co-conference code that I'm mixing that I'm responsible for would know the audio that I'm getting in this packet was generated by the entities with these identifiers and This is what would allow us to To show what your activity to show who's speaking in a particular call So we are almost there. We almost have the you know the Skype like conferencing user interface Except for the last bit showing the audio levels and why is that important to us because sometimes showing audio activity isn't enough Sometimes you have someone speaking and someone someone has the microphone And then at the same time someone else is generating some kind of weird Pastoring noise like, you know the Darth Vader people that would tend to put their microphones right underneath their nose and they start So you try to listen to the conference going understand whatever is being said but that doesn't happen because someone's so if When it when having all your levels it could very easily resolve that because the thing is that Normally people that generate that kind of noise don't don't know that they're doing it So when you once you determine who that is well, you could send them an instant message and say well Well, could you please maybe stop doing that and use your mute button because we're trying to have a conference call here You're not really helping so In order to what it's actually quite obvious that at this point It's the the most sensible thing to do would be to simply add a list of audio levels right after the list of the Identifiers and that's what we did we added an enumeration of audio levels here that Coming the same order as the CSR C identifiers and that was the last piece necessary necessary to implement the user interface up We were that I'm talking about We've described and published this solution in an internet draft you have the name over here and It's hopefully going to be integrated as an official working group document and one of the IDF working groups hopefully soon and That this was it. This is what gave us the possibility to give that to have that interface a Very important thing that I would like to say I would like to express our gratitude to the Internet Foundation From Netherlands who have been funding this work from the start. So thank you guys I don't know if anyone is here, but thanks anyway Oh, and another important thing is that again the fact that all communication is here is encrypted Transport through sRDP through the ZRDP key negotiation mechanism And oh, yeah, this currently only works with SIP for the time being but again as I said we are going to have an Implementation for XNPP jingle. This is the the job or way of doing telephony for one-to-one calls maybe at the end of the month or in the beginning of next month and We are going to port To to integrate the possibility of doing conference calls and all with all the interactivity with all the advanced audio level display stuff by Maybe the end of April So that was it. Thank you for coming and thank you for listening We have a couple more minutes. So if anyone has any questions, I'd be I'd be glad to answer. Yes Um, there is Yeah, I didn't say that indeed there is a field defined by the 4575 RFC that allows you to map a SIP URI to a to an SSRC number Anyone else? Yes No, you're not supposed to use the RDP to actually encrypt SIP signaling you do that normally using TLS and SIP communicator supports that so you can have a completely secure Co-establishment and in coal scenario with SIP communicator Simone state in your channel as in a man in the middle attack or Well, that's what the RDP is built for it has That is a special way of a very fine identity by involving a vocal check So you're displayed for characters that you have to read to the opposite party that have to compare them with with what? they're seeing and verify that this is indeed you so hijacking a connection would only happen if someone is able to imitate your voice or something which is Kind of difficult No, we don't do any of that right now Maybe yeah Well, that's the thing Well, we haven't really tried to find the maximum number of participants up that would depend very much on the On the computer configuration, but this is not meant to be something that you would use in large conference calls. This is Utility that it could use for Conference calls with four or five more participants And if you would need to have something more advanced than that then then you would have to You would have to use a server hosted solution somewhere and by the way servers such as come we leave it could be I could also implement the audio level solution and The 4575 RFC so we would have exactly the same user interface with CIP communicator as as with conference calls hosted by CIP communicator itself. I Was hoping to do that Thank you again