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 <[email protected]> wrote:


It's not stated, but I assume you'd have t_suspend() shortly after calling `evapi_async_relay()`?



Kaufman
Senior Voice Engineer



E: [email protected]




 

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 <[email protected]>
Sent: Monday, December 23, 2024 10:23 AM
To: Kamailio (SER) - Users Mailing List <[email protected]>
Cc: Alex Balashov <[email protected]>
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 <[email protected]> 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="">
Tel: +1-706-510-6800

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- 
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!

Reply via email to