On Oct 16, 2008, at 8:30 AM, Paul Kyzivat wrote:
Making this behavior "possible but not default" means that there must be two options: "do it", and "don't do it". The choice of which to do would need to be encoded somewhere. This matters a lot to the UA, so I think this option would have to be encoded as part of the registration request. Thus outbound would have to change to accommodate it.
If you want outbound's redundant-flow functionality, which is dependent on requests NOT forking to each flow to a UA, use outbound as specified.
If instead you want your two contacts treated as two different instances so that requests will fork to them, use two different instance-id values. Essentially, you're using single-contact/single flow Outbound (i.e., keepalive and reverse-routing of requests without redundant-flow) simultaneously on two different contacts (which may well be two different interfaces).
If you want both outbound's features simultaneously on multiple instances (or use virtual interfaces by having multiple instances on the same interface), then apply outbound as specified on each instance, where there are at least two proxies configured for each instance.
About the only thing I can see needing to document somewhere is the concept of using multiple instance-ids to make virtual interfaces, and that's pretty simple.
-- 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
