On Jun 13, 2007, at 4:26 AM, Christer Holmberg (JO/LMF) wrote:
Hi Dean,
Thanks for the document. I have read it before, but had forgotten
about it.
Probably a healthy response ;-).
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?"
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.
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) . . .
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). 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.
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.
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?
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.
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.
--
Dean
_______________________________________________
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
