Hi, >>Now, the first issue is how we know that the receiver supports the >>Content-Type of the body sent in INFO. There are ways to >>solve that, and it is not an INFO specific problem. > > >beyond "does it understand the content type?", we have the question "does it understand what you want it to do with the >content?"
Yes. >>The second issue is regarding the "SIP protocol rules", and I guess >>that is one thing which causes confusion. >> >>For example, if someone wants to send a DTMF tone he sends an INFO >>with the DTMF tone. The receiver will determine whether it's needed >>for anything (e.g. a robot asking for your PIN code) or not (e.g. >>if you're talking to a person and pressed a button by misstake). >>What "SIP protocol rules" do you need for that? The >>application will determine what/if it does with the received information. > > >"Spray and pray" is fun for kids in street gangs but >well-aimed fire is far more efficient and much safer for >innocent bystanders. 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. >Staying with the use of DTMF/INFO as an example (which, I'd >like to add, has been deprecated even if I did originally >endorse or maybe even coinvent it) . . . It hasn't been deprecated outside out on the field. >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... >Otherwise you wouldn't even bother sending it unless you're a hopeless optimist, trying >to impress your homies with the size of your packet-slinger, or just plain stoopid. I totally agree. >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. Just because you CAN doesn't mean you WILL :) >Now, for DTMF/INFO the "something useful" is pretty straightforward >-- take the tone sequences and either use them as input to a >local application or mix them back into the media stream. > >Other possible uses for INFO (and there have been many >proposed) are not generally so clear. For example, if I send >you an INFO containing a JPEG file, what are you supposed to >do with it? Project the image onto the wall? Use it is a >keyboard map? Use it as a voiceprint graph for spectral >comparison with my media stream as a means of performing a >MITM detection? (hey, I think I just invented something . . >.) Or something entirely different? That depends on the application. For example, the application may tell you that a JPEG file has arrived, and ask what you want to do with it. You may choose to project it, use it as a keyboard map, or whatever. But, again, I don't think anyone is going to send you the JPEG file "just like that", without any reason. >What is wrong with INFO as currently specified is that we >have no way of answering these questions. Content-disposition >and content-type just aren't rich enough for the range of >possibilities. I don't think we need to answer those questions, because they are application specific. What we need to answer is the question how to indicate what Content-Types the receiver supports, and is willing to receive for a given session. What we also should care about is to make sure that the Content-Types are standardized, so that we don't have multiple, uninteroperable, mechanisms doing the same thing out there. >So we either have to rigorously NOT use INFO for anything new >(and it is currently defined only for telephony tunneling), >or extend it to be able to differentiate usages. My personal >feeling is that the wild INFO cat has leapt out of the bag >and run off to have kittens, so we're better off giving those >kittens names and vaccinations than we are trying to convince >people not to pet the cat. I agree with you. I think that INFO is an easy and useful tool, and the market seems to think the same thing. 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
