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
