Answering a little bit of your scenario and a little bit of Francois':
1. Support must be explicit. Everything described so far makes
indication of the ability to receive an INVITE (or NOTIFY in
Francois' case) implicit in circumstances where such an
implication can be accidental. There are legitimate situations in
which any of the proposed heuristics used to perform such an
implication may legitimately exist and yet not mean that the
recipient is requesting INFO (or NOTIFY) requests.
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? 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.
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.
/a
(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".)
Hadriel Kaplan wrote:
Yeah, that's what I meant when I said in an earlier email:
"But I think that is something that could be standardized away if we needed to. One
way could be to define an Event package type model for it. One could argue Info is
essentially a Notify, except in a subscription implicitly created by, and tied to the
dialog from, an Invite."
But Adam didn't seem to like it. Not sure why. Adam?
-hadriel
-----Original Message-----
From: Francois Audet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 7:14 PM
To: Christer Holmberg; Dean Willis
Cc: IETF SIP List
Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip]
INFO)
(d) they think it's a waste of resources to establish
multiple additional subscription dialogs (there may be other
type of data than DTMF they are willing to receive) which in
many cases may not even be used during the call (it can not
be assumed that the one sending the subscription always knows
exactly when it will receive events). Maybe DTMF is not the
best example in the world (my fault - I should have been more
generic), but I am sure there could be events which would not
be used in a very high percentage of all calls, but still the
additional subscription dialog(s) would have to be
established - just in case.
Maybe a way to subscribe to packages within an INVITE dialog would
be suitable. You then would get the NOTIFYs withind the dialog, and
they wouldn't be out-of-the-blue because you would have subscribed
to those events explicitly with some Allow-Event in the INVITE.
I know many people will hate this idea but, I do agree with Christer
that subscribing to an event package "just in case" when it normally
is not used is quite a huge overhead and explain why people just
use INFO instead.
I still strongly think it would be much better to describe
the issues/advantages/disadvantages with BOTH INFO and
events, and study what possible needs to defined related to
negotiation etc, instead of just ignoring the real world and
providing flexibility to people using SIP for their applications...
I think the idea above would address this and avoid the INFO pitfalls.
_______________________________________________
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
_______________________________________________
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
