currently I have implemented the script as stateful, using transactions (TM). It works .... *BUT* ... I get this SIP flow:

10.20.0.1:5060 10.20.20.1:5060

──────────┬───────── ──────────┬─────────

15:44:20.013645 │ INVITE (SDP) │

+0.002128 │ ──────────────────────────> │

15:44:20.015773 │ 100 trying -- your call is │

+0.007130 │ <────────────────────────── │

15:44:20.022903 │ 300 Multiple Choices │

+0.001481 │ <────────────────────────── │

15:44:20.024384 │ ACK │

+0.467452 │ ──────────────────────────> │

15:44:20.491836 │ 300 Multiple Choices │

+0.999940 │ <<<──────────────────────── │

15:44:21.491776 │ 300 Multiple Choices │

│ <<<──────────────────────── │

│ │

Why is Kamailio sending 300 Multiple Choices after the last ACK when it should have already "exited" from processing the call?

On the main route, i added:

if (is_method("ACK") ) {

# don't need to bother with ACK!

xlog("L_INFO","New SIP message $rm with call-ID $ci \n");

exit;

}

and the RELAY route is:

route[RELAY] {

xlog("L_INFO", " ******** RELAY *******");

xlog("L_INFO", "RELAY - $rm to $si responding back to $su");

send_reply("300", "Multiple Choices");

exit;

}

already tried multiple parameters, but no luck...still the same behaviour.... and setting logs to debug level, doesn't show anything:

Dec 23 15:44:20 kamailio1 kamailio[4050726]: INFO: {1 1 INVITE 1-2589892@10.20.0.1} <script>: RELAY_API - API ASYNC ROUTING REQUEST: {"from":"sipp <sip:sipp@10.20.0.1:5060>;tag=1","to":"<sip:1@10.20.20.1:5060>","r-uri":"sip:1@10.20.20.1:5060","contact":"sip:sipp@10.20.0.1:5060;transport=UDP>","call-id":"1-2589892@10.20.0.1","request-time":""}

Dec 23 15:44:20 kamailio1 kamailio[4050726]: INFO: {1 1 INVITE 1-2589892@10.20.0.1} <script>: RELAY_API - Calling Async Query to url http://IP:PORT/URL

Dec 23 15:44:20 kamailio1 kamailio[4050756]: INFO: <script>: RELAY_API_RESPONSE - RESPONSE: {#012#011"SOME HIDDEN JSON "#012}

Dec 23 15:44:20 kamailio1 kamailio[4050756]: INFO: <script>: ******** RELAY *******

Dec 23 15:44:20 kamailio1 kamailio[4050756]: INFO: <script>: RELAY - INVITE to 10.20.0.1 from sip:10.20.0.1:5060

Dec 23 15:44:20 kamailio1 kamailio[4050756]: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Dec 23 15:44:20 kamailio1 kamailio[4050756]: INFO: tm [tm.c:1686]: t_release(): invalid usage - not in request route

Dec 23 15:44:20 kamailio1 kamailio[4050727]: INFO: {1 1 ACK 1-2589892@10.20.0.1} <script>: New SIP message ACK with call-ID 1-2589892@10.20.0.1

and it ends with this last log message.....

any clue any one?

@Alex Balashov ... "How I Learned to Stop Worrying and Love the Stateful" .... love the title! :)

Atenciosamente / Kind Regards / Cordialement / Un saludo,

Sérgio Charrua

On Mon, Dec 23, 2024 at 4:39 PM Alex Balashov via sr-users <sr-users@lists.kamailio.org> wrote:

There aren't really too many fruitful uses of Kamailio sans TM. Most intentions to go fully stateless, while understandable and full of noble intentions, end up being abandoned once it becomes apparent that things like failover aren't possible.

The performance argument for stateless harkens back to a different era in computing and memory. The argument isn't, strictly speaking, entirely meritless in 2024, and one can go down academic rabbit holes re: DoS and such. But as a practical matter, just do stateful if you're relaying anything anywhere, or engaged in asynchronous complications.

There should be a book: "How I Learned to Stop Worrying and Love the Stateful"...

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: 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!