On Jun 18, 2007, at 7:54 PM, Vijay K. Gurbani wrote:
Paul Kyzivat wrote:
True. But how many UAs support sipsec? :-)
Touche! Nothing like reality biting back in the face. ;-)
So let's think this through. Francois suggested proxies
don't fork and return 3xx, possibly with multiple contacts
and let the UAC decide if it wants to fork.
This is certainly possible, although having implemented forking
and response aggregation in a SIP stack, I know that this is a
non-trivial amount of complexity that now every UA would have
to implement if it wants to support sipsec.
Now, one thing that we have discovered that is sub-optimal about
proxies that recurse instead of sending a 3xx to the UA is the
potential for upgrading a sip URI to sips and downgrading in
reverse. With sipsec, such upgrading or downgrading at proxies
does not matter. Eventually, over any transport (sip or sips)
chosen by the proxy, certs would be exchanged end-to-end. For
this reason, it would be good if we don't force the endpoint
to support forking.
And finally, forking a non-INVITE request at a proxy should
still result in one 2xx, or a best non-2xx being returned to
the UAC. So user agents can inherit much of the current
transaction-related behavior for CONNECT and augment it with
the certificate and tunnel behavior.
There's no real reason you couldn't for a CONNECT. The UA is still
going to have to decide which endpoint it upgrades to TLS. Although
in the absence of a PKI, the connected-surprise problem could become
an issue. This is a somewhat more tractable problem if 302 is issued,
as the UA would only exercise contacts in the 302 which it expects to
be able to validate.
--
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
