Subject: SIP: comments on the spec

From: Anders Kristensen <[email-masked]>
Date: Fri, 25 Sep 1998 23:33:06 +0100

I recently read the SIP spec (-09) pretty carefully.  This is a bunch of
issues, comments, bugs, nits, suggestions, etc. that came up.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

[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?

[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?

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.

[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).

[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...

[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.

[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.

[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.

[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.

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

[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.

[6.37] BNF syntax broken - should be like From BNF:

  To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )

[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.

[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.

[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.

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.

[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?

[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.

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

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?

[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 ?

[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.

[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 (?)

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

[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.

[15.5]
  C->X: ACK sip:[email-masked] SIP/2.0
should be
  C->X: ACK sip:[email-masked] 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 :-))

[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?

[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.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Oct 1998 10:06:19 -0400

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.

> connections" means here. What about multicast SIP requests, for

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".

>   (token | (token "=" (token | quoted-string)))

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

> 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.

> here and it should be left to other specs (as in fact it was in

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.

> 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.

>    party indicates the data types it is willing to receive."

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.

> 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. 

> support in SIP minimal, especially since it's on the fringe of what

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.

>  - and fix up Via fields with 'received' info as described in 6.40.1.

We'll fix.

>         Content-Type    =    ( "Content-Type" ":" media-type

Fixed.

> 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.

>   To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )

Will fix.

> 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.

> 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.

> only the field names but also the values.

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

> (which is stated below) it should just say that.

Will fix.

> 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.

> currently mapped to, but the correctness of the spec should obviously

Will change to read "csvax...".

> also is nowhere in the example.

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

> wouldn't Call-Id's usually be constructed using the domain name of the

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

> (maddr=...). Shouldn't it be point-to-point to jove.cs.caltech.edu ?

Probably the maddr field should be removed.

> That would be Bell confirming the call, not Watson.

yes. Will fix.

> multihomed, but the example seems slightly far-fetched or at least

Will fix.

> Nope. It's good ol' Bell again.

Fine. Will fix.

> same as that given by H in the response.

Yes.

> response. (yes, I read this pretty carefully :-))

Fine.

> 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.

> 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.)

> 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:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 14 Oct 1998 13:32:20 +0100

Hi Jonathan and everyone else,

> Thanks for you careful reading.

My pleasure.

Thanks for the response. Below I comment on just those items which are
still not completely resolved (to me at least).

Anders

> the wording to "an application program tham sends SIP requests".

As it stands the text suggests that first the connection is established
and then SIP messages are exchanged, not that the connection is defined
by the messages exchanged, so yeah, I think some re-phrasing is called
for.

> by definition, as indicated in the text above the figure.

Right. I think that ideally the grammer shouldn't allow characters to
occur in places of SIP URLs where they are in fact not allowed, but in
the interest of keeping the spec readable it might be preferable to keep
it as is with the additional constraints outside the grammar.

> this part of the request URI.

A server needs to be able to figure out which string of characters make
up the 'user' field, but it doesn't need to be aware of whatever
structure is imposed on this field by, say, a telephony gateway server.
As far as I can tell the only entities that routes SIP requests based on
the 'user' field are telephony gateways. They will need to know the
syntax and semantics of this field of course, but that's a different
matter.  So what I'm musing about here is that a non-telephony gateway
SIP entity just needs to be able to decide what part of a SIP URI makes
up the contents of the 'user' field, and that this is satisfied without
fig. 4, and hence it shouldn't be there.

> clarify the relationship.

I remember vaguely some problem with this but I can't think of it right
now. Maybe I'll get back to you on that one ;-)

> not restrict this in any way. Text will be added to clarify this.

That's not what appendix B (Usage of SDP) says:

   "It is assumed that if caller or callee include a particular media
   type, they want to both send and receive media data. If the callee
   does not want to send a particular media type, it marks the media
   entry as recvonly. If the callee does not want to receive a   
particular media type, it may mark it as
   sendonly. If the callee wants to neither receive nor send a
   particular media type,
   it sets the port to zero. (RTCP ports are not needed in this case.)

   "The caller includes all media types that it is willing to send so
   that the receiver can provide matching media descriptions."

(BTW the first paragraph is bogus in the ascii version of the spec.)

But OK so SIP entities use SDP bodies to indicate receive capabilities.

This means that the comment in section 4.2.2 (Ack) saying:

   The ACK request MAY contain a message body with the final session
   description to be used by the callee. If the ACK message body is
   empty, the callee uses the session description in the INVITE request.

doesn't make much sense to me. Basically the UAC says what it's able to
receive in the INVITE req and the callee gets a chance to complain about
that in its response (606 Not Acceptable) at the same time at which it
says what *it* is willing to receive. The caller can then complain about
that (by sending a BYE req) but why would it change its mind at this
point about what it is capable of receiving?

There are two cases where I believe the SDP body indicates something
other than the senders receive capabilities.

One is the case of the UAS responding with a 606 status code. Example
15.8 indicates that the SDP body in this case indicates the media types
etc. which the sender of the 606 is capable or willing to generate. BTW
this use of the message body should probably be listed in section 8.1
together with the other uses.

The other case is the meaning of the SDP in invitations to multicast
conferences. There, the SDP body really does indicate what the callee
must be able to receive and/or what it may generate, depending on the
presence of recvonly/sendonly SDP parameters.

> opened from the server to the port listed in the Via field.

OK, I was thinking of the case where a client C connects to a stateless
proxy server using TCP and, say, local port 7777. The question was how
will the proxy figure out which TCP connection to use for the incoming
response, but if it maps the pair {C, 5060} rather than {C, 7777} to the
TCP connection there's no problem.

[15.2.1]
> unique, that is sufficient.

Right, but in the interest of making the examples as straight-forward
and realistic as possible maybe they should use the local host name.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Oct 1998 11:22:28 -0400

> by the messages exchanged, so yeah, I think some re-phrasing is called

Folks are invited to take a look at the "-10" draft-draft (on the SIP
web page, curently in PDF and PS only) that incorporates these comments
and then let us know whether this is satisfactory.

> fig. 4, and hence it shouldn't be there.

It seems useful to ensure interoperability between clients and ITGs and
harmless otherwise, so I'm not quite sure why you are so strongly
opposed to this. After all, ITGs will be an important class of SIP
servers.

>    it sets the port to zero. (RTCP ports are not needed in this case.)

The SDP experts can chime in here....

Whether SDP is capable of providing sender capabilities is immaterial to
SIP, particularly since that may well depend on the version of SDP and
whatever optional attributes you supply. Since this debate is out of
scope with regards to SIP, we've removed all references to SDP
indicating receiver (vs. sender and receiver) capability.
 
> point about what it is capable of receiving?

This is indeed not particularly likely, but possible, namely if the set
of capabilities that it has is not simultaneous. I've recently heard
about a device that can't hold code for all its codecs in its memory and
downloads codecs across the LAN as needed. Once it knows what the other
side can receive, it may well have to restrict its codecs to below what
it was offering initially. Example: say, a device can receive/send G.723
and G.729, but not both at the same time. In the INVITE, it would
obviously advertise both codecs. Depending on the response from the
other side (which would presumably indicate one or both of these
codecs), it would then choose one of them and announce this in the ACK.

> and realistic as possible maybe they should use the local host name.

They now do.