Hi,
21.1.1 sec of RFC 3261 says as follows
This response (100 trying) indicates that the request has been
received by the
next-hop server and that some unspecified action is being taken on
behalf of this call (for example, a database is being consulted).
This response, like all other provisional responses, stops
retransmissions of an INVITE by a UAC. The 100 (Trying) response is
different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.
In this section the RFC says that 100 trying indicates the previous hop
that,
this hop is doing some processing related to the call. So for Re-Invite
also
if the processing of RE-INVITE message takes long processing time > 200s
(which involves accessing the database or something) then the proxy can
send
100 trying for the same.If the processing time < 200s then it need not
send
the 100 trying response. This depends on the implemntation and processing
of RE-Invites in the proxy.
Regards,
S.Kingston Smiler.
"Rajnish Jain" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/08/2006 03:09 PM
To
"Attila Sipos" <[EMAIL PROTECTED]>
cc
[email protected], sumin seo <[EMAIL PROTECTED]>
Subject
Re: [Sip-implementors] 100 Trying for Re-INVITE
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
*********************** FSS-Unclassified ***********************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
