Juha Heinanen wrote:
Francois Audet writes:
> So: to summarize, with the current draft, the double record-route
> procedures are never used.
thanks for the your interpretation that differs from what i read earlier
on this list.
in order to make this perfectly clear to proxy implementers, can
someone, please, tell exactly what the proxy should so in terms of r-r
headers and r-uri when request with sip: uri scheme comes in over udp
and goes out over tls.
I think this is exactly in the scope of rr-fix draft to clarify this point.
Just to summarize how it *should* work from the beginning;
1) if your are not sure on what transport is supported by next elements,
you do not put any transport in your RR header, as specified in sentence
of item 4 of section 16.6, "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")
2) It is assumed the proxy will put a a logical name in Record-Route,
and then, according to RFC 3263 procedures, any SIP element that
will try to reach your proxy should find an appropriate transport
following these procedures (section 4.1,
basically:
If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used.
Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI. Similarly, if no transport protocol is specified,
and the TARGET is not numeric, but an explicit port is provided, the
client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is
because UDP is the only mandatory transport in RFC 2543 [6], and thus
the only one guaranteed to be interoperable for a SIP URI. It was
also specified as the default transport in RFC 2543 when no transport
was present in the SIP URI. However, another transport, such as TCP,
MAY be used if the guidelines of SIP mandate it for this particular
request. That is the case, for example, for requests that exceed the
path MTU.
Otherwise, if no transport protocol or port is specified, and the
target is not a numeric IP address, the client SHOULD perform a NAPTR
query for the domain in the URI.
3) So, in your case, if your proxy switch from UDP to TLS, it means the NAPTR records of your proxy
should answer with higher priority "TLS" for request coming from your "callee
side",
and UDP for requests coming from your "caller side"...
--> Multiple questions need clarifications here, because people want to be able
to switch from one transport to another, use numeric ip addresses, and still
make the RR work. So, that's why I explained a typical "workaround" is to put
a transport parameter on the RR. (if the proxy decides to
make RR rewriting, it will put just one RR with the transport used to reach the
next element, and when seeing the 200 OK response, change that transport
to the transport used with the previous element.
It explains you why I said that the "Route set seen by the callee will be different
than the Route Set seen by the callee" when rewriting.
Double Record-Routing does not solve that problem at all, this is still a topic
to be discussed, and I am open to any suggestion about this issue.
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
