Francois said:
Actually, now that I think of it, it may not be as bad as I tought.
If UAs are using sip-outbound with their proxies, it would handle the
vast majority of the links.
Between proxies, you would use DNS or static configuration normally.
Furthermore, between proxies, re-using of existing TCP/TLS may also be
done.
So maybe you are right
Dean Said:
It always tries TLS first, and if that doesn't work it either
1) falls back to something else or 2) gives up. The choice
between 1
and 2 is made based on local policy.
I think many of the assumptions we've been making seem to indicate
that if you just don't know, the only reasonable thing to do is try
TLS first. If there's nobody listening on the TLS port (but somebody
at the IP address), you should get an ICMP response pretty quickly
anyhow, then be able to decide on fallback.
If we hold the opposite true, and we try plain SIP/UDP first and only
move to TLS when plain SIP fails, we're going to be in for a world of
delay-hurt (waiting for that plain SIP/UDP transaction to time out)
and never opportunistically using TLS anyhow.
Of course, it's better if you "know" up front, which is part of what
the argument in favor of transport=tls is asking for. But given that
we have ways for knowing in many of the other cases, this may not be
critical.
Of course, if we'd started with a plain connection, discovered TLS
capability in a greeting message (aka EHELO) and then done an upgrade
to that connection using something like STARTTLS, we wouldn't be
having this discussion. It would have just worked. Boy do I feel dumb.
--
Dean
_______________________________________________
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
