El Miércoles, 3 de Febrero de 2010, Pranab Bohra escribió: > 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.
I do understand the retransmission mechanism for INVITE transactions. However I still don't understant why a UAC should retransmit a MESSAGE/SUBSCRIBE after it has received a provisional response from the proxy (100 or 1XX). This is: alice ---- proxy ---- bob - alice sends MESSAGE to bob through the proxy. - the proxy replies 100 to alice and routes the MESSAGE to bob. - bob takes long time to reply (problems). - alice (according to RFC 3261) retransmits the MESSAGE. Why should alice retransmit the MESSAGE? it's obvious that the proxy *already* received it as it replied 100. It's the proxy who should retransmit the MESSAGE to bob until get a response. However I've found a case in which this mechanism is needed: - alice sends MESSAGE to bob through the proxy. - the proxy replies 100 to alice and routes the MESSAGE to bob. - bob replies 200. - the proxy replies 200 to alice but the message is lost due to network problems. - alice (according to RFC 3261) retransmits the MESSAGE. Is it? -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
