2012/4/10 Paul Kyzivat <pkyzi...@alum.mit.edu>: > But this can be useful/important in certain cases. The one I have > thought about is NOTIFY. If you have a dialog event package where each > notification sends complete state, then it could be appropriate to send > a notify each time the state changes, even if an outstanding notify > hasn't completed. If the earlier one fails (500) because it arrives > late, that can be ignored by the UAC because the later one will provide > what is needed. But this isn't an appropriate strategy if the > notifications provide only incremental state changes. In that case the > UAC really needs to wait for one to complete before sending another. > > A case where this might arise incidentally is if a dialog is being > shared by multiple dialog usages. For instance, consider case where you > have an INVITE dialog usage, and send a REFER within it, resulting in a > refer event subscription sharing the dialog. Differing application > components might be dealing with these asynchronously, so that you might > have notify messages being driven by state changes in the call resulting > from the refer, and independently you might need to do something in the > invite dialog usage (e.g. a reinvite due to session timer.) As long as > the messages all are delivered in order this should work out. But if > they cross it will make a mess.
right... it can become really hard for the SIP stack developer :) >> Does it depend on the in-dialog request method of IN-DIALOG-1 and >> IN-DIALOG-2? Some cases: >> >> >> 1) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = BYE >> >> Should bob reply 200 to the BYE and later a final response for the INVITE? > > IMO this is legal and meaningful. Clearly there must be responses to > both messages. It would be simpler for the UAC if the INVITE got a final > response before the BYE. But I suppose that isn't required. ok > Note that RFC 5407 addresses this to some extent, showing some obscure > cases. Will check it. >> 3) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = OPTIONS > > According to 3261 section 11.2: > > An OPTIONS request received within a dialog generates a 200 (OK) > response that is identical to one constructed outside a dialog and > does not have any impact on the dialog. > > But I have found that requirement to be un-helpful. It clearly must > affect dialog state in that it changes the last-sent/last-received cseq > value. (And there is some question whether an in-dialog OPTIONS should > get a 481 response if the dialog is not known to the UAS.) > > In this context I see no reason not to respond to the OPTIONS in a > normal way. ok Thanks a lot. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
