Hello!
Two questions about suspended transactions:
1) What is the lifetime of a suspended INVITE transaction? Can I change it?
2) While a transaction is suspended, its event hooks (e.g. onreply_route, failure_route) do not run, of course, even if replies that match the transaction are received. Is there a way to intercept these replies externally and resume the transaction upon the receipt of the reply, and prior to the processing of the reply?
For example, can the replies be captured in a stateless route, and mapped Call-ID => index/label to t_continue() the transaction, then have the transaction state machine process that very same reply too?
t_is_retr_async_reply() seems to hint at this intention, but its scope is more narrow, if I understood the documentation correctly: it seems to deal with retransmissions only. The code path I'm interested in is more akin to a t_is_reply_to_async() function.
As you might guess, the driver for this inquiry is a mobile workflow where, in the vast majority of cases, one is contacting a stale registration and should just suspend the transaction, but where occasionally, in a small minority of cases, the endpoint does respond on the existing contact. The standard tsilo workflow of trickling parallel branches into a pending transaction doesn't work here because of the behaviour of Apple's CallKit; we have to try the existing contact _before_ we send a push notification.
-- Alex
Hello Alex,
I briefly looked to the code, and it seems that the asynchronous functions are having the fr_timer running. This is also indicated in the tm API docs.
About the second question, I am not aware of that, but it might be of course possible. Regarding the specific case, wouldn't it be possible to drop the response that is received and just wait until the transaction is continued again?
Cheers,
Henning
-----Original Message----- From: Alex Balashov via sr-users sr-users@lists.kamailio.org Sent: Thursday, April 3, 2025 4:59 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: [SR-Users] Behaviour of suspended transactions
Hello!
Two questions about suspended transactions:
1) What is the lifetime of a suspended INVITE transaction? Can I change it?
2) While a transaction is suspended, its event hooks (e.g. onreply_route, failure_route) do not run, of course, even if replies that match the transaction are received. Is there a way to intercept these replies externally and resume the transaction upon the receipt of the reply, and prior to the processing of the reply?
For example, can the replies be captured in a stateless route, and mapped Call-ID => index/label to t_continue() the transaction, then have the transaction state machine process that very same reply too?
t_is_retr_async_reply() seems to hint at this intention, but its scope is more narrow, if I understood the documentation correctly: it seems to deal with retransmissions only. The code path I'm interested in is more akin to a t_is_reply_to_async() function.
As you might guess, the driver for this inquiry is a mobile workflow where, in the vast majority of cases, one is contacting a stale registration and should just suspend the transaction, but where occasionally, in a small minority of cases, the endpoint does respond on the existing contact. The standard tsilo workflow of trickling parallel branches into a pending transaction doesn't work here because of the behaviour of Apple's CallKit; we have to try the existing contact _before_ we send a push notification.
-- 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!
Hi Alex,
I believe my script will act this way: 1/ forward to all contact + send push And do not call t_suspend if contact exist 2/ when all branch fails, call t_suspend (checking for conditions of failure)
In such cases, there is never requirements to handle response during t_suspend
I can verify next week, if asked!
Regards Aymeric
Antisip - http://www.antisip.com
Le mar. 15 avr. 2025, 19:47, Henning Westerholt via sr-users < sr-users@lists.kamailio.org> a écrit :
Hello Alex,
I briefly looked to the code, and it seems that the asynchronous functions are having the fr_timer running. This is also indicated in the tm API docs.
About the second question, I am not aware of that, but it might be of course possible. Regarding the specific case, wouldn't it be possible to drop the response that is received and just wait until the transaction is continued again?
Cheers,
Henning
-----Original Message----- From: Alex Balashov via sr-users sr-users@lists.kamailio.org Sent: Thursday, April 3, 2025 4:59 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: [SR-Users] Behaviour of suspended transactions
Hello!
Two questions about suspended transactions:
What is the lifetime of a suspended INVITE transaction? Can I change it?
While a transaction is suspended, its event hooks (e.g. onreply_route,
failure_route) do not run, of course, even if replies that match the transaction are received. Is there a way to intercept these replies externally and resume the transaction upon the receipt of the reply, and prior to the processing of the reply?
For example, can the replies be captured in a stateless route, and mapped Call-ID => index/label to t_continue() the transaction, then have the transaction state machine process that very same reply too?
t_is_retr_async_reply() seems to hint at this intention, but its scope is more narrow, if I understood the documentation correctly: it seems to deal with retransmissions only. The code path I'm interested in is more akin to a t_is_reply_to_async() function.
As you might guess, the driver for this inquiry is a mobile workflow where, in the vast majority of cases, one is contacting a stale registration and should just suspend the transaction, but where occasionally, in a small minority of cases, the endpoint does respond on the existing contact. The standard tsilo workflow of trickling parallel branches into a pending transaction doesn't work here because of the behaviour of Apple's CallKit; we have to try the existing contact _before_ we send a push notification.
-- 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! __________________________________________________________ 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!
-
Alex Balashov -
Aymeric Moizard -
Henning Westerholt