Hi John >>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?
The problem is that the INFO solution was implemented BEFORE KPML was finalized. I also believe that many people think it's easier do handle it in a single dialog, without having to establish and associate two separate ones. But, that's just my guessing (I have personally never had to make the decisson which solution to implement based on technical arguments). 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
