Hi, Agreed.
I've been trying to follow this thread here and there and finally got some clarity by reading Dean's mail below. In general high availability and also parallel forking are nice, but I'm definitely against any normative statements on how many flows UA needs to use. For instace the case Juha is describing, i.e. parallel registrations over GPRS and WLAN with parallel forking would have a trade off that the device battery would run out much sooner with a single GPRS- *or* WLAN-bound registration. So, for that reason I don't think that would be the best default choice for an UA in a battery powered wireless device. What Dean is describing below seems good as it is up to the UA to decide what to do while everything seems possible and there shouldn't be serious IOP issues even if UAs preferred different strategies. And above all we don't need to agree beforehand on what would be the best way. Markus >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of ext Elwell, John >Sent: 17 October, 2008 10:44 >To: Paul Kyzivat; Dean Willis >Cc: Bob Penfield; [email protected]; Christer Holmberg >Subject: Re: [Sip] Dual registration without Outbound > >+1 > >John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] >> Sent: 17 October 2008 01:08 >> To: Dean Willis >> Cc: Christer Holmberg; Elwell, John; Bob Penfield; Juha Heinanen; >> [email protected] >> Subject: Re: [Sip] Dual registration without Outbound >> >> I agree. >> >> Paul >> >> Dean Willis wrote: >> > >> > 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 > _______________________________________________ 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
