[NEW] Stateless and stateful replies - script handling
Using the new signalling module added by Anca, the reply handling is now
more simpler (from script and from the modules sending replies).
The issue that was solved is that all the modules were sending stateless
replies (internally). But from script, because of retransmissions (when
long processing for requests happened), many script writers were forcing
statefull processing (via t_newtran()) . This was leading to a bogus
behaviour (a mixture of stateless and stateful for the same requests) -
even if the transaction was created, the modules were internally sending
stateless replies, so the transaction was not updated. When a request
retransmission come, the Tm was detecting it and was trying to send the
last reply sent (as per RFC3261), but the TM was not aware of an reply,
so the request is simply discarded - and this mixture of stateless and
stateful breaks the SIP specs.
Typical example of how stateless/statful was used so far - if the
authentication processes take too long (DB, LDAP, etc delays), you want
to create the transaction for stoping the request retransmissions to hit
again the script processing:
This approach is currently used to protect (from processing the
retransmissions as normal request) several key points in scripts, like
authentication, registration, etc.
Now, all the modules are using the signaling module for sending replies.
This module is able to detect if a transaction was created or not and
use the appropriate way of sending replies (via TM or SL). All this
transparent for the script writer.
when the auth module sends the challenge, the reply will go statefully
(because the transaction was created via t_newtran() ). More or less, if
you create the transaction, all the following functions/module will
automatically switch to stateful processing.