> 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 [EMAIL PROTECTED];transport=tls.
The transport parameter indicates that the resource in the
request URI ([EMAIL PROTECTED]) 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 -> [EMAIL PROTECTED] 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.
_______________________________________________
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
