RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO)

["Christer Holmberg" <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip