Subject: Missing Warning reasons to SIP

From: "Scott Petrack"<[email-masked]>
Date: Thu, 25 Jun 1998 14:18:18 +0200

From: Scott Petrack@VOCALTEC on 06/25/98 02:18 PM

In SIP there are at present 5 Warning reasons defined. Two of these have to
do with SDP problems:
incomatible media format and incompatible protocol. These are very useful,
because as SDP is extended
there will be new formats and protocols used and the SIP server may not
understand these new types.

But it is already specified that SDP can be extended in seven different
ways, according to RFC 2327:

 "media",    "proto", "fmt", "att-field", "bwtype", "nettype" and
"addrtype".

So in SIP we have a warning for the case of "proto" and "format", but not
for any of the other cases.

I am writing up PINT now and I can already see that a SIP server which is
not a PINT server will not understand
the GSTN "nettype." And a PINT server which does not understand some local
numbering plan  contained in
the PINT request will understand the GSTN network type but not understand
the "addrtype."

Please can we get it right now and add to basic SIP the following Warnings:

606.6 Incompatible Media: One or more Media types described in the request
are not available.
606.7 Incompatible Network Type: One or more Network Types described in the
request are not available.

(e.g. This would be returned by a SIP server which doesn't understand the
GSTN nettype)

606.8 Incompatible Address Types: One or more Address Type fields described
in the request are not available.
606.9 Incompatible Attribute: One or more attribute fields described in the
request are not available.

606.10 Incompatible BW Type: One or more BW Type fields described in the
request are not available.

I asked before how SDP errors should be propogated back through SIP, and I
now see that the Warning field does
 this already in several cases, so it should be completed to allow standard
SIP servers to express their incompatibility with whatever future
extensions of SDP get made.

Thanks,

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

---

From: Mark Handley <[email-masked]>
Date: Thu, 25 Jun 1998 11:11:14 -0400

>request are not available.

I agree with most but not all of these.  The two I have reservations
about are Attribute and BW Type.  The others MUST be understood in
order to join the session, and hence merit causing an error and having
a warning field allocated to them.

Attributes are generally considered optional additional information
about the session.  For example, Icast and Precept have often used
attributes to convey additional information that is helpful for their
software to have, but isn't essential for reception of the session.
There are exceptions, such as rtpmap, which you really should
understand, and if I was doing SDP from scratch today, I'd do it
differently to make this distinction clearer, but the general rule is
that you do not raise an error if you get an attribute you don't
understand.  

Bandwidth fields are similar - normally you wouldn't expect an unknown
bandwidth identifier to cause an error because they're informational
but not essential to participation.  But as we have next to no
experience with bandwidth fields, this is somewhat less obviously
that it is with attributes.

As we progress SDP to draft standard and it gets used in a wider range
of circumstances, we might consider whether we need to add the SDP
equivalent of a "Require:" header for attributes to make the
distinction clearer.

Cheers,
	Mark