Juha,
I believe the issue you are implicitly identifying is the following: it
should always be possible to deterministically determine the transport to
use towards a next hop learned from a Record-Route header. For a SIPS URI
that implies that the 'transport' parameter MUST be present, because (in
theory) it could be both TCP and SCTP (ref RFC3261 section 18, where it says
"[...] transport protocols like TCP and SCTP, or TLS over those [...]".). It
is true that RFC3263 states that TCP SHOULD be used for SIPS in case there
is either an explicit port or a numeric IP address, but that does not mean
that it _was_ indeed used. And there is nothing in RFC3261 that says proxies
MUST support TLS over TCP (it just says TLS and TCP).
A stateful proxy/endpoint could maintain state about which transport was
used. For these connection oriented transports the connection itself can be
used as such, but as you mentioned it may get closed at one point and then
the state would be lost. In any case, stateless proxies must be able to
determine the transport based on only the URI provided.
The use of transport=tls was deprecated for the above reason (SCTP can also
go over TLS). So in your case you should be using
"sips:host[:port];transport=tcp", there is no implication of transport in
that.
And RFC3261 should be updated to say that proxies "MUST support TLS over
TCP", along with some inconsistencies (e.g. 18.1.1 says "It is 5060 for UDP,
TCP and SCTP, 5061 for TLS." while 18.2.1 says "(5060 for TCP and UDP, 5061
for TLS over TCP)"
Regards,
Jeroen
Juha Heinanen wrote:
Francois Audet writes:
But for that, you can use SIPS in Record-Route, no?
It would be semantically identical, no?
i don't know and don't care, because i don't use sips uri scheme for
anything. it is artificial to imply transport protocol from uri
scheme, when there is a way to tell it straight. perhaps someone
will later invent some other secure transport protocol to be used
with sips when then implication will fail.
-- juha
_______________________________________________
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
