Hadriel Kaplan wrote:
But we can't _require_ a fully-layered model. In other words, all packages
have to gracefully handle failure responses to their INFO request which were
caused by processing failure. And if a package really cares about processing
failure, then it could also define a way to indicate it in a subsequent
separate INFO transaction.
INFO-DTMF is a good example of one that *won't care*. There's no real point in
indicating errors back. That doesn't mean you can't send back a 4xx
immediately in response to the INFO request - you can always do that - it just
means we do NOT have to define a way to indicate error after that in an
upstream INFO request.
Either it's legal or it isn't. It's no good saying it's not legal but do
what you gotta do. Are you saying the info-events draft should allow UAs
to return INFO level errors in response to app-level problems?
And BTW, any package could define different content-type or body content or
whatever for both the normal use and the error indication, so it won't need
separate package names for each. But anyway that's really up to the specific
package to handle, not the main draft methinks.
So a UA would look at both Send-Info, Recv-Info and Accept in order to
find out what are the info pkg capabilities of the peer? I guess that
could work.
Anders
-hadriel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric
Burger
Sent: Sunday, November 30, 2008 5:28 PM
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.
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 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.
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.
I feel as if I am swimming upstream with a school of Red Herrings ;-)
_______________________________________________
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
