23 Dec
2024
23 Dec
'24
11:01 a.m.
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(a)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(a)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(a)10.20.0.1} <script>: New SIP message ACK with call-ID
1-2589892(a)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(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!