Re: Evaluation: draft-ietf-sip-symmetric-response - An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing to Proposed Standard

[hardie@qualcomm.com]

Ted Hardie          [   ]     [   ]       [  x]      [   ]

First, let me say that a large number of the issues I had
with the document turned out to be very well documented
in the IAB considerations section of the draft.   A few
other issues:

In Section 3:

  When the client sends the request, if the request is sent using UDP,
   the client MUST be prepared to receive the response on the same
   socket the request was sent on. Specifically, it MUST be prepared to
   receive the response on the same IP address and port present in the
   source IP address and source port of the request. For backwards
   compatibility, the client MUST still be prepared to receive a
   response on the port indicated in the sent-by field of the topmost
   Via header field value, as specified in Section 18.1.1 of SIP [1].


It seems pretty clear from the "on the same socket" that the following
sentence means the IP address and port present in the source IP
and port of the request _when it is sent_.  I think it would be clearer,
though, to use phrasing like "it MUST be prepared to receive the
response on the same IP address and port it used to populate
the source IP address and source port of the request.".

Also in Section 3:

   To keep the binding fresh, the client SHOULD retransmit its INVITE every 20
   seconds or so. These retransmissions will need to take place even
   after receiving a provisional response.

based on the idea the one minute seems to be a common UDP binding lifetime.
Section 9.3 notes, however, that there is no way to determine the UDP binding
lifetime.  Is there anyway to introduce a growing/shrinking algorithm
to this for cases where the binding lifetime is much longer (to avoid the
aggressiveness of 20 seconds for an arbitrary period of time) or to handle
the cases where the binding lifetime is shorter than 20+transmission time to
the NAT (since this has to handle the NAT being at some arbitrary place in
the topology).

In the initial section of 9:

   The client can then perform an additional registration,
   using this address in a Contact header. This would allow a client to
   receive incoming requests, such as INVITE, on the socket through
   which the registration was sent.

As is noted below that point, there are cases in which the port binding
is only valid for the server to which the original registration was sent.
Will the Contact header "leak" that so that a direction connection between a
different sip agent (user or proxy) might attempt to use it?  If so, a forward
pointer to the limitation might be useful here.

I would personally consider the UNSAF document a normative reference,
but this is not a big deal.