Comments inline... Thanks & Regards, Nataraju A.B.
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, June 05, 2006 9:22 PM > To: Nataraju A B > Cc: 'M. Rangnathan'; 'Sip-Implementors' > Subject: Re: [Sip-implementors] RFC 3265 : Why is subscribe not a three > wayhandshake? > > > > Nataraju A B wrote: > > -----Original Message----- > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 05, 2006 6:55 PM > > To: Nataraju A B > > Cc: 'M. Rangnathan'; 'Sip-Implementors' > > Subject: Re: [Sip-implementors] RFC 3265 : Why is subscribe not a three > > wayhandshake? > > > > > > > > Nataraju A B wrote: > > > >> 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. > > > > This does seem to be a fuzzy case. There are some scenarios where all > > could be well in this case. > > > > Suppose the SUBSCRIBE goes through a proxy that doesn't Record-Route. > > The SUBSCRIBE makes it to the UAS, which then sends a 200 and a NOTIFY. > > The 200 is sent back along the Via path, while the NOTIFY is sent > > directly to the Contact. If the proxy has crashed before it forwards the > > > > 200, then the 200 will never be received, but the NOTIFY can cause a > > quite acceptable dialog to be established between UAC and UAS. > > > > In cases when the 200 *is* received, it establishes *one* dialog, and > > there will normally be a NOTIFY received on that same dialog. But that > > NOTIFY may be received *before* the 200, and in addition if the request > > was forked, additional NOTIFYs may be received that establish other > > dialogs. When you receive the first NOTIFY of each dialog, and haven't > > yet received a 200, you have no way of knowing whether a 200 is expected > > > > on *that* dialog or not. So you don't know *which* dialog to delete. > > > > I guess it is possible to make a case either way on this, but I would be > > > > inclined to retain the dialog if I received the NOTIFY. > > > > [ABN] I almost agree with you, but in that case it would be a deviation > > from general statement "every transaction must be completed with a final > > response". > > I see no exception here. The SUBSCRIBE transaction does eventually fail, > with an implied 408 if necessary. The question is what happens as a > result of that. The UAC can conclude that the (half) dialog created by > sending the SUBSCRIBE is now gone, but that doesn't impact any of the > actual dialogs established as a result of the NOTIFY(s) received. > [ABN] probably this will lead to an open issue, what should be the correct behavior from UAC when timeout or error response received on a completed dialog... but still (as of now) this is a little bit deviation from normal transaction/dialog completion procedures. I mean complete the dialog from a different request than from it would have happened with an associated final response..? Also I feel many of the current implementations may not support this functionality of complete the dialog on NOTIFY and discard the 408 on the completed dialog... > *If* there had been a provisional response to the SUBSCRIBE, that had a > to-tag, then that would have established an early dialog. If so, and if > a NOTIFY had been received with the same to-tag (before or after), then > it might be appropriate to declare that dialog dead, and attempt to tear > it down by sending a reSUBSCRIBE with a zero expiration time. But > normally there will be no provisional responses, except perhaps a 100. > > Paul > > > Is this ok ??? > > in that case do we need to mention this deviation in the RFC ??? or > > probably this scenario could also be included in exceptional procedures > > draft ??? > > > > Paul > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
