Hi Paul, >>>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 ...".
It's up to the one defining the event packages to describe those things, and to say whether an event package is applicable for info-events and/or subscription-events. >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? That's for the implementors - not us - to decide. We provide the tools, and a clear definition on how they can be used etc. And, I think DTMF IS a very valid use-case to start working on this mechanism. The issues has been around for years, and it won't go away. Another use-case I've seen is related to interworking, where certain H.245 messages are mapped into INFO. Another use-case I've seen is related to video control, where INFO is used to control video-type-of applications. Another use-case is of course ISUP transport, and other type of PSTN/ISDN information. Other use-cases are when application are exchaning some data (e.g. the here-is-a-jpeg example which comes up all the time :) between themselves. These kind of use-cases will most likely grow as the number of applications grow. Applications can of course also exchange data by setting up a data channel, but there may be cases where the amount and frequency of data is not that large. And, we don't know how many such applications there already are out there. If we provide a standardized tool, people will hopefully bring those to IETF. Another use-case (and you're going to love this one :), is SIP overlap dialling. Some organizations have proposed requirements to optionally support SIP overlap in IMS. Currently TISPAN is studying two mechanism. One is based on the RFC, where a new initial INVITE is sent when more digits are provided. The other mechanism is based on, once an early dialog has been established with the remote peer, sending the additional digits in-dialog, and INFO is obviously one of the candidate methods for providing the additional digits. >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? At this point I think it's more TISPAN, but much of the work will probably end up in 3GPP sooner or later. Unfortunately I am not involved in that work, so I can't give any details. >We keep getting into trouble with 3GPP because we are asked >to provide mechanisms without use cases and clear >requirements for the mechanism. And when 3GPP does provide use-cases we start to argue against them... Anyway, that is another topic, so let's not get into that discussion here and now. 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
