Hi, I don't understand the race condition you are referring to. Can you please clarify?
About the new SUBSCRIBE within a SUBSCRIBE dialog scenario, are you suggesting that it is possible subscribe to different events using the same dialog? If so, then should this really be allowed and why? If it is allowed, why does it hurt to allow the new SUBSCRIBE to be a target refreshing one? (I haven't thought about this thoroughly, would it hurt when you are moving a dialog to another terminal. Can't think of the term used or the draft proposing that). These are the questions that we need scenarios for in order to answer. I think for INVITE, new INVITE within an INVITE dialog is always a reINVITE. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@;cisco.com] > Sent: Tuesday, November 05, 2002 4:52 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Questions about Dialogs > > > Hisham, > > I'm still thinking about the potential race conditions, so > I'm not yet prepared to take a strong position on this. But > *if* the issues exist, then I don't think your suggestion > solves them. Not only should you restrict to the method that > created the dialog - you should also restrict to the > particular X (I don't know what to call it - session, usage, > ...) on the dialog. Specifically, suppose a dialog was > created by a SUBSCRIBE, and then another unrelated subscribe > is done within the same dialog. If you are trying to restrict > what can update the target, then perhaps you should restrict > to just that first subscribe "session". > > Paul > > [EMAIL PROTECTED] wrote: > > > > May I suggest that we only allow target refresh requests to > have the same method as the request that created the dialog. > i.e.: only a reINVITE can be target refresh requests for a > dialog created by INVITE, only reSUBSCRIBE can be target > refresh requests for a dialog created by SUBSCRIBE. > > > > For a dialog created by INVITE, a SUBSCRIBE does not update > the target. For a dialog created by SUBSCRIBE, an INVITE does > not update the target. > > > > This is the only way to do it to avoid complexity and > confusion. Otherwise you got to start asking about REFER and > other extensions that create dialogs. > > > > I would prefer implementors to be able to build a generic > dialogs module in their stack that doesn't need to know about > methods. I mean what if I send a MESSAGE within a dialog? my > generic dialogs module no longer can be method agnostic > because it has to know that MESSAGE does not refresh a > target, but it has to know that SUBSCRIBE does... too complicated. > > > > In my suggestion, a dialog state would include the method > that created the dialog, call it dialog-method, and only > requests with methods that match the dialog-method are target > refresh requests. > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
