Hi, >>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.
I am not defending the usage of INFO for this either, but I see no reason why we should forbid things which are absolutely harmless. Let's focus on real issues instead. >>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. I agree. Regarding the question how to know where to pass the message internally. I think that is an implementation issue, and you have to deal with that also if using other mechanisms. >>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. My understanding of what was decided at the mic was that we were going to continue the discussions. Eric's draft was going to be used as base for the work, but that does not mean we agreed to everything which is said in the draft. >>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. We seem to be concentrating on DTMF, but I think we should be more generic. The question is whether we should allow INFO as a mechanism (limited, maybe) to transport information. The answer seems to be "No, you can use subscription events.". But, there are reasons why people don't want to use that. 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
