INVITEs typically involve human intervention. Whereas, non-INVITEs are typically processed entirely within automata (humans can observe such events but not intervene). It is expected that automata will turn around in less than T1 - RTT, thus alleviating the need for provisional responses for non-INVITEs and re-INVITEs.
The reason why the spec language discourages issuing 1XXs for non-INVITEs and re-INVITEs is because that tends to open the can of worms of the need/possibility of canceling a pending non-INVITE or a re-INVITE. Canceling a non-INVITE or a re-INVITE will almost always cause a race condition. I can understand the argument that processing non-INVITEs such as REGISTER that may involve writing to a database or UPDATE/re-INVITE with an SDP change can sometimes take longer than 200ms (which is the guideline for generating 100 Trying by INVITE server transactions in RFC 3261). If there is no way to optimize the UAS, I don't see any harm in sending a 100 Trying for non-INVITEs (including UPDATE) in such cases. While discouraged, the non-INVITE server and client transaction state machines include the notion of 1XXs so its has been designed in and valid. Thanks, Rajnish > 8.2.6.1 Sending a Provisional Response > > One largely non-method-specific guideline for the generation of > responses is that UASs SHOULD NOT issue a provisional response for a > non-INVITE request. Rather, UASs SHOULD generate a final response to > a non-INVITE request as soon as possible. > > > (To be honest I can't remember why provisional responses are > discouraged for non-INVITE's, but I do remember it's importance > was strongly stated in several e-mails) > > > Regards, > > Attila > > > Attila Sipos > http://www.vegastream.com > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
