Ok - we're closer, but not quite together yet.
Lets start with a different message from the UAC where the RURI is
simply
sip:[EMAIL PROTECTED]
The authority for [EMAIL PROTECTED] (the person that might send a register
request
with that in the To: header) wants requests to go to
sip:[EMAIL PROTECTED]
and they want it to go over TLS. What they'd _like_ to do is send a
register
request with a contact that says to use TLS, or at most, send a
single URI
to the operators of P1 that describes where to send requests that
show up
for [EMAIL PROTECTED]
What tools do we give them to make the statement they want to make?
RjS
On Jun 4, 2007, at 4:30 PM, Francois Audet wrote:
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
