On Dec 23, 2024, at 10:56 am, Ben Kaufman via sr-users sr-users@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