Juha Heinanen wrote:
Thomas Froment writes:
> 1) Do we want to *deprecate* record-route rewriting or just recommend
> double R-R but let R-R rewriting as a valid alternative?
can you clarify what you mean by r-r rewriting? if i recall correctly,
according to rfc 3261 r-r headers are added during dialog initiating
request and after that route set does not change, i.e., proxies only
need to r-r initial request.
Yes, RR-rewriting is described in section 3.2 of
http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt,
and drawbacks outlined in section 4...
Basically, the R-R has to be modified in the 200 OK response so that the
Route set seen by the caller will be different than the Route set seen
by the callee...
> 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".
my proxy may be talking to a proxy of another organization using tls no
matter if uri scheme in requests is sip or sips. if request comes in
over udp and goes out over tls, should my proxy double r-r and add
transport=tls or what?
So, I voluntarily omitted to discuss the "transport=TLS" use case since
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt already
take care of it,
so "sips:" scheme should be used and double RR is also to be recommended
when transiting from "sip:" to "sips:", it is described in the sip/sips
document.
By the way, another question comes to my mind, should we ask Francois
Audet to reference this record-route document in its "double RR" section?
The open issue I described here was: "do we recommend to double R-R
*and* put the transport parameter on RR header in some circumstances?"
(which is a different
wording than current text which says "SHOULD NOT put any transport
parameter etc...".
-
Thomas
_______________________________________________
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
