Christer, In-line.
John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 14 June 2007 11:02 > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > Hi, > > >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? > > Then, why did we do KPML? [JRE] KPML addresses a different problem space, i.e., an application server that doesn't necessarily have any audio and/or DTMF capability. > > I am personally not saying people should use one solution > instead of another. I think the issue is that the market has > seen a need for out-of-band transport of DTMF tones, one > reason being that all entities using DTMF do not have access > to the media. [JRE] KPML addresses this space. Because it establishes a dialog for the purpose, KPML can ensure that SIPS is used, even if SIPS is not used for the INVITE-initiated dialog. Why do we need a different solution? > If you don't agree to that requirement I think > this is the wrong place to discuss it :) > > Regards, > > Christer > > > > > > > > -----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
