INFO 4xx response (was RE: INFO Framework - one pakage per INFO)

Hi, 

>>I think the 488 precedent was unfortunate. If you send SDP offer in a 
>>reliable provisional response or a 2xx response, 488 isn't available 
>>to you (except I suppose you could put a Reason header in the PRACK or

>>ACK request, but I don't really want to go there).
>
>The same could be said of 413, 415, 493, etc.  If the UAC can't
fundamentally handle an INVITE response's body, it can send a CANCEL,
with the Reason header.  I thought that was the point of the Reason 
>header - to be able to send the failure reason in requests.
>From RFC 3326:
>   "SIP responses already offer a means of informing the user of why a
>   request failed.  The simple mechanism in this document accomplishes
>   something roughly similar for requests."
>
>
>So I don't think we need we need a way of indicating in an INFO 
>response problems with body content in the request.  Let the 
>application send an INFO request in the reverse direction.
>
>That's not always technically possible, AFAICT.  If the body content is
bad, there's no guarantee it even got to the app-layer.

If the body content is bad, in the sense that the UA does not support
it, can't parse it etc, one should be allowed to send a 4xx response -
like for any other SIP request (well, not for PRACK, but we're trying to
fix that :).

BUT, if the body is used for my chess application, and I am trying to
make a chess move which is not allowed, that should not be mapped into a
SIP response code. Instead an INFO should be sent back, indicating the
error.

Regards,

Christer

_______________________________________________
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