My comments inline... Regards, Nataraju A.B.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. Rangnathan Sent: Monday, June 05, 2006 12:30 PM To: Sip-Implementors Subject: [Sip-implementors] RFC 3265 : Why is subscribe not a three wayhandshake? RFC 3265 has a race condition where the NOTIFY can arrive at the subscriber before the Response to the SUBSCRIBE arrives -- and has to be allocated the same Dalog as the response to the subscribe. This results in a race condition which is a headache for protocol implementors ( like yours truly :-) ). Does anybody know why SUBSCRIBE is not a three way handshake like INVITE (with NOTIFY only possible after the three way handshake completes? ). Is there something with the protocol design of subscribe NOTIFY that forbids this? [ABN] one of the basic reason behind making INVITE a 3-way handshaking was that offer/answer model to complete on BOTH sides completely. Whereas here in SUB/NTFY case it's very much fine to make it 2-way and NOTIFY an additional message to complete the dialog on UAC side. The 200-SUB and NTFY serves almost similar same purpose for UAC. Also one more thing is NOTIFY is from UAS (with respect to SUBSCRIBE transaction) hence does not make 3-way scenario. I guess there is no open issue as such... Second question : what should the Subscriber do if the Subscribe transaction times out but the NOTIFY arrives ? Should the dialog be deleted (presumably yes as RFC 3265 may imply) ? If so, why? ( presumably the other end got the SUBSCRIBE and is hence sending you NOTIFY ). [ABN] if we do like this, then we have to mention it as an exception to statement mentioned in 3261 i.e., "every transaction will complete in itself request/response". Whereas the 2543 had the similar problem while handling INVITE and CANCEL. Sec 28.1 or 3261 << o In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now. When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally. A UAS needs to respond to the original INVITE request with a 487 response. >> IMHO its not a good idea to still go ahead if the response for SUB is not received while NOTIFY received. Thanks in advance for your replies. Hope the question is not confusing. Ranga -- M. Ranganathan Advanced Networking Technologies Division, National Institute of Standards and Technology (NIST), 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Advanced Networking Technologies For the People! _______________________________________________ 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
