> -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 3:15 PM > To: Stucker, Brian (RICH1:AR00) > Cc: [email protected] > Subject: Re: [Sip] INFO > > 1. INFO for keep alive? That¹s a new one. Everyone I know > uses OPTIONS. Oh well. Maybe we should resurrect the PING method.
Well, you don't know Jack then. Jack uses INFO. :P Seriously, there are people out there using it this way. No negotiation is required. I'm not defending it, I'm just letting you know that there are a number boxes out there hammering away with INFO requests to see if a dialog is still active. Ask around and I'm sure you'll find people who have at least seen this done even if they don't generate the requests themselves. Honestly, I think we should all be using RFC-4028 and not OPTIONS or INFO for this purpose. If you want to put that in your draft, I'll happily support that. > > 2. INVITE discussion is a non-sequitur. INVITE fully > specifies a negotiation framework. INVITE without SDP is an > invitation for you to start the negotiation. Ok, so I send you an OPTIONS or an INVITE first to see what content-types/mechanisms you might support for DTMF transport. You tell me what you support, and then I use that mechanism (might be INFO digits). What's the difference? If I send you something you don't like or understand you can reject it. Sounds like a negotiation framework already exists. > > 3. The semantics of the media are totally orthogonal to the > INVITE negotiation. C.f. the LONG discussion on P-Asserted-Service. > > 4. The semantics of an INFO body is critical. The stack > needs to know how to process the body or where to pass the > message to. Right now, there is no mechanism for doing that. > Content-type does not work. So where do you think the stack sends SDP content types? You're making the claim here that the content-type can't be used to determine the semantics, or that the stack can't figure out how to handle it and must just simply choke and die because it was conveyed in an INFO instead of an INVITE. I'm probing to find the justification for that assertion. > > 5. "Just write it down": Agreed, and there has already been a > framework for doing INFO negotiation (Dean's document). I > was about to go there, until I realized that it would be > identical to SUB/NOT. > > 6. Rough work group consensus was NOT to create an INFO > negotiation mechanism. If you can convince the chairs > otherwise, I'd be happy to submit a negotiation mechanism. I don't remember it going down quite that way and I was at the mic expressing support. Perhaps I misunderstood the question that prompted the vote, but I interpreted it as meaning we didn't think one was NECESSARY. Big difference in my mind. Acknowledge the uses as they exist today, encourage people to look elsewhere for the future. I thought that was what we said at the last meeting. You're arguing that INFO w/ DTMF is broken because there's no negotiation mechanism. Sending DTMF with a given content-type and expecting the other side to reject that content type if it does not understand it is a basic tenet of SIP. You can clearly tell if the other side understands or not unless it is not paying attention to what it's being sent. > > 7. The argument that we have to extend INFO to do negotiation > because we need to protect the existing INFO-based DTMF > implementations is totally bogus. If we create a negotiation > mechanism, those existing implementations have to be fixed. > If they have to be fixed, any reason not to fix them with > something that already works and won't suck down work group > and RFC Editor time? I'm not asking to fix anything. Honestly, I think the vast majority of implementations are moving on to 2833/4733 to convey DTMF digits and to a great extent that makes the discussion somewhat moot in my mind. Whether this document exists or not will not affect INFO-based DTMF implementations. The horse is out of the barn and way down the road on that one. You've made some assertions in your arguments that I believe need some substantiation. You've said that the content-type is not enough to figure out what is going on at all. I disagee. I think a content type that says "I'm sending you DTMF digits in a particular format" is every bit as robust as the content-type that conveys MWI for instance, and a heck of a lot more specific than SDP is. We have done quite well with SDP for some time in getting things to work, so I don't understand why simply writing down: hey, this content-type means DTMF digits is not a valid way forward to closing the books on that implementation. We can even say things like "please don't do this in the future" but unless we can clearly show WHY people shouldn't do this in the future that uses logic that can also clarify the things that we DO want them to do in the future, I don't see how this can be successful. It appears arbitrary to say DTMF in INFO is bad because it relies on content-type settings to identify it as such when we do not require a P-Asserted-Service header in every INVITE to clarify the SDP that lies within. I think you may be confusing my questioning of your arguments as a declaration of support for using INFO for a particular purpose. I honestly don't care if another INFO is ever generated by any SIP stack anywhere ever again for any purpose personally. I'm looking for consistent arguments that can be applied to problems outside of INFO so when the next bad idea (tm) comes along we can clearly point to this document and say "you're trying to do X which we can clearly show is bad and does not align to the things we think are good." I haven't read such an argument yet. > > 8. Who in their right mind would use KPML for keep alive? > You can always subscribe to anything with an expires of zero. > It is still silly in any event [sic]. True. I completely agree. I didn't write that last statement correctly. I was intending to point out that INFO was being used this way. KPML has nothing to do with it. > > > On 9/10/07 11:46 AM, "Brian Stucker" <[EMAIL PROTECTED]> wrote: > > > > > > >> -----Original Message----- > >> From: Eric Burger [mailto:[EMAIL PROTECTED] > >> Sent: Monday, September 10, 2007 8:08 AM > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: [email protected] > >> Subject: Re: [Sip] INFO > >> > >> Brian Stucker Says: > >> I'm not really sure what your point was > >> here unless you are against people > >> writing down a common way of using > >> a protocol amongst themselves > >> > >> Actually, I have no problem with "people writing down a > common way of > >> using a protocol". One would offer that is the work of the IETF. > >> However, the key phrase I have a problem with is, "amongst > >> themselves." The IETF makes protocols for everybody, not > just members > >> of the garden club. The garden club can do whatever they > want inside > >> their garden. The IETF has no right nor interest in mandating what > >> goes on inside their garden. > > > > True, but it's not a club. Those disclaimers are to limit > reproduction > > of the material by other SDOs without permission. You don't > have to be > > a member of the garden club to use the protocols written by > the garden > > club, such as they are. Whether you want to or not is > another matter > > entirely. > > > > [SNIP] > > > >> In my mind, INFO for DTMF falls into the, "it is not an Internet > >> protocol, but you can do whatever you want in your playground, so > >> long as your fences are good and you will still play with > me. P.S., > >> do not claim you are using Internet protocols, because you > are not." > > > > Only because they happen to not be written down as an IETF > document, > > which, as I suggested earlier, may be the solution to the problem. > > > >> > >> P-Preferred-Service is an example of something that falls > into "the > >> toxic substance that will bleed through, so do not even think of > >> using it" category. > > > > So then I would be most interested to hear your thoughts on the > > following: > > > > The first sentence in section 2 in your draft states: > > > > "There is no programmatic way of determining what > the content > > of an INFO request means." > > > > You could say the same is true for an INVITE. To the 'User-Agent's > > point of view, an [INVITE] just appears'. Without a negotiation > > mechanism such as SDP, is this INVITE conveying an > conference call, a > > user-to-user gaming session, or what? We can't programmatically > > determine what an INVITE with no SDP means. So if I'm > following your > > argument here wrt INFO, the analogous solution would be to > deprecate > > INVITE unless it always has SDP. > > > > But wait, there's more... Again, using your line of thought > for INFO, > > SDP may not be good enough: > > > > "However, as we learned in the messaging community [7], > > relying upon the MIME type alone is not sufficient to determine the > > context of the message. Clearly, as shown in the previous paragraph > > [which describes using the MIME type of an INFO as a negotiation > > mechanism], the message content relates to the message context. > > However, it is quite easy to imagine situations where the > same content > > type has multiple meanings for a User Agent." > > > > So if the content relates to the message context, and the > content and > > type can be ambiguous, such as the INVITE contains SDP, or the SDP > > contains an audio stream (is it a conference or is it a podcast or > > what) or worse, SDP that contains content types that are not > > well-known, then clearly SIP and SDP are not enough to correctly > > identify what the User Agent is to do with this request. Hence, a > > mechanism such as P-Preferred-Service rears it's ugly head. > > > > As a result, if I understand you correctly, rather than correct the > > negotiation problem (more like just write it down because > it's already > > being neogitated out there in the wild in many cases) and > let the UAs > > deal with it, you'd rather deprecate the whole thing in favor of > > something else. Correct? > > > > Also, your list of examples is missing one usecase that KPML > > definitely does not address (but session timers does): INFO > is used to > > detect if a call is still alive. > > > > Cheers, > > Brian > > > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > _______________________________________________ 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
