23 Dec
2024
23 Dec
'24
11:57 a.m.
It's not stated, but I assume you'd have t_suspend() shortly after calling
`evapi_async_relay()`?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 10:23 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)evaristesys.com>
Subject: [SR-Users] Re: Kamailio not receiving packets on high CPS
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
On Dec 23, 2024, at 10:56 am, Ben Kaufman via sr-users
<sr-users(a)lists.kamailio.org> wrote:
This came off a bit more harsh than I intended. I think I understand the advantage of
EVAPI in that it can initiate a command to Kamailio (thus Kamailio doesn't need to
hold the thread, possibly it doesn't need to store the message even), but it would
still be nice to have a higher level overview of how this would be achieved. Not even
example code, but more a base architecture explanation / diagram of the flow.
It's probably not complicated enough to warrant a diagram.
1) EVAPI server is initialised:
loadmodule "evapi"
modparam("evapi", "workers", 3)
modparam("evapi", "bind_addr", "xxx:10399")
2) TCP client connects to this socket when it becomes available;
2) Kamailio receives request and serialises it (e.g. JSON), embedding the transaction ID
and label in whatever serialisation structure is used, then emits it on the EVAPI bus,
e.g.
evapi_async_relay("invite_request:$T(id_index):$T(id_label):$(var(data){s.encode.base64})");
3) TCP client reads this package off the wire; the built-in netstring support is ideal. It
then processes it, generates a response, serialises it, and puts it back on the wire.
Vitally, the $T(id_index) and $T(id_label) are embedded in the response, allowing Kamailio
to resume the transaction:
4) Kamailio receives this message in $evapi(msg), in this event_route, and resumes the
transaction into route[RESUME]:
event_route[evapi:message-received] {
...
jansson_get("tm_trans.tm_index", "$evapi(msg)",
"$var(t_index)");
jansson_get("tm_trans.tm_label", "$evapi(msg)",
"$var(t_label)");
t_continue("$var(t_index)", "$var(t_label)",
"RESUME");
...
}
5) In route[RESUME], INVITE processing continues as normal, enlightened by anything else
that was deserialised out of $evapi(msg).
EVAPI is my favourite Kamailio module, and the only way I interface with outside services,
when it's up to me.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!