Hi Gilad, I hear what you are saying, and if you really want to compary INFO to implicit NOTIFY, you should also remember that in some cases INFO messages will be sent in both directions, so doesn't that mean you would have TWO subscriptions (one for each direction)? But, in order to avoid unecessary discussions I agree with Paul that we shouldn't continue onto that path :) A couple of other comments, though:
First, you say "Of course it's not possible to say which INFO messages to receive". If you indicate which content types you support, you know what you COULD receive in INFO (if someone sends you something you haven't indicated support for it's a protocol error). Second, in an earlier mail you said that if we want to use INFO we should still use the XML format as specified in KPML. The INFO implementations I've seen do not use XML. E.g. Cisco seems to simply send something like "Signal= 1 Duration= 160". I am not sure, but I think there was a draft on that a long time ago. Personally I think't it's a little "overkill" to send an XML body just in order to provide a DTMF digit (and possibly additional duration information). But, as some people say about SIP messages: size doesn't matter :) Regards, Christer > -----Original Message----- > From: Gilad Shaham [mailto:[EMAIL PROTECTED] > Sent: 15. kesäkuuta 2007 0:37 > To: Paul Kyzivat > Cc: [EMAIL PROTECTED]; Christer Holmberg (JO/LMF); [email protected] > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > I never said that I endorse it... > > Neither am I saying that INFO is implicit NOTIFY. I'm saying > INFO's functionality is notification on INVITE dialog usage > without subscription. > > I agree it's an odd way to look at it (hence my comment on > stupidity), but here is the analogy (bear with me): > Suppose an implementation requires information during the > lifetime of the INVITE dialog, something related to the call > itself. The normal way of doing this is implementing an event > package, something that holds the call-id, remote-tag and > local-tag of the INVITE dialog to which it references. > One could say that this is a lot of work, why not send the > information on the INVITE dialog itself? Hence INFO roles > into the game. > It _does_ the same functionality from user's perspective. > Implementers will find it much easier to do and it seems as a > legitimate method for communicating this information. > > Of course it's not possible to say which INFO messages to > receive as opposed to event notification which are specified > in the subscription. > Hence the implicit subscription (or lack of explicit subscription). > Furthermore, as Dale pointer out, there is nothing similar to > Event header, only the content-type tells what type of > notification is this. I already said this is a problem with > INFO, but some disagree and say that content-type is enough > to hold the same information. > > That's at least my understanding of what's proposed here: > KPML provides information on DTMF events that occur during > the lifetime of the INVITE dialog. The events are sent in > NOTIFY and the event package itself refers to the invite > dialog with call-id, remote-tag and local-tag. One could say > that the same information can be passed in INFO and it's > easier to implement. No one subscribes to this information, > somehow the subscription is implicit. > > If the logic of the analogy is correct, I think it has > implications on INFO. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 14, 2007 8:52 PM > > To: [email protected] > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > > > > From: Paul Kyzivat <[EMAIL PROTECTED]> > > > > If you start down this path (I'd rather not), then rather than > > considering INFO to be a notification of an implicit subscription > you > > might was well use NOTIFY for an implicit subscription. > > > > In particular, NOTIFY is labeled with an event-type, so the > recipient > > knows whether or not it knows how to process the event. > > > > Dale > > > > > > _______________________________________________ > > 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
