Subject: [Sip] Review of draft-ietf-sip-record-route-fix-03

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 07 Aug 2008 20:00:30 +0200

Hello,

Keith asked me the review the sip-record-route-fix draft.

I think the draft is important and summarizes well what is state of the 
art for the majority of the SIP implementations any way.

Most of my findings are just minor fixes. Except the following two:

Section 6.1, 2nd paragraph on page 17:
   What happen if... still problemtic.

I do not agree with what is stated in this paragraph. It works only if 
both UAs get to the result of using UDP as transport. But if both would
come to the result to use TCP (or any other transport which is not equal 
to the one which was used by UA2 for its registration), the problem 
still remains that UA2 is registered only via UDP. And later on UA2 
would have to switch to TCP because of the DNS resolution.
In my attached patch I tried to fix this already with some more words.

Section 6.2, first paragraph:

Why does this paragraph open the door again for rewriting, if the rest 
of document recommends this as an depricated technique? Is this intentional?

I'm attaching a patch with my minor fixes and suggestions/add-ons for 
clarification. Let me know if you would like to receive it in a 
different format.

Best regards
   Nils Ohlmeier
--- draft-ietf-sip-record-route-fix-03-orig.txt	2008-08-03 23:30:32.000000000 +0200
+++ draft-ietf-sip-record-route-fix-03.txt	2008-08-07 19:20:22.000000000 +0200
@@ -376,7 +376,8 @@
       -- 192.0.2.1
 
    UA2 has one interface with address, 192.0.2.2.  There is potentially
-   no IP level route between UA1 and UA2; no ping; no traceroute.  They
+   no IP level route between UA1 and UA2 (pinging or traceroute does not
+   work between these two hosts). They
    live in entirely different networks.  But they can still exchange SIP
    messages, because P is a SIP Proxy.  This works in SIP because P can
    "record-route".
@@ -432,13 +433,13 @@
    current text indicates that the Record-Route value MUST be modified
    to contain a SIPS URI when routing a response from non-TLS to TLS
    transports.  This makes sense only if the request indicated SIPS.
-   Hop-by-hop TLS needs to be covered separately, see [BUG735]).
+   Hop-by-hop TLS needs to be covered separately, see [BUG735].
 
    This list enlights the utility of rewriting and double Record-Routing
    techniques which apply for any multi-homed proxy use case, whenever
    the proxy changes its IP address, the transport parameter or the URI
    scheme between incoming and outgoing interfaces.  This is why, these
-   techniques are described, compared and discussed in sections 4 and 5;
+   techniques are described, compared and discussed in sections 4 and 5,
    the specific question to put or not the transport parameter on
    Record-Route is then discussed in Section 6.
 
@@ -467,7 +468,9 @@
    request phase, it goes through output interface calculation and
    writes the output interface into the route.  It must then inspect all
    responses, grep for an input interface, and selectively edit them to
-   reference the correct output interface: this is a CPU drag.
+   reference the correct output interface. And this has to be done for
+   dialog initiating and in-dialog requests and responses: this is a 
+   CPU drag.
 
    Therefore this document recommends not re-writing the Record-Route.
    Instead, proxies SHOULD use the Double Record-Route approach as
@@ -518,17 +521,19 @@
    completely backwards compatible with [RFC3261].  Generally speaking,
    the time complexity will be less in double Record-Routing since on
    the response, the proxy does not have to do any re-writes (and thus,
-   no searching).
+   no searching). And the handling of in-dialog requests and responses
+   requires no special state-full handling any more.
 
-   When double Record-Routing, the proxy will have to handle the
+   When double Record-Routing is used, the proxy will have to handle the
    subsequent in-dialog request(s) as a spiral, and consequently devote
-   some space to maintaining a transaction.  In order to avoid a spiral,
-   the proxy has to be smart and scan an extra route ahead to determine
+   some space to maintaining an additional transaction.  In order to avoid
+   a spiral,
+   the proxy can be smart and scan an extra route ahead to determine
    whether the request will spiral through it.  If it does, it can
    optimize the second spiral through itself.  Even though this is an
    implementation decision, it is much more efficient to avoid
    spiraling.  So, it means in section 16.4, "Route Information
-   Preprocessing" f[RFC3261], implementors can choose that proxy MAY
+   Preprocessing" [RFC3261], implementors can choose that proxy MAY
    remove two routes instead of one when using the double Record-
    Routing.
 
@@ -538,8 +543,8 @@
    annotates the dialog state on each UA.  In this example, proxy P1,
    responsible for the domain biloxy.com, receives a request from an
    IPv4-only upstream client.  It proxies this request to an IPv6-only
-   downstream server.  Proxy P1 is running on a dual-stack host; on the
-   IPv4 interface, it has an address of 192.0.2.1 and on the IPv6
+   downstream UA.  Proxy P1 is running on a dual-stack host, on the
+   IPv4 interface, it has an address of 192.0.2.254 and on the IPv6
    interface, it is configured with an address of 2001:db8::1.

@@ -900,9 +905,10 @@
    the Record-Route URI.
 
    What happen if the proxy had record-routed its logical name (e.g.
-   p1.example.com)? if UA1 and UA2 use the same DNS server, [RFC3263]
+   p1.example.com)? If UA1 and UA2 use the same DNS server, [RFC3263]
    procedure would resolve to the same transport on both sides and
-   scenario should work.  However, if one of the UA sends an initial
+   only if the resulting transport would be UDP the scenario would work.
+   However, if one of the UA sends an initial
    request using a different transport than the one configured in DNS,
    this scenario is still problematic.
 
@@ -996,9 +1002,10 @@
    proxy SHOULD put a Record-Route header as soon as it changes the
    transport protocol parameter between its incoming and outgoing sides.
 
-   By extension, a proxy SHOULD also put a Record-Route header for any
-   multi-homed situation (as the ones described in this document; scheme
-   changes, sigcomp, IPv4/IPv6...) that MAY impact the processing of
+   By extension, a proxy SHOULD also put a double Record-Route header for any
+   multi-homed situation (as the ones described in this document: scheme
+   changes, sigcomp, IPv4/IPv6, transport changes, ...) that MAY impact
+   the processing of
    proxies being on the path of subsequent requests.

@@ -1021,9 +1028,13 @@
 
       - Record-Route header interoperability problems on transport
       protocol switching scenarios have been outlined and described in
-      section 6.  This last section gives some recommendations to UA and
-      proxy implementations to improve the situation.
-
+      section 6. Proxies SHOULD use Double Record-Routing for any
+      multi-homed situation that MAY impact the further processing.
+      UAs SHOULD NOT offer options to overwrite the transport for
+      initial requests. Further UAs SHOULD rely on DNS to express their
+      desired transport and SHOULD avoid IP addresses with transport
+      parameters in this case. Finally UAs SHOULD be ready to switch
+      transport between the initial request and further in-dialog messages.

_______________________________________________
Sip mailing list  https://www.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