Nah, it auto-suspends. Otherwise it'd just be evapi_relay(), not evapi_async_relay(). :-)

Sent from mobile, apologies for brevity and errors.

On Dec 23, 2024, at 11:57 AM, Ben Kaufman <bkaufman@bcmone.com> wrote:


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
img
img
 


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%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cf118d19ae9d94f167e4908dd236f007c%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705681871349908%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YXE7RBzUzZmKgT%2BrblxaxG5xQaucQrQNhBn7avAuWrw%3D&reserved=0
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!