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. Thoughts? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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
