Hi Christer, See inline.
Thanks, Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] > Sent: Friday, June 15, 2007 7:24 AM > To: Gilad Shaham; Paul Kyzivat > Cc: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > 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 > :) I agree there are cases where there are 2 actual subscriptions. One unfortunate implication of this implicit subscription. I don't think we should draft a proposal for implicit subscription - certainly not. I fear we are already on that path. We went on that path as soon as INFO was allowed. We just didn't say so, but effectively we implemented this functionality. If I'm right then I cannot understand how one can oppose implicit subscriptions and endorse extended usage of INFO at the same time. If I'm wrong it means that there is some kind of additional functionality of INFO which I missed. I prefer that someone would show me what's basically wrong with the analogy or my conclusions instead of why implicit subscriptions are a bad idea. > > 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). Yeah, it possible, same discussion as before regarding content-type and info type applies. > > 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 :) > I don't like the idea that multiple formats will be defined in RFCs for the same functionality. Maybe it's just me, but I think that in this case "the more that merrier" does not apply. > 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
