It seems that, the document can end with some modifications not
requiring to change any *must* statement, so if i understood well what
Robert said, it is still possible to change a *should* (i.e. "you can
bypass it only if you have a very good reason"...) in a "bcp" (best
practice having to justify what this very good reason IS...).
Before going to version -01, I would like to poll the working group on
the following open issues:
1) Do we want to *deprecate* record-route rewriting or just recommend
double R-R but let R-R rewriting as a valid alternative?
When I wrote the first version of the draft, I decided to let the two
possibilities open, but some people told me there was probably a
consensus for deprecating.
Is rewriting a valid technique given the fact that end-to-end protection
of the route set can not be supported by the protocol when authorizing this?
So, maybe we can start a poll here, who is in favor of deprecating, who
is opposed and why?
2) About transport switching, as it is described yet, one of the
observed proxy implementation behaviour is to make double R-R, puting
the transport parameter
(for instance, if we have a proxy switching from TCP to UDP, and using
numeric IP addresses), and thus, ignoring the SHOULD
statement:[RFC3261], item 4 of section 16.6, "The URI placed in the
Record-Route header field value MUST be a SIP or SIPS URI. [...] The URI
SHOULD NOT contain the transport parameter unless the proxy has
knowledge(such as in a private network) that the next downstream element
that will be in the path of subsequent requests supports that transport".
Actually, double RR with transport parameter is ok as long as the
dowstream element support that transport. It is, in the most general
case, always the case
as long as proxy is using one on the transport mandated in RFC3261 (UDP,
TCP).
The problem occurs of course if the proxy is switching, for instance,
from TCP to SCTP, then, if the next SIP element supports that transport,
it is still dangerous:
let's assume this is a proxy which is NOT record-route, then, when a
subsequent request arrives, the second SIP element may be asked to route
the request
using a Route with transport=SCTP parameter it does not support.
What to do in that case? I suggest to recommend to double -RR WITH
transport parameter *only* if transport is a mandatory transport (UDP or
TCP, possibly TLS, but should be replaced by sips in a near future, so
let's forget the TLS transport), OR if proxy has knowledge that *any*
subsequent element do support that transport.
Any thoughts?
-
Thomas
Dean Willis wrote:
In Prague we recorded a consensus on documenting the various fixes to
record-route as described in:
http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt
While we agreed to undertake this effort, we left open the discussion
of how to achieve it.
Two proposals were made:
1) Recast the solution as a BCP
2) Move this into the "Essential Corrections" process for RFC 3261
bugfixing.
I currently lean towards number 2, but we should discuss it.
--
Dean
_______________________________________________
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
_______________________________________________
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
