3 feb 2010 kl. 19.32 skrev Iñaki Baz Castillo: > 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 think that is it. It makes sense to me. /O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
