Subject: [SIP] SIP issues raised at bake-off

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Apr 2000 18:38:48 -0400

The following issues were discussed at the SIP bake-off. Comments from
the list are appreciated. 'Suggested solution' is the preference
expressed by the bake-off attendees.

1) SDP case-sensitivity for encodings (see previous message)

Suggested solution: case-insensitive (possibly with upper-case as the
canonical version)

2) tag: currently is hex, should token be allowed?

Suggested solution: yes, token should be allowed.

3) REGISTER authentication

Some suggested that proxy-authorization should be used instead of
Authorization for REGISTER. Text needs to be clarified but consensus was
that Authorization is to be used (if a proxy, real or co-located also
wants the client to authenticate, it is free to return a 407 and the
client should use the same mechanism to return Proxy-Authorization).

4) Digest quoting of URIs

RFC 2617 is inconsistent. The BNF specifies that URIs are appended as
arguments, while the example in RFC 2617, Section 3.5 encloses them in
quotation marks. The latter is considered correct since the URI may
contain non-token characters.

5) From/To header

Some implementations do not put a space between the display name and the
'<'. This is legal, if unusual.

6) Expires header

If a new registration has a shorter expiration date, it updates the old
one.

7) Multicast INVITE/REGISTER

It was suggested to include a maddr in the Via header containing the
multicast address. This makes it easier for the server to tell that the
request was received via multicast (since sockets may receive both
unicast and multicast packets).

8) Overlapping transactions

A number of people expressed unhappiness about not allowing overlapping
transactions as it greatly complicates the client state machine for
things like hold/mute. This may need to be discussed again. Maybe
limiting this restriction to media list changes would address most of
the concerns.

9) Status code for non-matching media (in SDP)

Currently, we have 606 for "Not Acceptable", but this terminates
searches. Thus, it was suggested that we may want to add a 488 code for
incompatibility at an individual terminal (which allows the proxy to
search elsewhere for matching media).

10) Record-Route

It was suggested that UAS should reflect all Record-Route headers into
Route headers, as that might simplify implementation of future features.
This is already implied by the current wording in 6.33.2.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 17:05:46 -0400

Henning Schulzrinne wrote:

Yup, as per Annex C:

> The grammar described by this specification is word-based. Except
>    where noted otherwise, linear white space (LWS) can be included
>    between any two adjacent words (token or quoted-string), and between
>    adjacent tokens and separators, without changing the interpretation
>    of a field. At least one delimiter (LWS and/or separators) MUST exist
>    between any two tokens (for the definition of "token" below), since
>    they would otherwise be interpreted as a single token.

The only place there MUST appear LWS is between tokens. Since > is a
separator, according to this paragraph,  LWS can appear, but not MUST
appear.

> If a new registration has a shorter expiration date, it updates the old

Note that this is consistent with the Expires:0 operation; the reason we
did Expires:0 to erase registrations is that it didn't require special
case treatment for enabling removal. Thus, an implementation which does
not currently have code to special case 0 should work this way already.

This is already specified in rfc2543:

> A proxy sending a request to a multicast address MUST add the "maddr"
>    parameter to its Via header field, and SHOULD add the "ttl"
>    parameter. If a server receives a request which contained an "maddr"
>    parameter in the topmost Via field, it SHOULD send the response to
>    the multicast address listed in the "maddr" parameter.

The text should be clarified in that it only says this for proxy. Its
also true for a UAC.

> search elsewhere for matching media).

An implementation can send any 400 code, in fact, and just change the
reason phrase. No need to wait for an additional response code for
people to begin doing this.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Alexei Prokofiev" <[email-masked]>
Date: Mon, 24 Apr 2000 01:42:52 +0400

Hi,

in case replies are sent by a server UA via several TCP connections 
(for example, a new connection is created for each message) close 
out of which of the connetions must be treated by a client UA as 
CANCEL in case the transaction is not complete?

Thank you for your responce.
-----------
Alex Prokofiev
Mera Labs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 23:55:13 -0400

The server should not open a new connection to send a response if one is
already open. You should not be opening a new connection for each
response.

As a result, it is the original connection the request was sent on,
that, if closed, implies CANCEL.

-Jonathan R.