Hi, A small addition regarding the does-your-phone-knows-that-it-shall-generate-DTMF-when-you-press-a-button: wouldn't you have exactly the same problem no matter whether you use INFO, RFC2833 or some other mechanism to transport the DTMF tones?
Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 14. kesäkuuta 2007 12: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
