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
