Hi, >>There is a big difference between specific additional uses, defined on
>>a one-by-one basis, and *generic* usage. >> >>I don't know how to view generic usage as anything but an explicit >>move to support SIP as a tunneling protocol. And I think that is >>something that many people here *don't* want it to become. >> >>Opening it that way would pose many of the same issues that the >>Service-ID did. >> > >I'd argue we already used that can of worms for fishing when we did >RFC 3265. Event packages provide a nice way of using SIP as a >transport protocol, wrapped up with nice safety padding so one is >less likely to hurt one's self using them and so that the >application using the transported data is properly isolated from the SIP state >machine. > >The real question is whether there's a real requirement to do the >same thing for INFO. I think INFO pretty much already does the same thing. It is written that it shall not affect the SIP state. >As has been pointed out, it's possible to do anything that you can do >with INFO by doing a set of subscriptions (possibly MANY >subscriptions) in parallel to an INVITE dialog usage. Especially >since GRUU gives us a way to make the subscription endpoints >the same as the INVITE endpoints. > >So we're just talking about efficiency here, not functionality. My understanding (maybe it's because of my background in H.248) of an subscribed event is that something somewhere triggers an event which I have requested to be informed about. In most cases I don't think that sending DTMFs between two SIP entities fits that concept. If two applications are exchaning data I don't understand why I, as the caller, have to tell the other party to send me a registration so that I can send him the data. The subscription is not used in order to be informed about detected events, but in order to be able to send data. BUT, if I e.g. control a media server using SIP, I could use an event registration to request to be informed about DTMFs detected on a media stream. In that case the DTMF may not be seen as data exchanged between two applications (and may not even be directly associated with another SIP dialog), but more as an indication. But, maybe that's more of a conceptual discussion than functional... >With what we've been talking about with INFO, it should be possible >to declare support for many different INFO usages within a single >INVITE dialog. This has the potential to make the INFO approach >substantially more message-efficient than SUBSCRIBE/NOTIFY, which in >most cases is going to require at least one subscription in each >direction, and in some cases many subscriptions in each direction. Exactly - subscriptions which you MAY end up never using, but which in many cases still will consume SOME resources. >The real question -- aside from the officially-sanctioned PSTN >transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY >THIS WG) DTMF are any applications being developed that need this >sort of efficiency? > >My personal feeling is that if it is available, INFO will be used. >Sometimes wisely, sometimes unwisely. But I can imagine myriad >applications that could usefully accompany a multimedia session with >little snippets of data being schlepped back and forth. I can also >imagine doing the same thing with a parallel MSRP session. I am sure all mechanisms we define have their pros and cons, and it's difficult for us to say that a specific application must use a specific mechanism etc. Our job is to define the tools for the application developers, and hopefully they will then be able to choose the most efficient tool, based on the characteristics, efficiency etc of the tools. And, I doubt anyone would use INFO for a real-time chat type of applications, with lots of relatively small messages, since it would overload intermediates. But, it's difficult for us to draw a clear line on what people can do and can't. Regards, Christer _______________________________________________ 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
