I have one, my name is Nune Reish, I work for a tall desk, which is a cold center company
that exists just in the cloud.
We offer contact sensor solutions, basically, and down the road, we use a lot of open sources
as well.
As you may see here, I will speak today about Camille Free Switch RTP engine, mainly Camille
Euryo, some of Free Switches as well, we will get into that, and let's do it.
So I will just try to explain what the problem was in talk desk for this, and we will
do a quick overview of how our global network, I will then go into the details of the
design and architecture behind what we did, and some future work that I think might
still have room to be done.
Okay, so the problem we had was somehow the company decided that we should try to go after
some on-prem contact centers, not exactly as talk desk, and he may believe I could
be able to be able to test for them as a solution.
To do that, and since we are talking about on-prem or even other cloud contact centers
that are PT legacy, or I kind of closed in themselves, we will talk to look on what
were the existing frameworks, standards that we could tap on to actually enable this.
One of the things, and I will focus a lot today on that, is how we enabled the co-pilot
feature that we had already on, let's call it native talk desk solution, by using C-Prec,
with connecting C-Prec with talk desk, with this open source components.
Basically, we also looked at what we call the X-Connect ecosystem, the X-Connect
access system is, group of components that include Camille, RTPA engine, SBC, and we have
some flows already supported in that, but maybe there were missing parts there, to actually
enable this, we tried to identify which were those missing parts, and I could we close
those gaps using official open source, like Camille, RTPA, or Frisic.
So again, by the way, it was to connect external sources through C-Prec with us, make this
global available, work at scale, and we also had a requirement, internal requirement in
talk desk, to keep the AI ecosystem, which is a different vertical in talk desk, as most
simple chess possible, since we didn't want to go, I can increase the effort on changing
much of that, and we kind of achieved that through what we did.
So our global network is basically, so we have everything cloud hosted, as I said, we have
a global presence, more or less like this for C-Connectivity, and some other use cases,
but in this particular situation, C-Connectivity, at an IWRW review of what we use,
basically, we have the SBC component, Camille, RTPA engine, and then we just connect everything
from AWS as EC2s, deploy to the C-Prec side of talk desk, which is other kinds of people
use Kubernetes, EC2s, so it's kind of a mix there, and we get into this one to actually support
C-Prec, so the idea here was, so we got the C-Prec in, we would fit it into Camille, Camille,
we would do some initial work with that, would send it to a new piece, which is that SRS,
the C-Prec server, the C-Prec server would then send it back over Camille into a free switch
instance, and this free switch isn't with AirPin, the participants of the call together,
and reply back, and basically the dialogue will establish, by doing this and using a specific
module in free switch, which is the module we would be able to stream over web socket,
any call happening in free switch to a web socket, which was the interface that the guys
in talk desk were using for initiating a co-pilot instance, then here there are some magic that
I will not go into much detail, but we would then start a session on some kind of web browser
in that on-prem system where the co-pilot will connect with an agent that was already mapped
to an agent in talk desk, as if it was an ativation, and all that will go from there.
Okay, so, in terms of open source components, common free switch, module stream for free switch,
and we started by using Bractio SRS, I have to say that they were pretty ingenious on the proposal
they did for providing an SRS and an SRS capability interactive, so they have two flavors,
one is using free switch, the other is using RTP Engine, actually by implementing that diagram
that I showed before, we support the two together as well, we are now using RTP Engine,
and by leveraging the Janus mode of RTP Engine, we can subscribe like a video room like Janus
session and get the stream of that, so that works also, we decided to go with the module stream
for free switch because the endpoint was already a web socket, we needed that, we could pass
and activate along with it, so it worked better for the time friend that we had.
Okay, some of the community modules that I used for all of these, so this patcher, it's table,
STP, upset, desktop, Johnson, HTTPS, Inc, and some others, but maybe these were the major ones.
So in terms of RTP Engine, we did not change much, so RTP Engine is there for normalizing everything,
we have the Janus mode also if we want to actually stream something off RTP Engine it works as well.
Now, an example of how I basically detect if I am on a separate call in Canary Audio,
so here we are basically tapping into the body of the message and see if it's multi-part mixed,
if it is we continue and then we will see if there is STP part and the recording session method
part, if we actually find the recording session method at the part we will try to see the content
disposition is record session, if it is, we say okay, this is a separate call and then we do some other stuff.
In this case, I'm actually storing in the hash table, the call ID of the original separate call,
I will need that later because everything here is stateless and since I will be showing
a call example in a few moments, but basically I'm keeping this call ID stored to actually when
the call goes through all the components and gets to free switch, I saved the details of free switch
where like the IP of that instance, the ID of the free switch instance itself, so by doing that
and saving that I will later emit an event out of community to via our X connect API to a Kafka topic,
then our components on the other side would be listening for that topic and would be able to
request the stream out of the right instance of free switch through more audio stream and they will get
basically the calls streaming, so this is more or less what I'm doing, this later part here,
we are encoding the recording session method at the end of STPs as best 64, so we can send it in that event,
so that's what this is doing, on free switch we created an extension out plan extension for
the air pin part, this is highly inspired by the work of Draktio, so the guys at Draktio have
kind of a similar simpler approach for this, so when we get the call in free switch,
I'm basically doing some tests if we are getting some requests, you are hyper-emitter,
they are coming from Camille here, you want that particular call, if that matches, we enter here
and then I apply here a Ragex on the STP part to actually get from the STP part,
two things, one is the original CPEC all ID, that I will be then sending in a customer
other back to Camille here, and the other thing that is important to me is the destination you are
the original one, so I can link the original C, SRS call with the reply part on the same SRS instance,
so this is more or less what this is doing, so basically here we are using an external
runtime for the SRS, I don't like it as it is today, it works fine, but some interesting thing
to actually do here would be making Camille, you will do what SRS is doing outside of Camille,
like in a module of some sort that would basically reuse for instance free switch for the rest,
as SRS is doing already, maybe that would be nice, I don't know, maybe we will do that,
okay, yeah that's it, now let me just show you the call example with all this,
if I am able, I don't need it, it works, okay, so, okay, so this is a CPEC invite,
so we have the multipart with STP and recording session metadata, the first thing there,
so for you to know this is Camille, this is the SRS, this is free switch, and this is Camille,
again we will get, okay, so call interest Camille, okay Camille with the dispatcher,
sends it detects that this is CPEC, sends it to the SRS instance, the SRS instance does a first kind of
clean up, it basically slices the STP part and uses the first part of all of the STP to actually
pin the participant, the audio of the first participant that will be bridged in free switch at a point,
okay, so then here it's being sent to free switch, I'm adding some CPEC parameters in the top,
as you see here in the STP, I'm actually adding some extra attributes with the original call ID and the
original destination URI, and currently in this particular case with X, so that this is basically
reused later, so basically free switch here processes that and adds all those custom
methods that talk that something, so I'm basically, this is important for that event that I talked about,
so the core UID of the free switch is the instance that processed the call, the IP of that call,
the AWS region, where the instance is, and I'm actually adding as well the original call ID and the
CPEC destination URI encoded and then Camille will de-encoded it later, so it gets into this,
now the answer, and the answer that is coming from SRS, is also treated by SRS sent to
free switch, free switch, free switch, this is the call together, everything goes back,
until we send the 20th OK reply off the original CPEC call back, when it gets here, I created some
logic in Camille URI that basically when I detect this step, I emit the event with all the
logic that I, with all the things that I collected, namely the free switch details that will then be
used for asking the stream of the audio. OK, that's it, the time was a bit short, I could eventually
show you some code in Camille URI, I showed you some examples already, but time is up, sorry guys,
I hope this was interesting enough, so questions if you want, you can also find me on MasterBone if you
want to engage.
Completely say it was yes, so basically I'm using this patch by setting every time I want an instance
of an SRS runtime, it gets added to this patch, by itself, and then the details to actually keep
the state that is important to me are transferred back and forth in the matches itself and
reprocessed in the places I need. So yeah.