\section{Changes To Be Made}

NOTE: Almost all of these require further discussion or may already
have been integrated into the main spec.

\begin{itemize}

% 1999-04-08: Reported by: Adam Roach, Ericsson
% Changed: 

\item Bug:  Consider a proxy that implements an ACD service.  It proxies
call requests to operators based on some complex logic.  After receiving
and {\INVITE}, proxying it, and forwarding the response, the proxy
eventually times out its state.  Later on, an {\ACK} (a late one, or one
that has been wandering in the network) arrives.  Where should the proxy
send this?  Ideally, the proxy should know where it sent the {\INVITE}, and
send it to the same place.  This is not workable for complex forwarding
logic.  To fix this, the {\ACK}s should go directly to the UAS.  This
will occur if a UAS inserts a Contact into the 200 OK, and if the UAC
honors this in subsequent requests (including {\ACK}).  However,
insertion of Contact, and honoring of Contact, are SHOULD, not MUST, so
this "lost ACK" case is still possible in conditionally compliant
implementations.  TO fix this, (1) insertion of a Contact header, and
(2) honoring of a Contact header, should be made MUST strength.  (Q:  is
this the only solution???)

% 1999-04-08: Reported by Cicso
% Changed: 

\item Bug:  Section 4.2.6 specifies that, for a {\REGISTER} request, the
user name of the Request-URI MUST be empty.  While it does not mention
anything about the ``@'' sign, the SIP-URL BNF is defined so that an "@"
sign is used only in conjunction with a user ID.  The implication that
no ``@'' sign appears in a {\REGISTER} Request-URI is never explicitly
stated.

% 1999-04-08: Reported by: MCI
% Changed: 

\item Issue:  Usage of Content-Length.  Spec is not that clear under
what conditions its needed, particularly with TCP.  This should be
clarified.  Another issue:  should Content-Length just be made
mandatory?  It's not as a carryover from HTTP; do we have the same
assumptions they do?  Also, the section on Content-Length does not
discuss behavior for requests over TCP that do not contain
Content-Lengths (Answer:  if no Content-Length is present in requests,
the request packet must be terminated with a close connection.  However,
having the client close a connection is the same as sending a CANCEL, so
no response is ever received.  Now, a client *can* do this, but it makes
no sense)

% 1999-04-08: Reported by: HP
% Changed: 

\item Issue:  In {\REGISTER} requests, should the request URI be a fully
qualified hostname, or the domainname:

\begin{verbatim}
  REGISTER sip:machine.company.com SIP/2.0
\end{verbatim}

or
\begin{verbatim}
  REGISTER sip:company.com SIP/2.0
\end{verbatim}

It matters since registrars check if the domain name is there's before 
accepting the registration. The comparison might fail if the wrong thing is 
sent. Answer: probably a proxy/UAC SHOULD send it to company.com 
(and then use SRV to find the right machine), but a registrar SHOULD 
accept both fully qualified host names and domain names in comparisons. In 
fact, the registrar probably should be making this comparison on the To 
field, not the Request-URI!

% 1999-04-09: Reported by: Various
% Changed: 

\item Issue:  A sends an {\INVITE} to B, and B returns a 180 with a tag. 
Then, A sends BYE to B, without a tag in the To field.  Should B accept
this BYE or not?  Answer:  not sure; I think actually it says somewhere
in the spec you are not supposed to initiate a new transaction until the
previous completes.

% 1999-04-09: Reported by Lucent
% Changed: 

\item Bug:  A {\INVITE}s B through a proxy, B responds to A with a tag in
the To field.  Later, A sends a re-{\INVITE} to B, with a tag in the To
field, through the proxy.  This request is malformed, so the proxy
returns a 400 error.  Normally, a proxy will insert a tag into the To
field of a 400 response.  But here, it cannot, since a tag is already
present in the request.  Thus, the rule should be that if a request
arrives with a tag, the entity sending a response MUST NOT insert an
additional tag, even if it a different entity than the one that created
the tag in the first place.

% 1999-04-19: Reported by Lucent
% Changed: 

\item Bug:  The spec says that if a server receives a {\CANCEL} for which
it has no pending transaction, it returns an error.  This, however, is
not true for a proxy.  A stateless proxy SHOULD forward the {\CANCEL} as it
would any non-{\INVITE} request. 

\item Table 5 lists \header{WWW-Authenticate} as a response-header
allowed only in 401 responses.  However, section 13.2 allows its reuse
in requests containing \texttt{Require:  signed-response}
header.  Also examples in section 14.1 have \header{WWW-Authenticate} in
{\INVITE} requests with no \texttt{Require:  present}.

A client {\MAY} require that a server sign its response by including a
\texttt{Require: signed-response} request header field. 
The client indicates the desired authentication method via the WWW-
Authenticate header.

This is also an inconsistency.  If we do allow this, then
\header{WWW-Authenticate} must be a request and response header field,
and the \header{Authorization} header as well, since then it is included
in a signed response.

\item Text on including Authorization in responses and WWW-Authenticate
in requests needs to be added.

\end{itemize}
