[OpenSIPS-Users] [RFD] Unified way of sending SIP replies from modules

[Bogdan-Andrei Iancu]

Hi everybody,

I want to propose an enhancement in the way SIP replies are being sent 
from inside the modules.

At this moment, almost all of the modules send stateless replies, so 
retransmissions are not properly handled and even worst a retransmission 
will be fully processed again as a standalone request.
This is a big issue when we have function performing some time/resource 
consuming ops before sending out a reply (like registration functions,, 
authentication functions, presence functions, etc).
The current workaround is to create from script a dummy transaction for 
the processed request. The problem with this approach is that the 
transaction is not aware of the reply sent out by the modules (as done 
statelessly),so any following retransmissions will be absorbed, but no 
reply will be sent to the client.

The solution will be to have a new  module that comes as a wrapper over 
tm and sl modules and offers one function to be called by the modules 
that want to send a reply. To solve the problem above, the module will 
first search if a transaction is created and if so, send a state full 
reply, using tm module, otherwise send a stateless reply with the 
function exported by sl.
In this way, the script writer still has the call on how the transaction 
should be handled, state full or stateless and the reply is send 
accordingly to his choice.

For example, if you do a t_newtran() in the script before doing save() 
(for registration), the function will automatically send the reply in 
stateful mode as a transaction is available. If no transaction is done, 
the reply will be sent in stateless way (as now).

By doing this, we have the possibility to have same module sending 
either stateful either stateless replies, by just controlling this from 
the script (if we create or not a transaction).
So, the signalling will be more coherent as the replies will be sent 
according to the transaction presence (or not).

Moreover, this module can also offer the possibility of loading only one 
of the module, sl or tm, and send reply using only the module that is 
loaded. This is useful as not in all cases a user desires to send 
stateful or stateless replies and he should not be forced to load the 
module only because the send reply interface requires it.

Before moving forward, any comments or opinions are welcomed on this topic.

Regards,
Bogdan