Firstly, I am still of the opinion that this is NOT an essential
correction to SIP, but rather a BCP. Clearly the record-route mechanism
in RFC3261 itself still works and works fine for the cases where it is
applicable. Documenting double-record routing makes sense, but I do not
believe it should replace what is in RFC3261 or obsolete it. There is no
reason to do it, and its unrealistic to think that everyone who is doing
rr-rewriting will go an change their implementation because IETF decided
to deprecate something that works.
Section 3.1: this is an unrealistic use case. If this were the actual
network, no media would be able to flow in the resulting session.
Section 3.2: the indented text seems to include both the original
rfc3261 text and commentary on it; I think only the orginal text should
be indented.
often been noticed that letting [RFC3261] with the Record-Route
rewriting as the only technique described in core specification is
dangerous, due to the fact that rewriting has some heavy drawbacks.
this is hyperbole, and not supported by the two points which follow:
1) Callee cannot sign the route set, because it gets edited by the
proxy in the response. Consequently, end-to-end protection of the
route set can not be supported by the protocol. The openness and
the end-to-end principles are broken (!)...
sign the route set?? This has never been possible. Even S/MIME doesn't
support that:
Header fields that can be legitimately modified by proxy servers are:
Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
Authorization. If these header fields are not intact end-to-end,
implementations SHOULD NOT consider this a breach of security
I don't know what real attack or real problem you are talking about here.
2) Proxy must implement special "multi-homed" stateful logic. On
the 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.
it is true that there is additional CPU cost. However, that is hardly
"dangerous". And, I suspect, in most cases, not a very big CPU burden.
I'm not opposed to double record-routing; I am taking objection to the
vilification of what is in RFC 3261.
Thus, on the request processing side: item 4 of section 16.6 of
[RFC3261], it SHOULD be noticed that the URI MAY contain the
I don't know what it means to SHOULD notice something. Why is this text
indented?
This technique has many benefits, and is completely backwards
compatible with [RFC3261]. It consists in putting as the first
value, the Route of receiving interface, including schemes and/or URI
parameters, and, as second value, the Route of the sending interface.
When processing the response, no modification of the recorded route
is required.
s/Route/URI
Section 5 has odd indenting.
The document is hard to follow; it intermixes restatements of RFC3261
sections along with other normative text which is not defined as a
restateemnt of rfc3261.
I think it would be a clearer document, in fact, if it were not an
essential correction and instead a clear description of how to double
record-route and when to do it.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.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
