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".
I just reviewed 3428, and I don't read it as saying that a 200 should be
returned of the message is *received*. It says that the the message
should be processed according to the rules of sip, and then a final
response should be returned immediately. It just says the message need
not be *rendered* immediately (or ever).
It doesn't say that you can't, or shouldn't, check the validity of the
message and return an error if it is invalid.
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.
Certainly that is a possibility, but only for packages that define a way
to do that.
I don't personally care either way - I'm more interested in knowing if current INFO users *need* to have a 200 ok sent back even on content processing failure.
That is a good question. I certainly wouldn't *count* on that behavior
based on the current language.
Because if someone needs it, then we should define it that way; anyone else who
doesn't and wants to integrate it into the response can still freely send back
a 415 or 488 or whatever to the INFO, because the rules for a UAC would not
change and none would be the wiser.
Yup. For something like DTMF, I would expect to get an error if the body
is badly formed, not an info in the other direction.
Thanks,
Paul
But it does mean all drafts defining a specific package would need to put rules
in for how to indicate subsequent failure after a 200 ok if they need to, and
that sucks. :(
I'm trying to see what Subscribe/Notify does about this, and grep can't seem to
find anything. I wonder if this was not handled in Sub/Not?
AFAICT the draft has no discussion on how to carry app-level success or
failure indications. In fact, the table in sec 5.2 indicates that
Info-Package is allowed in requests only.
Right, only in requests. Failure of the INFO delivery or package-name type
stuff would be in this draft as a request failure; whereas failure to process
the package contents (ie body content) would be specified by the drafts which
define specific packages. Presumably they would need to specify error
indications in reverse-direction INFO requests, or better yet ignore the error
if possible.
-hadriel
_______________________________________________
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
_______________________________________________
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
