Subject: [Sip] Comments on sip-outbound-00

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 29 Sep 2005 02:49:50 +0200

Hi guys,

as I'm about to (partially) implement your draft ietf-sip-outbound-00 here 
some comments (sorry for the lengthly input, but I hope its worth the 
effort):

We already do not accept incoming connections any more on our UAs. But in my 
opinion this makes only sence if you obtained GRUU contacts from your 
registrar. If your registered contacts are all GRUU contacts with flow-id's 
then you can safely assume that all incoming requests will come over one of 
these flow's. Otherwise still some may have to open a new connection to you, 
for example in case of a transfer.
I think this is also the answer to your open question regarding GRUU. In case 
there are NATs or firewalls in between the two flow parties, a transfer will 
only work if the Refer-To header contains a global routeable URI, so that the 
new request goes over the existing flow.
In case there are no "blocking elements" in between the two flow ends, it 
could also work without a GRUU contact in the Refer-To header, but the 
destination UA would still have to accept incoming connections.
Thus I think the requirement for Record-Routing (in section 5.2) is more or 
less useless. Instead of the Record-Route a GRUU would be required. In case 
of missing GRUU  support Record-Routing would fix mid dialog requests, but 
not transfer scenarios.
Bottom line: I would not require GRUU support. But if you explain this 
scenario in your draft, the/a strong recommendation for implementing GRUU 
should be obvious.

Currently there is no way for the UA to determine if the proxy supports 
flow-id or not. The result is that the UA does not know if it safely can 
ignore any new incoming connections or not.
Currently I have not a real idea how this could be achieved. But as this a 
feature between the UA and the first hop and not the final request target it 
should be a very generic solution. Do we have a header which is added by the 
middle path elements and is returned to the UAC, except Record-Route (which 
is normaly not used for REGISTER requests)?

Forget my last comment which I sent to you during the last IETF about the 
flow-id numbers not starting from 1. As we (snom) have to store the relation 
between our connections and the flow-id's, we can also start from 1 all the 
time. So my only concern about always starting at 1, is that every potential 
attacker knows this information too. Although it is currently not clear to me 
how someone could use this information. Maybe this information would ease an 
attack on the edge proxy algorithm 1 for choosing the correct flow.

Can you enlight me how a UA which registers at a registrar with flow-id 
support should obtain an URI with the "stun" parameter (last paragraph in 
section 7) to decide what keepalive mechanism is supported by the server?
I think a new header in the 200 OK reply to the REGISTER request, or a 
parameter appended to the returned Contact, which lists the supported 
keepalive mechanisms would make more sence and would be a lot more flexible 
and extendible for the future.

The section 4.1.1 "Instance-ID Selection" appears a little bit unmotivated in 
the middle of the text. Although it is clear that an instance-id is important 
for a working outbound solution, I think you should add a sentence why you 
are talking about this topic here (again).

In the UA section 4 it should be mentioned in which requests the flow-id makes 
sence. But as usually it can not be guaranteed that always a REGISTER if the 
first request to the proxy which established the flow, I assume that the 
flow-id should be present in every Contact, or?

Although I understand that the outbound and connection-reuse drafts have 
different target groups, did you considered to merge these two drafts into 
one?

Why is the file name version still 00, although there are sections talking 
about versions 00 and 01. Should the version number be 02?

Please find attached a diff against this version:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-00.txt
for fixing some typos.

Regards
  Nils Ohlmeier
-- 
gpg-key: http://www.ohlmeier.org/public_key.asc
--- draft-ietf-sip-outbound-00.txt	2005-08-27 00:20:56.000000000 +0200
+++ draft-ietf-sip-outbound-00.txt.new	2005-08-27 00:21:07.000000000 +0200
@@ -369,7 +369,7 @@
    loads on the server and is referred to as the avalanche restart
    problem.  The multiple flows to many servers help reduce the load
    caused by the avalanche restart.  If a UA has multiple flows, and one
-   os the servers fails, it can delay some significant time before
+   of the servers fails, it can delay some significant time before
    trying to form a new connection to replace the flow to the server
    that failed.  By spreading out the time used for all the UA to
    reconnect to a server, the load on the server is reduced.
@@ -383,7 +383,7 @@
    routed through the edge proxy.  There could be a NAT for FW between
    the UA and the edge proxy and there could also be one between the
    edge proxy and the Registrar.  This second case typically happens
-   when the Edge proxy is in an enterprise the the registrar is at a
+   when the Edge proxy is in an enterprise the registrar is at a
    service provider.

@@ -600,7 +600,7 @@
    between 30 and 60 seconds after the failure of the first registration
    request.
 
-4.4  Registration by other other instances
+4.4  Registration by other instances
 
    A User Agent MUST NOT include an instance-id or flow-id in the
    Contact header field of a registration if the registering UA is not
@@ -626,7 +626,7 @@
    change.  Any time the registrar checks if a new contact matches an
    existing contact in the location database, it MUST also check and see
    if both the instance-id and flow-id match.  If they do not match,
-   then the they are not the same contact.  The registrar MUST be
+   then they are not the same contact.  The registrar MUST be
    prepared to receive some registrations that use instance-id and
    flow-id and some that do not, simultaneously for the same AOR.
 
@@ -749,7 +749,7 @@
    Algorithm 1: The proxy base64 decodes the user part of the Route
       header.  For TCP, if a connection specified by the file descriptor
       is present and the creation time of the file descriptor matches
-      the creation time encoded in the Route header, then proxy forwards
+      the creation time encoded in the Route header, the proxy forwards
       the request over that connection.  For UDP, the proxy forwards the
       request from the encoded file descriptor to the source IP address
       and port.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip