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://evaristesys.com
Tel: +1-706-510-6800