Re: Dual registration without Outbound

Juha,

I think outbound will help us to implement redundant proxy/registrar
without the need for load balancers/clusters/etc.

But it's not currently in the spec. I view it as something of high
priority that we should be looking at. But we'll never get there if we 
don't get outbound out the door first.
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Juha Heinanen
> Sent: Monday, October 06, 2008 10:49
> To: Dean Willis
> Cc: [email protected]; Christer Holmberg
> Subject: Re: [Sip] Dual registration without Outbound
> 
> Dean Willis writes:
> 
>  > Why do I get the feeling that you won't be happy even when 
> every UA is  > forced to register every contact it has or 
> might obtain have with  > every registrar that ever existed 
> or will exist ;-)?
> 
> dean,
> 
> that is not true.  i sincerely hoped that outbound would help 
> me to implement redundant proxy/registrar without a need to 
> for load balancers, database clusters, or forwarding of 
> requests between proxies simply by being able to assume that 
> if i have two ob proxies, each ua would register all contacts 
> that it has via both of them.  
> 
> this is a VERY simple, easy to understand and implement 
> requirement compared to anything else this working group has 
> ever produced.
> 
> -- juha
> 
> 
> 
>  >
>  > On Oct 6, 2008, at 11:43 AM, Juha Heinanen wrote:
>  >
>  > > Dean Willis writes:
>  > >
>  > >> Assume a UA has two different interfaces, and it 
> registers each of  > >> its  > >> interfaces with a different 
> proxy/registrar. Further assume that  > >> those  > >> two 
> proxy registrars collude with respect to mapping the user's 
> AUR  > >> onto those contacts.
>  > >
>  > > that "collude" thing is exactly what i tried to avoid.  
> if ua is  > > required to register all of its contacts via 
> both proxies, then  > > redundancy of the service can be 
> implemented by running the  > > two proxy/registrars 
> completely independent of each other thus greatly  > > 
> simplifying the implementation.
>  > >
>  > > if that requirement is not there, ob becomes totally 
> useless again and  > > there was no advantage that the text 
> was changed according to my  > > wishes.  you may as well go 
> and change it back to what it was before.
>  >
> _______________________________________________
> 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