Hi, Inline
>> 2. Dialog re-use causes problems. Having multiple usages within a >> dialog causes all kinds of confusing interactions between the >> usages. Even the ones that are well documented are seldom >> implemented correctly. (e.g., if I send a re-INVITE in a dialog >> that is shared with a SUBSCRIBE and get a 481, what >> is gone? The INVITE usage or the dialog? > >The dialog, as before, and also the subscription, since the >subscription would be tied to the invite's dialog. They >would share fate. [Christer] I agree. I am not even sure we should call it a subscription dialog, but a invite dialog subscription. We also need to remember that there is a difference in how an invite dialog and subscription dialog are created. Due to the forking rules for SUBSCRIBE, the receival of a NOTIFY can create a subscription dialog. An invite dialog is always created by a responses (provisional or final), and I don't think we want to change that. >> What it it's a 480? A 500? Even if _you_ know where to look it up, will implementors? >> Even if they do, are the rules sufficiently labyrinthine that the >> chances of misimplementation are high?) The "pushing my buttons" >> comment came from your implication that INFO was basically the >> same as NOTIFY in this context -- which is imperfect in myriad ways. >> For example: >> such a statement would mean that the INFO usage survives the >> termination of the INVITE dialog >> (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's >> probably not what you meant, but (except at the most superficial >> level) it's so far away from what you might actually want as to be >> a very poor starting point. > >Right, it's not what I meant. :) [Christer] Good :) If we only have one usage, the invite usage, everthing else would share the fate of the INVITE dialog. For example, when the 200 OK is received, and all other early dialogs are terminated, all "invite dialog subscriptions" related to those dialogs are also automatically terminated. >>Can this be salvaged? Yes -- and Dean's earlier proposal for INFO >>packages does so by making such things explicit. There's another >>question about whether it's worth salvaging, and I think that's a >>little less cut-and-dried (despite my strong opinion on the topic) -- >>but I'm boggled by the extreme pushback to making this negotiation >>explicit in the face of clear examples of how things break when we don't. > >I don't think anyone is pushing back against making negotiation explicit. > > >>(For the record: "Allow-Event" in an INVITE has very well defined >>semantics -- it means, "if you send me a SUBSCRIBE for this event >>package, I can send NOTIFYs". It is exactly backwards from the meaning >>"I can receive NOTIFYs of this type".) > >Yes I agree... didn't say otherwise. :) [Christer] One issue with the subscription mechanism is that when A is interested to receive events from B it sends a subscription to B. There is basically no good way for A to tell B "Hey, I have some events I would like to send you (if you support them), so please subscribe to them". For some applications B KNOWS it will have to subscribe to certain events from A, but in some cases B may again subscribe to events "just in case". I think it would be useful if A somehow could indiate which events it expects B to subscribe to for this specific call. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
