Christer Holmberg wrote:
Hi,
OK. Adam has persuaded me that overlap with relevant existing event
packages is negligible (none, or perhaps KPML - more on that later) and
that recommending that new ones be created to support two mechanisms is
a bad idea.
So that leaves the question of whether to nail down a negotiation
mechanism for "info-packages".
The obvious first case to consider is DTMF. The problem of course is
that we already have two standard methods for transfering DTMF
(telephone-events in RTP, and KPML subscriptions.) So standardizing use
of INFO for this would mean standardizing a *different* way than KPML.
And most likely it would be different than the non-standard way(s?) of
using INFO for DTMF in the wild. Is that going to do anybody any good,
or just give people more heartburn? Perhaps we should either bless what
is being used or else continue to treat it with benign neglect.
Once you get past that one, I think we might as well wait until somebody
has something else they want to exchange this way to before getting too
caught up in inventing machinery.
I think we should invent the machinery, and HOPEFULLY people will then start
implement it instead of the non-standard way.
My original thinking was that this was just a lightweight way to
establish a slightly restricted subscription. I was thinking of it as a
way to use an existing event specification in a particular sub-case
where you knew you wanted the target and duration to be the same as your
invite. That is why I thought the same event package definitions would
apply.
That is no longer the case. This is a new thing. As such, it needs to
define its own scope of applicability. There must be a way to say: "THIS
new behavior should be done as an info-event because ..., and THAT new
behavior should be done using an event/subscription because ...".
What do we use to decide on that scope? We need some use cases. Other
than DTMF, do we have any? And for DTMF, do you know how to partition
those cases that should use this technique from the other two standard
techniques and N non-standard techniques?
I also know that other SDOs are looking into using INFO for certain things, so
I think it would be really good to define a proper mechanism before they also
start to use INFO as it's used today (with all the problems people have listed).
Could you be more specific? I'm guessing you are talking about 3GPP?
We keep getting into trouble with 3GPP because we are asked to provide
mechanisms without use cases and clear requirements for the mechanism.
Paul
_______________________________________________
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
