It's not stated, but I assume you'd have t_suspend() shortly after calling `evapi_async_relay()`?
Kaufman Senior Voice Engineer
E: bkaufman@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@lists.kamailio.org Sent: Monday, December 23, 2024 10:23 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!