Christer, I think I'm starting to see your point... It sounds to me as if you are saying something equivalent to the following: INFO is a notification for some type of implicit subscription on an INVITE dialog. (geez, I hope my interpretation doesn't sound stupid)
For example, instead of establishing a new dialog for receiving DTMF notifications, the INFO is used in order to send events on the INVITE dialog without requiring a new subscription usage on the dialog (meaning, the implicit subscription ends with the BYE, unlike explicit subscriptions which are a different usage). Is this interpretation acceptable? Only thing part I feel is missing is actually stating which "subscriptions" the UAs want to receive/support and the previous discussion on content-type vs. another header to indicate the purpose of the INFO message. If DTMF on INFO does become a known RFC, I think for the very least it should adopt the body from the KPML syntax rather than a proprietary one, but that's another issue. Regards, Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 14, 2007 3:38 PM > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > 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 _______________________________________________ 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
