[Sip] update-01: the 155 response and implied errors

["Bob Penfield" <bpenfield@acmepacket.com>]

Last night at the meeting I raised the issue that it is burdensome for the
UAC to figure out what the problem is with a request when a 155 provisional
response is received. For example, there would be no way to tell that a 416
(Unsupported URI scheme) problem exists. There were 2 suggestions to solve
this problem.

1. Include the proposed Reason header (or a simple version of it) which
would indicate the associated 4xx error code.

2. Include a status-line in a sipfrag body.

The first option was rejected because the Reason header will not be ready in
time for the 2nd bundle (manyfolks, privacy, call-auth, etc.) and it has
also been sent back to SIPPING for a better definition of requirements. The
idea of a simplified reason header was rejected because we don't want to add
too many headers.

The second option does not seem promising because of issues raised with the
sipfrag MIME type (I'm not aware of what those are).

My fear is that we would need a new option tag when the Reason header was
done because it would impose slightly different behavior requirements on the
UAS and UAC.

After further investigation, it appears that only 416 is a problem and all
other reason can be determined by the presence of a specific header (as
described in the draft). Therefore, if we just added another status code
(say 156) to cover 416, I think we would have everything covered.

401: 155 with WWW-Authenticate
407: 155 with Proxy-Authenticate
415: 155 with Accept/Accept-Encoding/Accept-Language
416: 156
420: 155 with Unsupported
423: 155 with Min-Expires
488: 155 with Warning

This still requires the UAC to check the headers. And presence of an Accept
header does not necessarily imply 415, unless we change the draft to say
that it does. We could specify that all the other headers should be checked
first.

Another alternative would be to define a 15x status codes for each
corresponding 4xx code so that the UAS can be explicit about the problem.

401&407: 151
415: 152
416: 153
420: 154
423: 155
488: 156

We could use 150 as a place holder for use with the future Reason header and
indicate that the UAC should CANCEL if it cannot figure out what the problem
is.

The new status codes may be overkill.

Thoughts?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip