Do you mean this in the context of: "are there any registered 3265-type events which would be useful for this?" Or do you mean this in the sense of: "are there any events in general which would be useful for this?"
For the former, I tend to agree with you. I don't see any registered 3265 events which would really be useful for tying to an Invite dialog in an INFO. For the latter, we've already been discussing one: dtmf. The next obvious one would be ISUP info exchange (though it's not as clear if it's needed). But one can also envision future ones. For example a way to perform a traceroute type thing across b2bua's (like incrementing max-forwards, but not identical). Or a package for sending vcard info to the caller/called. Or a package for giving out a jpeg for photo-id, or for call screen display. Or a package for soft-key maps for a specific call (like a call to a vmail server). Or a package for giving out an HTTP URL for simultaneous click-to-web-browsing with call. Or a package for sending a "failed media path" indication. Or a package for sending instructions for a SIP-based game. Can some or all of these be done with Subscribes? Sure. And for some I think it probably makes sense to ONLY allow it in subscribes/publish/whatever. But for some of those, or for something in the future, it may make more sense to only exchange it in the Invite dialog it's related to, without the overhead of a Subscribe dialog. 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? -hadriel > -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 12:10 AM > To: Dean Willis > Cc: Sanjay Sinha (sanjsinh); sip List > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > Dean Willis wrote: > > > > On Oct 28, 2007, at 4:58 PM, Adam Roach wrote: > > > >> Dean Willis wrote: > >>> Seriously, this stuff only makes sense for fairly atomic events. > >>> Partial notification just doesn't compute. That's why it would be > >>> silly to say it works for all event packages. > >> > >> You misspelled "any." > >> > > > > No, I don't believe so. It would, for example, function quite well > > with MWI (although not be terribly useful). > > Which is pretty much my point. I assume you picked a useless example > because there isn't a useful one. Is there anything better? Let's check > the IANA registry. > > Conference? That doesn't seem to match you assertion that "partial > notification just doesn't compute." Or are you thinking you'll be > passing full conference state around in INFO? > > Dialog? No, you're in the dialog -- you know how it's going. > > KPML? That uses a lot of the SUBSCRIBE mechanics to set up what triggers > notification. And if the endpoints are interested, send 2833/4733. > > MWI? I agree with what you say above -- not terribly useful. > > POC settings? You're in a call with the device -- it no longer matters > whether it will auto answer or whether it's going to bar you from calling. > > REG? This gets heavily into the authorization questions Robert was > raising (unless you're talking to yourself, in which case it's downright > silly) -- and even if we blithely wave our hands at auth and say "send > it if you like and don't send it if you don't," what is the use case? > Why would someone do this? > > Refer? Spirits? Winfo? What would those even *mean*? > > We've been working on this for the past 7 years, and there's not a > single reasonable proof of concept that what you're fighting so > vigorously for has any practical application. The best example you can > come up with is one you concede is useless. Robert has raised a host of > reasonable concerns, and I've been pointing out additional sets of > problems that arise from your proposal. > > We know the downsides, and they are non-trivial. To make a fair > judgment, we need to balance those against the benefits. What are they? > > /a > > > _______________________________________________ > 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
