Eric,
I understand what you're saying but as I said I think it's problematic
or at least warrants some discussion in terms of where it leads. My
worry is that it makes it significantly more tedious to build on the
info-events work and hence invites people to either ignore the whole
thing or the parts with which they disagree.
So let's take the ubiquitous DTMF example. Someone defines a DTMF info
event package and they want the recipient of DTMF events to be able to
indicate to the sender that a particular event could not be decoded. If
I understand you correctly, the error indication would have to be
carried in an INFO going in the opposite direction of the DTMF itself.
PROBLEM 1: If errors are to be returned this way it means that both
parties must signal both "Send-Info: dtmf" and "Recv-Info: dtmf". Hence
there's no distinction between the sender of DTMF events and the sender
of responses to DTMF events. Unless the dtmf package is modeled as two
separate INFO event packages.
PROBLEM 2: In some cases (most likely more often than not) it will be
necessary to correlate responses to requests. In your model this
correlation has to be done at the app level, that is, in the INFO
payload. However, that will make it difficult to use existing formats
that don't have a convenient place to put such an ID. My employer's INFO
DTMF payload doesn't have a place to put it. Another frequently used
example is the exchange of JPG images for whatever purpose. Again, no
place to put an app level ID in the INFO payload. You could put it in
the INFO header put that would be a layer violation, right?
PROBLEM 3: If all events require a response you end up with twice as
many INFO transactions as is really necessary. That's difficult to
swallow without a really good reason. We could allow 200 respones to
INFO to carry INFO package responses with no adverse affects to layering
so that's not it.
Thanks,
Anders
Eric Burger wrote:
Let us try again.
INFO is a method that *transports* Application-Level "messages".
INFO is NOT a method of Application-Level messaging.
What is the difference? In TCP, if I send a message, "SIP/2.blah blech"
to port 5060, TCP will acknowledge delivery of that packet. That is
like a "200 OK" in SIP. The process monitoring port 5060, on the other
hand, will hopefully come back with some sort of "4xx you suck" message,
encapsulated over TCP, which TCP will acknowledge delivery of.
It is bad enough that we are proving Oran's Law: any well-deployed
protocol becomes a transport protocol. Let us not make it worse and make
SIP look like Bluetooth with its dozens of profiles for whether you are
a data device, a speaker, a microphone, a headset (yes, which is
different than a speaker and a microphone), and so on.
Let INFO be INFO: something that *transports* messages through a SIP
Proxy network. Note I say "through a SIP Proxy network." If you do not
want to traverse Proxies, use TCP :-)
On Nov 29, 2008, at 2:03 AM, Anders Kristensen wrote:
Hadriel Kaplan wrote:
-----Original Message-----
From: Anders Kristensen [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 9:44 PM
In any event (no pun intended) I don't think the draft adequately deals
with the implications of this model. If errors occurring at higher
layers aren't reported as failure of the INFO request itself, it pretty
much follows that the 200 response to the INFO must include a payload
that carries info (sorry, pun not intended here either) on the error.
No I think the logic that Eric's arguing for is "you asked for
delivery of this package, and I'm responding with 200 ok because it
was delivered". In other words treat INFO as a delivery vehicle,
like MESSAGE, and as long as the package was delivered you send a 200
ok, with no correlation to if/when the package was opened and read
successfully or not by a higher-layer info-package "consumer".
The alternatives would be:
1) Don't report app-level errors. Perhaps OK for simple packages.
2) Report outcome in separate INFO requests going in the opposite
direction. Seems wasteful and requires additional app-level
correlation.
Yeah, I think Eric's argument is for (2). If they need it, they pay
for it.
Well, in the case of (2) I'd say they'd be overpaying. In my view it's
a non-starter. People will want to be able to send app-level responses
and they won't want to go through a lot of extra trouble to do it. And
why should they? I'm thinking we should allow app-level errors to be
signalled with INFO error codes and/or allow INFO responses to carry
responses along the lines of what CSTA does.
I'll be applying the flame retardant now...
Anders
_______________________________________________
Sip mailing list https://www.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
