I have not found any situation, where t_flush_flags() is needed. If I set a flag after t_newtran() and then call t_relay(), the flag stays set both in failure route and reply route. If there exists a case, where t_flush_flags() needs to be called after t_newtran(), it should be mentioned in README in order to avoid needless calls of t_flush_flags().
Looked in the code and the flags are resync'ed on t_relay() (or the similar relay functions), that happens because of:
* https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_lookup.c#L...
And t_newtran() is executed inside t_relay_to():
* https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_funcs.c#L2...
The behaviour is coming via SER project, based on the comments there.
I am going to add the same for xflags.
On the other hand, the t_flush_flags() might still be useful for the case when the transaction is created, but not forwarded (e.g., local handling or, even I haven't checked the code, could be the case of suspending the transaction), so I am going to keep the functions, but document that they are not needed if the transaction is forwarded with t_relay() or similar functions.
Daniel-Constantin Mierla writes:
Looked in the code and the flags are resync'ed on t_relay() (or the similar relay functions), that happens because of:
Makes sense, since it greatly simplifies scripting.
I am going to add the same for xflags.
Thank you very much.
-- Juha
Closing, the patch was pushed to master. If still not working as expected, reopen.
Closed #1490.
-
Daniel-Constantin Mierla -
juha-h