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?
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 ). 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
