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]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>


________________________________
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=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<https://evaristesys.com/>
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