Eric Burger wrote:
PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric
information going the other way, then you want to send Foo-Response.
Like you say, Foo is not the same as Foo-Response. Look at KPML as an
example of how to do this right.
OK, it can be done using two packages. It seems a bit clumsy to me but
it'll work.
PROBLEM 2: You've got it in one! The correlation MUST be at the
application layer. If you have a package that has asymmetric
information flows, then you have two choices. The first is that you are
using a dialog-related application-to-application messaging protocol
(INFO) because you want to send messages related to *this* dialog. Any
response belongs to the request. Fairly straight forward. Otherwise, if
I think we're talking past each other. The problem is not correlating to
the dialog, it's correlating the app-level response to a particular
app-level request within a given dialog.
you have a package that is really using INFO for tunneling, then it is
most likely already doing some sort of multiplexing, which means you
already need some way of identifying what the messages are for and about.
PROBLEM 3: Another winner! If you care at all about performance, you
would NEVER use INFO!!!! Come on guys - let's look at DTMF: one to
sixteen bytes of payload, two thousand bytes of SIP overhead.
I don't think I buy that. If something can be accomplished with one INFO
request people are going to wonder why they have to have two.
Of course, the problems listed below are sort of hyper-theoretical. If
a UAC cannot get a message as simple as DTMF right, getting an error
message from the UAS saying the UAC got it wrong is not going to help.
I'll bet my next $100 dollars that a UAC that needs hints inside of a
package to get something as easy as DTMF right will core dump when it
gets an error.
Obviously, DTMF is not the problem. If you're only targeting
applications as simple as DTMF then there's no problem. I think we have
to expect it'll be used for all sorts of things, though, including
request-response type apps.
Anders
I feel as if I am swimming upstream with a school of Red Herrings ;-)
On Nov 30, 2008, at 4:44 PM, Anders Kristensen wrote:
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
