Concerning 100 response for non-INVITE requests, see RFC 4320 since it updates RFC 3261.
> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Worley, Dale R > (Dale) > Sent: Wednesday, October 19, 2011 11:35 AM > To: Vineet Menon; [email protected] > Subject: Re: [Sip-implementors] sequence of response codes 100 trying > > > From: Vineet Menon [[email protected]] > > > > I have a general doubt regarding the sequence of response codes from > a > > proxy. When a proxy receives a request from an UA, say user1 destined > > to user2, then does proxy always sends back a 100 trying response to > > user1 before sending a 180 ringing? Or is it that 100 trying is only > > done in case of forking requests? > > Strictly speaking, a 100 response is never mandatory. > > A proxy should never generate a 100 unless it is transaction-stateful, > in that it remembers the request and takes on the responsibility for > retransmitting the request downstream until a response is obtained. > > If a 100 is sent, it should be sent immediately after receiving the > request. Although due to network delays, other elements may receive > 100 responses at any time after the request is sent, so there is no > way for other elements to detect if the proxy has sent 100 a long time > after receiving the request. > > If a proxy is transaction-stateful, when it receives a 100 it should > cease retransmitting the request. If a proxy is not > transaction-stateful, when it receives a 100 it should pass the 100 to > the upstream element. The first element upstream that is > transaction-stateful will "absorb" the 100 and cease retransmitting. > > RFC 3261 intends that 100 is never sent in response to any request > other than an INVITE because all other requests are supposed to get > final responses quickly enough that 100 is never needed to stop > retransmissions from the upstream elements. > > In the sipX open-source proxy (which is transaction-stateful), we've > found it useful in practice to send 100 responses to non-INVITE > requests when the proxy receives the second copy (first > retransmission). Strictly according to RFC 3261, this 100 should not > be sent, but also no proxy should receive a retransmission of a > non-INVITE request as the UAC will have received a response quickly, > but that often does not happen in practice We've never seen any > problem from sending 100 responses to non-INVITE requests. > > Dale > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
