Hi, See Inline
Gilad Christer Holmberg wrote: > >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. You do not tell the other party to send registration so you can send him data. The other party asks for this data and you send it or vise versa. Some of us are saying that the lack of ability in SIP to state which INFO messages each ends wants to receive, it is a major drawback. As long as new RFCs don't focus on INFO, this problem is usually limited, but if we use INFO more broadly it's a real issue. > > 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... > I'm not sure I understand what you mean, but it sounds to me as if you are describing a solution to the issue of specifying which INFOs are required. > >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. > And if it would have been possible to subscribe to many different event packages in a single message, would that be an equivalent solution? > >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. > Right. Currently if extended usage of INFO is needed, it's not well defined and there are several problems to resolve. We might have been taking this conversation to the wrong direction. If some feel that SUBSCRIBE/NOTIFY might be too complex in some situations, I think we should discuss it outside the context of INFO. INFO is just one solution to this problem. If the best solution in this case would turn out to be INFO, we will be more motivated to fix its problems. I don't see a reason to "reverse engineer" a proprietary solution that some vendors took that involved INFO at the time. We need a problem definition. Whether or not the end solution will be similar to the vendor's solution is irrelevant. _______________________________________________ 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
