Christer, Slightly aside from the main direction of the discussion, but what about security? I send my audio using SRTP, and would expect DTMF to receive exactly the same protection. The signalling may or may not be end-to-end secured, depending on which of the current and future key management methods are used. Maybe SIPS has to be used, but we all know the limitations of that (e.g., if I receive an INVITE request to my SIPS URI, can I be sure all hops are secured?). I am sure the IETF would not want to endorse a mechanism that opens up a security hole that is not present with an existing mechanism for doing the same thing (RFC 2833).
John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 14 June 2007 10:20 > To: Paul Kyzivat > Cc: SIP IETF; Dean Willis > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > Hi, > > >>I don't think an application will trigger INFOs in a spray and pray > >>matter. You will only send media server control messages if you are > >>communicating with a media server control application that > >>understands them. > > > >How does my phone know it is communicating with a media > >server that understands INFO for conveying DTMF? The thing I > >call may indicate support of INFO because it supports qsig tunneling. > > It should also indicate support (using the Accept header) of the > content-type which is used to transport the media control messages. > > >>>Before you send a DTMF/INFO, you really need to know that the > recipient understands DTMF/INFO in general and the > >>>specific encoding of DTMF in INFO that you're using (there > have been > >>>multiple encodings proposed). > >> > >>Yes, and you know that if you receive an indication from the other > party that he supports application/my-dtmf (or whatever > >value is used). > >> > >>And, if we would have standardized one encoding, maybe > there wouldn't > >>be multiple ones out there... > > > >We currently have no way to say "I support mime-type foo for > >use with disposition bar and method baz", but in reality that > >is going to be the situation. I support sdp for disposition > >"session" in the methods that convey o/a. But I don't support > >sdp in MESSAGE or INFO. I support text/plain with > content-type "render" > in MESSAGE, but not for other > >dispositions and other message types. > > You don't have any way to say "I support mime-type SDP for use with > disposition bar and method baz" either - that we specify elsewhere. > > And, if we define a DTMF mime-type, we should of course also say in > which SIP message it can be used etc. But, again, we should > not specify > the applications that are going to use it. > > Also, since INFO is not supposed to affect the SIP session, > we can also > put restrictions on which disposition values are to be used etc. > > So, of course there is some work to do, but that's not a reason to > reject something. If everything was done and ready, there would be no > need for the SIP WG :) > > >Getting an indication of support for application/my-dtmf is > >useful *if* you know that the UA sending it to you always > >uses it the same ways you do. You can only know that if you > >control it, or if all the uses of that type are standardized. > > It's up to the applications to make sure that the DTMFs are sent and > intepreted. If the receiving application has not asked for DTMFs, and > the sender still sends them, the receiver should simply discard them. > It's part of the application logic - not the SIP protocol. The SIP > protocol defines information elements to indicate what > content types you > support, what actions to take if the content type is not > supported etc. > But, again: we don't specify what the applicatons are going to do with > information. > > It's similar to when you use RFC2833 for sending DTMFs. The only thing > you do, as part of the offer/answer procedure, is agreeing that both > endpoints support RFC2833 - but you do not specify what the endpoints > are going to do with the tones, when they will be sent etc. > > >>>And beyond just understanding your encoding of DTMF/INFO, > you need to > > >>>know that the recipient you are sending it to is likely to do > >>>something useful with that INFO, and that this "something > useful" is > >>>what you intend it to do when you send it. > >> > >>Yes, but you wouldn't send it unless you have a reason to think the > >>receiver is going to do something with it, e.g. if you have > >>been asked to give your PIN code. > >> > >>I don't understand why people think that applications would start > >>sending all kind of INFOs "just for fun", without any logic > >>behind. I have never seen that happen in real world deployments. I > wouldn't > >>start sending UPDATEs and/or re-INVITEs just for fun either, > >>eventhough there is nothing preventing me from doing it. > > > >Lets go back to my phone. *It* doesn't know that I have been > >asked to give my PIN code, even though I do. All my phone > >knows is that I have pressed one of the buttons on the > >keypad. It may reasonably infer that I want *something* to be > >done with them, and probably that I want them sent to the > >other end in some way. It has no idea *how* (or *if*) the > >other end is prepared to receive them. > > I think what you are talking about is how you will design your SIP > phone. > > For example, on my table phone, if I during a call want to send DTMF > tones I have to first press one button to "active" DTMF, and then any > button I sent is sent as DTMF. If I am asked to give my PIN > code, but do > not active DTMF, nothing will happen when I press the buttons. > > On my GSM phone, however, I don't need to active DTMF. If I > am asked to > give my PIN code, I simply press buttons and they are sent as DTMF > tones. > > >For instance, it may have indicated support for a mime type > >that my phone knows how to use to encode DTMF. But its > >possible it was really trying to say that it would support > >that type in a NOTIFY (sent or received). > > IF there are missing parts in the negotiation mechanism, we > need to fix > that. > > Something like: > > Accept: application/my-dtmf;method=INFO > > OR, in the draft defining the content type, we specify that > content type > X can only be sent using this and that method. I belive we do the same > thing for SDP. > > But, so far we haven't been interested in looking into these > issues. We > just say that using INFO is against the spirit of SIP, it causes all > kind of problems etc etc. > > My intention is not to "promote" the usage of INFO. My issue > is that the > market has found and deployed an easy and effective way of > doing things > using INFO, without breaking the protocol, and what worries me is that > instead of trying to help the market (e.g. by standardizing > the content > types, providing negotiation mechanism to achieve > interoperability), and > in that way indirectly help them to come up with new SIP applications, > we simply tell them that what they are doing (and have been doing for > years) is wrong, that they are breaking SIP, etc etc etc. > > And, if we really wanted to restrict the usage of INFO, it should have > been done a long time ago - not years after the INFO RFC is published > and people have deployed usages of it. > > Anyway, I guess we can go on with this discussion forever. Maybe we > should find some time in Chicago and sit down and discuss this? > > 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 > _______________________________________________ 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
