Picked up from rfc 3261 section 17.1: "The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction’s reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests."
The above explains why UAC must stop retransmission after receiving 1xx in case of INVITE. On Wed, Feb 3, 2010 at 10:35 PM, Iñaki Baz Castillo <[email protected]> wrote: > El Miércoles, 3 de Febrero de 2010, Pranab Bohra escribió: >> Hi Inaki, >> >> In addition to what Brett mentioned, the 1xx response includes "100 >> Trying" as well. >> 100 is a hop-by-hop response and not end-to-end. So, even if the >> client transaction has entered "Proceeding" state after receiving 100 >> from proxy, it doesn't mean that the UAS has received the request. >> Hence the retransmission. > > Thanks but this explanation doesn't make sense IMHO, let me explain: > > The same you say should then be applied for INVITE transactions as tue UAC > cannot know if the UAS has received it. However UAC must stop retransmissions > after receiving a 1XX response from the *proxy*. > > A retransmission just makes sense as hop by hop, so if the UAC has received a > 1XX response coming from the proxy, why should the UAC retransmit the request? > > > -- > Iñaki Baz Castillo <[email protected]> > > _______________________________________________ > 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
