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.
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).
Regards,
Christer
Paul
Adam Roach wrote:
> On 10/30/07 10:52 AM, Hadriel Kaplan wrote:
>> I do assume from a SIP stack model perspective and its application
>> user that there would need to be some form of clear differentiation of
>> subscription Event Package support/usage, and one for Info-Packages.
>> So I guess separating these from Subscription-type Event packages
>> makes sense in that context. But does that mean one can't define a
>> new package that works both ways?
>>
>
> One could. [1]
>
> My argument is that one shouldn't. Because when one does, one creates
> two ways to do the same thing. Which means that implementors either
> choose a single mechanism (and fail to work with the other -- this is
> bad) or are forced to implement both mechanisms (doubling implementation
> cost -- this is also bad).
>
> Why are we putting forth mechanisms that force implementors to choose
> between two bad options?
>
> The examples you cite clearly work better in an INVITE context -- so
> define them that way, and leave SUBSCRIBE out of it.
>
> /a
>
> ----
> [1] One can also pound screws into wood with a hammer -- the measure of
> whether to do something isn't "can we", but "what happens if we do?"
>
>
> _______________________________________________
> 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
_______________________________________________
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
