This is exactly where we are disagreeing.
How do you _tell_ P1 that you want to reach P2 using TLS in
the first place.
As I said elsewhere in the thread, I don't think leaving this
unspecified ("you just do this with the configuration of the
proxy") is the right answer. If you have DNS, you tell P1
about P2 using DNS. If you don't have DNS, using the
transport parameter in the URI you hand it seems pretty
natural. That's how you're going to tell it to use udp or tcp...
I think I finally understand what you are saying...
Say UAC sends request to Request-URI uas at p2;transport=tls.
The transport parameter indicates that the resource in the
request URI (uas at p2) is the one that needs to be contacted with
TLS. Therefore, it would be the P1 -> P2 link that would use
TLS in this case (since P2 owns that domain). And P2 could use
whatever
it wants for P2 -> uas at uaspc.p2. And similarly, uac -> P1 (or P1 to
any
other
proxy between P1 and P2) could use whatever they want.
The use case would be where the UAC "trust" it own domain and does not
feel it necessary to use TLS, and/or the UAC "trusts" the target
domain
for being responsible of that happens inside the target domain. And
finally,
the UAC does not really care if there are other types of proxies in
the
middle (not responsible for a specific domain), that may not use
TLS.
While I understand that this is in theory something that could be
solvable, I'm not sure why it is such an interesting case. Seems to me
it is only of value if the only "vulnerable" hop is the one between
the
source and target domains, and if there are no other proxies between
them
(e.g., no "Service provider").
In fact, it pretty much describes to me why you should be using
SIPS in
the first place.
Do we *really* want to reintroduce transport=tls for this case?
Side note: I just want to point out that RFC 2543 did NOT allow the
presence of the transport parameter at all in a Request-URI and 2543
servers would ignore it or remove it.