Subject: Re: Missing Warning reasons to SIP

From: "Scott Petrack"<[email-masked]>
Date: Mon, 29 Jun 1998 13:23:08 +0200

From: Scott Petrack@VOCALTEC on 06/29/98 01:23 PM

I don't want to go anywhere near a Rathole at this late stage, so let me
try this as a solution.

I would like to *remove* the "606.x" labels from *all* warnings. Instead,
we can allocate numeric codes
from some "warning code space."  The idea is that the warning should
indicate the "problem" only, and
should not indicate if the problem is a true error (i.e.the request cannot
be processed as is) or not.
The response code indicates if the response is an error or not, and this is
orthogonal to the content of the
Warning.

As an example, one could imagine that if a particular attribute "a=" line
is not understood, it might be
impossible to process the request, although normally the receiver should be
able to ignore the
attribute line. So it would be nice to have some Warning code  "xxx.x
Attribute Not Understood"   which
sometimes appears in errors and sometimes does not.

As another example, it may be that several alternative formats for a
particular media are offered, and the
server understands one but not another. The request can be processed,
because it is only necessary to
understand one of them. But it would be nice to be able to indicate in a
warning that the server doesn't
understand all formats. (For example, I could use this to answer an
invitation to an RTP session with a
Warning that I can't do G.723, even though I can accept the invitation and
use GSM or G.711. etc. You get
the idea).

In addition to the Warnings already described in the current spec with
606.x headers, I would add the ones
I suggested, to say that some SDP extension was not understood, and maybe
Mark's suggestion for a new
warning with "Unknown SIP header field." All in all we would have about 10
Warnings.  As a first crack, I would
suggest that there should be two major numbers at present:  1.x for "SIP
warnings" and "2.x" for "SDP warnings".

I leave it up to the authors now. I just need the ability to warn the
requestor that some SDP extension was not
understood.  And I need to be able to do this both in error responses and
in successful responses.

Scott

[email-masked] on 06/28/98 06:01:50 PM

To:   Scott Petrack
cc:   [email-masked], [email-masked]
Subject:  Re: Missing Warning reasons to SIP

>Ahhh. I thought that it is not necessary that a Warning: header be
>returned in an error reponse. I thought that even a response which denotes
>success
>might carry a Warning: header, to indicate, well, a warning ;-).
>
>So basically I agree with Mark, I just assumed that this was already
>allowed to have
>certain Warning returned in success responses.  I merely wanted these
>Warnings to be "pre-defined" and agreed upon.

I just re-read what the spec says, and I think you're right - we need
to extend the wording in the description of the Warning header.  It
should be quite acceptable to return a Warning header in a wide range
of circumstances, not just in a "606 Not Acceptable" response.
However, the only existing warnings defined are 606.x warnings - those
that cause a failure because the recipient cannot participate in the
session as described.
"Unknown attribute" and "unknown bandwidth" would appear to be 200.x
warnings - they don't cause an error, but it might be useful to inform
the caller that they were ignored.
Off the top of my head, useful 200.x warnings would be:
  200.1 - Unknown SIP header field
  200.2 - Unknown session attribute
  200.3 - Unknown session bandwidth specifier
The problem is the current usage of 606.x warnings is to return in the
response payload a modifed session description that would be
acceptable, not to indicate directly what is unacceptable.  Thus
getting "200.2 Unknown session attribute" doesn't tell you which
attribute is unacceptable, and hence isn't terribly much use.  What
you might do is remove the attribute from the session description sent
back to the caller, although this is somewhat subtle, and may not work
at all for unicast calls where an attribute might only be intended to
apply to one direction.  Thus right now I'm reluctant to add these
warning codes until we've sorted out how to make them unambiguous.
Most other response codes don't justify warning codes because there is
little that can be done automatically by a UA client that receives
them.  If there is no *automatic* course of action the UAC can take, I
would expect a simple textual payload to be sufficient for debugging
purposes.  We don't want to add complexity to SIP with
additional Warning codes.  Perhaps we should define a generic warning
code to convey this, because often we cannot use a text/plain payload
as we're already obliged to carry an application/sdp payload (200 is
the obvious case).  So perhaps we should define a new Warning code:
  000.0 Generic Warning
The idea is that the text conveyed by the warning field explains to
someone attempting to debug code that something unexpected happened,
but that the UA client is not expected to do anything special with the
Warning field.  A good example of this might be with a "400 Bad
Request" field, where the client has erred and so you don't expect it
to be able to do anything automatic to fix the problem, but would at
least like to be able to report what exactly the problem was that the
server had with the request.
Looking through the list of response codes, I find very few others
that might want to return additional information that 000.0 would
*not* be appropriate for and that appropriate mechanisms aren't
already defined:
  "482 Loop Detected"
     it would be good to have a way to return the path that lead to it
     because either proxies or UA clients might be able to modify
     their future requests to avoid the problem.  Of course doing so
     would not be mandatory for sites that wish to hide topology.

  "483 Too Many Hops"
     as 482
That was all I found.  These two don't seem to be well handled by a
warning field.  Do we want to define an alternative mechanism?  In
these cases, returning a payload of application/sip or
application/quoted-sip and simply returning the Via headers as a
payload might be an appropriate course of action.

More importantly, looking at the 606.x warnings, I find that we've
only specified how to discover what the problem really is on the
examples section (14.8 in the 07a draft).  We need to add text to make
this much clearer.

Cheers,
     Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Jun 1998 14:43:44 +0200

> orthogonal to the content of the

I like this idea - it also corresponds to what the HTTP folks are doing.
(One less potential stumbling block during last call...)

> (For example, I could use this to answer an

This type of "warning" (or indication, rather) should be in the session
description (the sender [not really supported by SDP] or receiver
capability [standard SDP attributes]).

> warnings" and "2.x" for "SDP warnings".

Please note that SIP is independent of SDP and thus, there should be
nothing in the base spec (beyond some appendix that says how to use SDP
with SIP) that references SDP explicitly.

It would be helpful if we could describe the list of warnings we need
right now, beyond the

insufficient bandwidth
incompatible [transport] protocol
incompatible [media] format
multicast not available
unicast not available

(suggested new wordings in []) and the new

network address type not supported

and the possible

session description parameter not understood (where the warning text
would be expected to be more specific)

Example would be

Warning: 100 foo.com Session parameter "foobar" for media "audio"
(instance 1) not understood

Note that we'd probably want to use numbers outside the single/double
digits that HTTP currently occupies, just in case.