Re: SIP: comments on the spec

[Jonathan Rosenberg <[e-mail]>]

Anders,

Sorry for the delayed reply.

The text below represents the outcome of discussions among all four
authors of the spec.

Thanks for you careful reading.

Thanks,
Jonathan R.

Anders Kristensen wrote:
> 
> [1.3] In the definition of "Client: An application program that
> establishes connections..."  I'm not sure I know what "establishes
> connections" means here. What about multicast SIP requests, for
> example?

I'm not sure I understand what this means; connection in the context
here is state at the end system, not in the network. Perhaps that the
source of the confusion. To provide some clarification, we can change
the wording to "an application program tham sends SIP requests".

> 
> [2] In the SIP URL grammar (fig 3) 'other-param' is simply *uric.
> Ought the BNF not define other-params to be a semi-colon
> separated list of
> 
>   (token | (token "=" (token | quoted-string)))
> 
> or something like that?

I agree. Seems like a minor change for clarification, as this was our
original intent. Its been fixed.

> 
> As it stands the BNF is ambigous. Other-params can include ';' which
> separates it from other parameters and '?' which separates params from
> headers.  Likewise, header names and values can contain '&' which also
> separates them from each other. The "URI: Generic Syntax" draft can
> get away with defining query as *uric because it doesn't say
> *anything* about the structure of those parts of URLs, but SIP does
> and so must be more precise.

The &, ?, and ; are listed as reserved. These all need to be escaped,
by definition, as indicated in the text above the figure.

> 
> [2] I don't see the point of figure 4. Sure you can encode phone
> numbers (or whatever) into the user field but if it's transparent for
> the purpose of the SIP spec there's no point at all in going into it
> here and it should be left to other specs (as in fact it was in
> earlier drafts).

Would be nice to leave it to other specs, but they are not RFC's. Its
not
"transparent" to SIP though, since a server needs to be able to parse
the request URI. In will need to know what the BNF represenation is of
this part of the request URI.

> 
> [4.2.1] The relationship between session descriptions (SD) and calls
> isn't completely clear to me.  Section 4.2.1 would seem to suggest
> that SDs are a property of calls rather than call legs.
> 
> Typically there'll be a single SD in force per call (ie per Call-Id),
> but given that multiple INVITEs can be received for the same call,
> potentially with different SDs and possibly even in different SD
> languages, shouldn't SDs be a property of a call leg rather than the
> call?
> 
> Suppose, for example, that A, B, and C are in a conference call and
> are connected by a mesh and A wants to "far-side" mute B. It can do
> this by sending an INVITE with an SDP body with a c= field with a zero
> address as described in appendix B. This should cause B to stop
> sending media data to A but it should continue sending to C.
> 
> Maybe this is only really a problem with the call-control extensions
> described in a separate draft, since this allows A to establish the
> leg between B and C in the first place...

There can be multiple legs even in the base spec, but not because of the
way mentioned. Multiple 200 responses can be received for a single
call request, establishing multiple call legs. In that case, this is
right, a session description is per call leg, which is in most cases the
same as the call. 

In any case, section 4.2.1 says nothing to suggest that a SD is a
property of a call rather than a call leg. We can add some text to
clarify the relationship.

> 
> [4.2.1]
> 
>    "For two-party
>    calls, the caller indicates the type of media it is able to receive
>    as well as their parameters such as network destination. A success
>    response indicates in its message body which media the callee wishes
>    to receive."
> 
> This doesn't give the impression that the session description is just
> as much about conveying what one can *send* as it is about what can be
> received. This same vagueness pops up again in section 15.3:
> 
>    "Note that Watson's list of
>    codecs may or may not be a subset of the one offered by Bell, as each
>    party indicates the data types it is willing to receive."
> 
> ... and send.

I don't think you can indicate both with SDP, and only the receive
capabilities are important for the session. However, other session
description formats may be able to express send capabilities. SIP does
not restrict this in any way. Text will be added to clarify this.


> 
> [4.2.3] The OPTIONS request is used to ask the server about its
> capabilities. The server can indicate
> 
>   - media it understands
>   - how it would have responded to the corresponding INVITE
>   - the valid methods for the resource (Allow header)
> 
> It would be useful if the server could also tell the client which
> extensions it knows about. It could do this using a "Supported" header
> field (like Unsupported with the sign reversed).
> 
> It could be argued that this is a security risk since it reveals
> information, but
> 
>   - the server can just choose NOT to tell about certain extensions
>   - the client can get info about specific extensions anyway by
>     including a Required header in the request, and
>   - the server can require authentication before giving away this
>     info.
> 
> If this use of a Supported header is deemed a good idea example 15.8
> should be changed to illustrate it.

I do think its a good idea, but I'd rather delay this until draft
standard. I think a Supported header would be good in requests as well,
to allow for server feature extensions that a client must understand.
But, these are a big change, and I would rather delay something like
this to draft once we have had more experience with it. 


> 
> [4.2.6] Register
> 
> Registrations are sensitive to request reordering. If I register for
> one location and then (fairly rapidly) again for another location they
> might be received out-of-order. Since the two requests belong to
> seperate calls (or rather no call at all) they would appear to get
> processed out-of-order. Yes? No?
> 
> It might be useful to be able to say that a REGISTER request takes
> effect from some specified point in the future. Say I leave my office
> and know I will be reachable at a friends number half an hour later.
> This is just an idea. It's probably better to keep the registration
> support in SIP minimal, especially since it's on the fringe of what
> SIP is really about.

There are ways to handle out of order registrations using combinations
of CSeq, Call-ID, Date fields, etc., but these quickly become
extremely complex. The somewhat implied solution in the specification
(which we will clarify), is that a server processes the registrations
in the order they are received. If a client wants to avoid ordering
problems, it should wait for the previous registrations response (200
OK) before proceeding with the next.


> 
> [6] "Proxies MUST NOT reorder or otherwise modify header fields
> other than by adding a new Via or other hop-by-hop field."
> 
>  - and fix up Via fields with 'received' info as described in 6.40.1.

We'll fix.

> 
> [6.16] BNF for Content-Type has extraneous "(":
>         Content-Type    =    ( "Content-Type" ":" media-type

Fixed.

> 
> [6.30] Require BNF syntax:
>         Require = "Require" ":" 1#option-tag
>   Problem is option-tag is *uric and the uric character class includes
> commas. Hence something like "Require: a.b.c,x.y.z" is ambigous. This
> is easily fixed by defining option-tag as being a token.

Comma is a reserved character in the uric definition, and thus must be
escaped.

> 
> [6.37] BNF syntax broken - should be like From BNF:
> 
>   To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )

Will fix.

> 
> [6.37] Tag param in From, To fields.
> 
>   "It MUST be placed in the To field of the
>    response by each instance when there is a possibility that the
>    request was forked at an intermediate proxy. This, in general, means
>    that the tag MUST be inserted when the URL in the To does not refer
>    to a fully qualified hostname."
> 
> Meaning, I guess, that when the host part of the To URL is a domain
> name, it has an A RR associated with it.  This is, however, not a very
> good criteria as many domains (hp.com being one) have A records
> associated with them to make URLs like http://hp.com/ work.  Hence
> doing a single A DNS lookup won't work.
> 
> Section 11.2 more precisely says that a UAS MUST add the tag whenever
> the fqdn is different from it's own fqdn. This can still fail for
> shared machines (coming into fashion again - maybe) where the same
> user can be logged in more than once.

We've changed the spec to indicate that a tag MUST be inserted when
there is more than one Via field in the received request. This is
unambiguous and easy to use, at the expense of being slightly
conservative.



> 
> [6.40.3] Via
> 
> If the request was sent using a TCP connection which was closed before
> the response was received, it is not necessarily possible to connect
> to the address indicated by the 'sent-by' Via parameter as prescribed
> by step 4. This is the case when the client did an active open as the
> Via field would contain some random port number.  Maybe a solution
> would be to require UACs using TCP to include a Contact header with
> the address of the TCP SIP server, and then change the rules for
> response processing to accommodate this situation.

No. The whole idea is that you're supposed to put this TCP SIP server
port in the Via field, not the random port. With TCP, if the
connection is still open, responses are sent as normal to the source
port of the request. Only when the connection is closed, and a
response comes and needs to be forwarded upstream, a connection is
opened from the server to the port listed in the Via field.

> 
> [9] "Thus, the header in section 15.2 could also be written:..."
> Well, yes, but it would be a different header. You have changed not
> only the field names but also the values.

Should read "Thus, the message in section ....". Will be fixed.

> 
> More importantly, what does the following statement mean
> 
>    "These short forms are NOT abbreviations, they
>    are field names. No other header field abbreviations are allowed."
> 
> This is self-contradicting. First they are NOT abbreviations and then
> no OTHER abbreviations are allowed.
> 
> Anyway, how are they NOT abbreviations. There is no separate
> definition for the "f" header field, for example. It's just a short
> form for "From". That's usually known as an abbreviation.  If you just
> mean that proxies are not allowed to substitute one for the other
> (which is stated below) it should just say that.

Will fix.

> 
> [11.3]
>    "The UAC also notes the value of the To and From
>    header fields in each response. For each call leg, the To header
>    field becomes the remote address, and the From header field becomes
>    the local address."
> 
> Won't the From in the response always be that of the INVITE as sent by
> the UAC? Is the UAS allowed to change it in it's response?

Yes; its just for convenience of explanation. No, they can't change.

> 
> [15.2.1]
>   "... from the host 131.215.131.131." I guess this should read
> "csvax.cs.caltech.edu", which, in fact a DNS lookup reveals that it is
> currently mapped to, but the correctness of the spec should obviously
> not depend on this.

Will change to read "csvax...".

> 
> Also, two sentences later the IP addr 128.16.64.19 is mentioned which
> also is nowhere in the example.

Will change to "north.isi...".

> 
> In this and many other examples throughout the spec the host part of
> the Call-Id is different from the host part of the first Via header. I
> realize that the client is free to choose whatever fqdn it likes but
> wouldn't Call-Id's usually be constructed using the domain name of the
> local host?

Its not mandatory, I don't think, to even use the fqdn. As long as its
unique, that is sufficient.

> 
> [15.2.2]
> Last message (C->S: ACK...): why is this sent to the multicast address
> (maddr=...). Shouldn't it be point-to-point to jove.cs.caltech.edu ?

Probably the maddr field should be removed.

> 
> [15.3] "Since the two sides have agreed on the set of media, Watson
> confirms the call without enclosing another session description:"
> 
> That would be Bell confirming the call, not Watson.

yes. Will fix.

> 
> [15.3] In the first message (C->S: INVITE): how can the three IP
> dotted-decimal addresses all be different?  I would have thought that
> for a two-party call the IP addr in the SDP origin field would equal
> the address given in the SDP connection field, which would also be the
> address of the first Via SIP header. Of course the caller can be
> multihomed, but the example seems slightly far-fetched or at least
> atypical (?)

Will fix.

> 
> [15.5]
> "Watson's user agent sends the invitation..."
> Nope. It's good ol' Bell again.

Fine. Will fix.

> 
> [15.5]
>   P->H: INVITE
>   H->P: 404 Not Found
>   P->H: ACK this gives a tag param in the To field - this should be the
> same as that given by H in the response.

Yes.

> 
> [15.5]
>   C->X: ACK sip:[e-mail] SIP/2.0
> should be
>   C->X: ACK sip:[e-mail] SIP/2.0
> as this is the addr given in the Contact field of the X->P: 200 OK
> response. (yes, I read this pretty carefully :-))

Fine.

> 
> [15.8]
>   "the original request specified 256 kb/s total"
>   "The original request specified GSM audio, H.261 video, and WB
>    whiteboard"
>   "The response also states that multicast is not available"
> 
> Where does this wealth of information come from exactly?

Its not present, just an example of what might have been in a request to
create this response.

> 
> [Appendix C]
>   Why has the HTTP 'tspecials' character class been renamed
> 'separators'? It's not that that's a particularly brilliant name - it
> just seems silly changing it without a good reason.

Actually, *HTTP* changed that "without a good reason" :-) See
draft-ietf-http-v11-spec-rev-05.txt

tspecials and separators are equivalent in both RFC 2068 and the
HTTP/1.1 revision, just the name changed. Given that the revision will
supersede RFC 2068, it seems to make sense to use the new definition.
Not sure if a note is needed here. Hasn't been in the HTTP/1.1 revision
drafts since -03. Somewhere in draft-ietf-http-v11-spec-rev-03.txt it
says:

"Renamed tspecials BNF production to separators to avoid confusion with
  tspecials in RFC 2045. (Section 2.2)." (RFC 2045 is MIME message
bodies.)

> 
> [Appendix C]
>   The BNF for 'comment' includes (unlike the HTTP def) a quoted-pair
> thingy. This doesn't seem to be defined anywhere.

Will remove.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   [phone]                       Rm. 4C-526
EMAIL: [e-mail]
URL: http://www.cs.columbia.edu/~jdrosen