> 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
