Hey Adam, Comments inline... > -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 11:26 AM > > The problem isn't _in_ that direction. The problem is: how do I say "I > am capable of receiving DTMF digits in an INFO message"? > > The "Accept" header-field lets you say you understand the syntax, but > doesn't convey what contexts it makes sense in.
When you say "doesn't convey what contexts it makes sense in", in what way do you mean that if the topic is DTMF? Do you mean because it doesn't specify which methods it's acceptable in (e.g., INFO)? Or do you mean because it won't indicate that an INFO with DTMF is only acceptable in the context of an Invite-based dialog, for example? I ask because the argument of "not conveying context semantics" has come up a few times, and I'm trying to figure out if the problem is one that can be solved by standardization, or if the problem is something bigger. When I think of "context", I think of it in a bigger sense than protocol syntax, and more of application semantics. But DTMF has no such semantics at the UAC. The UAC has no idea what a button push means from an application perspective, beyond just "the user pressed #". There is a protocol issue, though, in terms of "if and how do I tell someone the user pressed #". But I think that's something that can be solved. > The "Allow" header-field lets you say you can process INFO for some > mime-types, but doesn't let you say which ones. > There is no current mechanism that lets you tie the semantics together, > the way that event packages do. I've shown, in previous messages, how > this can lead to ambiguity and consequent interoperability failure. I agree with you, but that problem already exists today. There are plenty of cases where there are constraints on the combination of method+mime that cannot be described with Accept and Allow headers. There are devices which won't accept Invites or re-Invites without application/sdp, and there are devices which don't accept Options with mime types they do accept Invites with, etc. (You can call them broken I guess) What does it mean for an application/sdp mime body to be in a Message method, or in a Bye? I also think for this dtmf case, we can define the usage for application/dtmf such that it is tied to a specific method, in specific session contexts. (or not) > To be clear: I don't really care much whether we come up with INFO > packages or whether we formally deprecate INFO, but the current > situation is untenable. I guess that's the $64k question: is the current situation untenable? If we think rfc2833 will ultimately become ubiquitous and address the application needs, then we don't need to worry about this. There are devices that already convert 2833 to Info and vice versa, and they'll be happy to keep doing so for the short term. If we think 2833 is not going to solve this problem ultimately, or the application usage for dtmf is not possible by 2833 for all cases, then I think we need a solution. KPML isn't it, IMHO. -hadriel _______________________________________________ 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
