Hadriel Kaplan wrote:
Send the 200 OK and let the application sort out the body. SIP has done
its job - don't be a layer violator and conflate an application error
with a transport error!
I don't think I agree with this, but it could stand some further
discussion. Are you asserting this behavior is special for INFO? Or that
it is true for all messages?
I don't find anything in 2976 that calls for a success response when the
content of the body is incorrect.
Yeah there's no debate that SIP expects INVITE/UPDATE to be handled integral
with body processing. What's always been argued is how to handle things like
MESSAGE, SUB/NOT and INFO. Several people have argued the body part content of
those was at a higher layer. The text in SUB/NOT RFC only defined a response
code for bad Event-types or unknown body content-types I think, but left body
processing failure out of it. And none of the packages seem to go any deeper
as far as I can tell.
Of course in practice some (many?) devices respond with failure codes when body
processing fails no matter the method.
Wasn't this debated a couple few ago on this list?
I sort of see the logic although I'm also not 100% convinced by it.
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.
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.
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.
Assuming an event package specifies that all INFO requests result in a
response which is carried in the 200 response, what does that mean for
the info package negotiation? An implementation might be able to act as
a sender of this type of INFO but not as a receiver. It still needs to
understand the INFO responses but presumably it needn't list the info
pkg in Recv-Info header fields it generates.
Just as an FYI ECMA has defined TR/87, a SIP INFO binding for the
computer-supported telecommunications applications (CSTA) CTI standard,
which uses exactly that model. CSTA requests and events are carried in
SIP INFOs and these INFO requests succeed even if the CSTA request
fails. For CSTA requests the 200 response to INFO always carry a CSTA
response and for CSTA events the INFO response has no payload. The spec
is available from
http://www.ecma-international.org/publications/techreports/E-TR-087.htm.
Thanks,
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
