On May 10, 2008, at 12:40 AM, Juha Heinanen wrote: > Dean Willis writes: > >> Then you're reading a different outbound draft than I am, because as >> far as I know, enabling the UA to bind multiple proxies is what the >> outbound draft does. Without it, you have no real way to do this. > > ob draft does not "anable UA to bind to multiple proxies". rfc3261 > already allows and enables UA to bind to multiple proxies.
Not and detect when they've dropped and need to be re-connected, and not in a way that allows the proxies to reach the UAs back across a NAT reliably, > > >> Since the mechanism works with a single binding, there's no rationale >> under RFC 2119 for making usage of multiple bindings a MUST. If we >> did that , then we'd have to make it a MUST for proxies to always be >> deployed in pairs, and that clearly isn't going to happen in every >> deployment scenario. I can only afford one proxy! > > then the ob set that you tell to your UAs would consist of only one > proxy, which would be perfectly fine. Earlier, you were apparently arguing that having only one proxy configured should be a violation of the spec, and that Outbound is useless because it does not require a UA to register with multiple proxies. Now you're saying that this would be perfectly fine. Are you saying that the configuration mechanism should have an indicator to tell a configured UA which or how many proxies it should bind to, out of a larger set of available proxies that it can choose from? For example, we might have a configuration that says "Here are the six proxies available for you to use. We expect you to register with at least two of them, and if you lose any bindings, please make a new one. Registering with only one is a violation of your terms of service and will force us to neuter your cat." Or perhaps another config that says "Here are four proxies. You must register with all of them." -- Dean _______________________________________________ Sip mailing list https://www.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
