Re: Behaviour of suspended transactions

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 <
[email protected]> 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 <[email protected]>
> Sent: Thursday, April 3, 2025 4:59 PM
> To: Kamailio (SER) - Users Mailing List <[email protected]>
> Cc: Alex Balashov <[email protected]>
> 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 --
> [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!
>

__________________________________________________________
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!