Christer, Yes, it affects all information, but in the case of DTMF we already have a mechanism for securing it, SRTP. So why attempt to standardise a new mechanism for transporting DTMF that introduces security issues that are already solved with the existing mechanism?
John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 14 June 2007 10:41 > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > Hi John, > > I hear what you are saying, but I don't see how this is > specific to DTMF and INFO. > > Doesn't this affect all I kind of sensitive information that > you want to transport over SIP? > > Regards, > > Christer > > > > > -----Original Message----- > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > Sent: 14. kesäkuuta 2007 12:33 > > To: Christer Holmberg (JO/LMF) > > Cc: SIP IETF > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > > 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
