Hi, Comments inline
> -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 13, 2007 10:47 PM > To: Dean Willis > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > 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. > Don't we need something that indicates to each UA what types of INFOs the other UA should get? I still don't agree there is a 1:1 relationship between content type and info purpose. > >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. That depends on what "it" means, there are several old drafts for this single functionality, for example one proposed to send MGCP in the body. Another proposed a specific body. There are probably more. So is our approach to document and standardize any proprietary implementation for this? Even when we have alternatives? > > >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 :) Is the assumption that INFO is triggered by user and not by something in the flow? Let's say I invent INFO that sends information on voice quality in a call every X seconds. How does one indicate this will/should be sent? > > >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 if each is sent for a different reason and not just one picture is sent? How do you tell the application "the 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. > I tend to feel it's not enough. > >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. > This is not your everyday kitten. This big cat bites and scratches. Or maybe I've taken the metaphor too far... Really - other than SIP-T, I don't understand so far what necessary usages INFO has that do not have other viable/better alternatives. Just because some company X did something and perhaps even company Y mimicked it, who said it's a good idea. For any new usage I think of for INFO I find a better solution in SUBSCRIBE-NOTIFY... Just like INFO should not be sent just for the heck of it, INFO usages should not be invented just because it's possible. > I think that INFO is an easy and useful tool, and the market seems to > think the same thing. I agree it's easy. Can it ease some implementation? > > 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
