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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
