[00:00.000 --> 00:11.880]  So, hi everyone again, leave you from OpenSIPs here and I'm going to be quickly going through
[00:11.880 --> 00:19.120]  what has been happening in the last year and what is new in the latest OpenSIPs 3.3 release,
[00:19.120 --> 00:32.160]  which is pretty much focused on IM and RCS and a bit of extensions to both IMS and on
[00:32.160 --> 00:35.240]  the UC, on the call center side.
[00:35.240 --> 00:41.120]  And the reason why we went this route with this iteration, because we have one major
[00:41.120 --> 00:49.560]  release each year, is that we've talked to the community and also read a bit of papers
[00:49.560 --> 00:55.240]  like this one from a Juniper saying that RCS is growing, it's getting more and more
[00:55.240 --> 01:04.400]  adoption, the subscriber population is forecasted to grow to like at least two billion devices
[01:04.400 --> 01:13.120]  within the next few years, so why not make a bit of additions on this part.
[01:13.120 --> 01:19.840]  And one of the first, so here you can see hopefully the font is not too small, kind
[01:19.840 --> 01:29.560]  of the entire ecosystem that we have in mind here, where OpenSIPs, we make all these like
[01:29.560 --> 01:38.400]  microservices catering to various components of the platform, there is the MSRP protocol,
[01:38.400 --> 01:46.040]  which I'm going to quickly go through, so we are seeing a relay there, there is also
[01:46.040 --> 01:54.520]  some gatewaying necessity for clients which don't support MSRP yet, they still need to
[01:54.520 --> 01:57.400]  be integrated with the platform.
[01:57.400 --> 02:05.320]  There is gatewaying to the IMS side, using RCS capabilities and also the contact center.
[02:05.320 --> 02:14.240]  And with the IAM, we have, this is what we had, the simple message SIP method, just a
[02:14.240 --> 02:20.080]  request reply, nothing much past that, but then there is also this MSRP protocol which
[02:20.080 --> 02:30.480]  is not that new, it's 15 years old, but so far we've just seen it as you could use some
[02:30.480 --> 02:36.480]  other software for it, there was also the MSRP relay project that you could use, but
[02:36.480 --> 02:43.720]  now there is the need to have this closer in OpenSIPs and gain more access, more control
[02:43.720 --> 02:50.160]  over the sessions and that's why we went and implemented the protocol as well.
[02:50.160 --> 02:59.120]  So for example, this enables features like the RCS I was talking about, you could see
[02:59.120 --> 03:06.280]  RCS as a turbocharged SMS, so it's pretty much SMS with all of these nice capabilities
[03:06.280 --> 03:12.280]  like read and write receipts, file transfer, photo sharing natively into the phone, you
[03:12.280 --> 03:17.680]  don't need an OTT app like WhatsApp, iMessage to give you all of that, that is the idea
[03:17.680 --> 03:24.600]  with RCS and it's why Google is pushing it forward and why Apple is pretty much reluctant
[03:24.600 --> 03:29.400]  or neutral towards it because they already have the iMessage, so why also work on something
[03:29.400 --> 03:34.160]  that conflicts with your own application, right?
[03:34.160 --> 03:40.040]  So MSRP, not much time to go into it, maybe we can take a look at a couple of request
[03:40.040 --> 03:47.200]  replies, so here you set up the session like a regular call and if we look at the SDP,
[03:47.200 --> 03:56.560]  we get the source port that each side is advertising and from now on they will exchange these MSRP
[03:56.560 --> 04:02.400]  messages, so it kind of looks like similar to SIP messages and in the payload we see
[04:02.400 --> 04:06.840]  the messages, the chat part.
[04:06.840 --> 04:12.760]  And this is how the stack looks in OpenSIPs, it's kind of a three layer architecture right
[04:12.760 --> 04:16.480]  on the bottom, there is the protocol and if you're familiar with OpenSIPs you know the
[04:16.480 --> 04:24.120]  other proto underscore modules, your TCP, your TLS, your WebSocket and all of those,
[04:24.120 --> 04:29.960]  now there is the MSRP as well and the first module we built on top of it is the relay
[04:29.960 --> 04:37.880]  which as the name suggests there is not that much going on but also it solves the problem
[04:37.880 --> 04:45.040]  of authentication which is in the MSRP protocol, the auth method and it gives you some useful
[04:45.040 --> 04:50.440]  callbacks to supply the credentials, right?
[04:50.440 --> 04:57.240]  Also on the egress side it gives you the possibility to select the destination and that's pretty
[04:57.240 --> 05:04.960]  much about the relay, the user agent is a bit more interesting in the sense that you
[05:04.960 --> 05:10.720]  can interact with it in various ways, also first from the OpenSIPs configuration script
[05:10.720 --> 05:15.320]  you have this, I'm going to show you some call flows so you can get an idea of how it
[05:15.320 --> 05:22.600]  works but also through the management interface right which is HTTP based, so you get this,
[05:22.600 --> 05:28.440]  you can implement it from your web applications for example and initiate and control sessions
[05:28.440 --> 05:36.760]  that way, for example, okay so there are no animations, so here if we take them from top
[05:36.760 --> 05:43.720]  to bottom we can see an example of a web app that is obviously not MSRP enabled, talking
[05:43.720 --> 05:53.600]  to an MSRP enabled application like a web phone and on the app side you use MI, right,
[05:53.600 --> 05:59.800]  like HTTP invocations, like start session, send message or end session which get nicely
[05:59.800 --> 06:08.240]  converted on the outbound leg to SIP calls, right, it's a SIP call that then only has
[06:08.240 --> 06:16.160]  these MSRP mid-dialogue messages and on the other direction the SIP calls initiated by
[06:16.160 --> 06:23.400]  the MSRP phone get converted into events for the application, you can subscribe to it via
[06:23.400 --> 06:32.440]  whatever channel you want to receive them on, JSONRPC or stuff like that, so the next
[06:32.440 --> 06:43.240]  one was the gateway, right, the MSRP gateway that helps us include the classic SIP clients
[06:43.240 --> 06:48.840]  which are only capable of SIP message, right, they don't know MSRP but it does this nice
[06:48.840 --> 06:55.920]  conversion of like these simple request reply messages, it actually converts them to a session
[06:55.920 --> 07:03.520]  with the MSRP enabled phone, so these sessions are kept by open SIPs transparently and they
[07:03.520 --> 07:08.440]  are even closed, for example, since there is no way of knowing when it decides to stop
[07:08.440 --> 07:13.080]  a chat, for example, right, we just close them based on inactivity, we just time them
[07:13.080 --> 07:22.040]  out, whereas, so this is when the simple, one minute left, okay, okay, so that is pretty
[07:22.040 --> 07:30.200]  much on the gateway, the call center, some additions here, right, because now we got
[07:30.200 --> 07:34.720]  some more types of workloads or capabilities for the call center agents, they can handle
[07:34.720 --> 07:40.320]  both chat messages and voice, so a cool thing about chats is that now they can do parallel
[07:40.320 --> 07:45.320]  work, right, you can do two calls at the same time but you can have four chat windows open,
[07:45.320 --> 07:51.120]  so there is this problem of balancing the incoming requests in the queue, right, you
[07:51.120 --> 07:56.160]  have calls and chats and from various parts of the platform and now there is this problem
[07:56.160 --> 08:02.240]  of correctly balancing them to your available agent based on their capabilities, right,
[08:02.240 --> 08:07.560]  some of them may have chat enabled in their application, some of them not and there are
[08:07.560 --> 08:14.960]  few modes to control that and on the MS side, of course, the possibility to build custom
[08:14.960 --> 08:22.080]  diameter requests and pretty much that's it on the, on the UC side and DIMAS and RCS,
[08:22.080 --> 08:27.520]  a couple more additions on status and reporting, so now OpenSIPS is a lot more verbose with
[08:27.520 --> 08:33.560]  regards to how its internal state looks like, some additions on the TCP engine also giving
[08:33.560 --> 08:40.000]  control of TCP connections and that's about it as far as I have here with OpenSIPS 33
[08:40.000 --> 08:44.640]  and I would like to welcome everybody to the newly announced OpenSIPS conference this year
[08:44.640 --> 08:50.480]  for where we will be unveiling what's been going on with the 3.4 and what we are working
[08:50.480 --> 08:55.320]  on on that side and with that, I'm not sure if there are any more questions but thank
[08:55.320 --> 09:14.320]  you for your attention.