Subject: RE: [Sip] Outbound: Multiple flows and forking

From: <[email-masked]>
Date: Fri, 7 Apr 2006 10:11:26 +0300

Hi,

>what is the reason for designating the proxies as primary or secondary?

I do not know exactly. However it is a convention the current
spec seems to consistently use starting from section

 3.3  Multiple Connections from a User Agent

To me these two flows look equivalent from the proxy / registrar
perspective. I could not find any normative text to state that
when forwarding inbound requests, the primary flow should be
preferred over the backup flow.

Maybe those consepts were just introduced to make the idea
of multiple flows more understandable. However it could cause
some confusion that there is some kind of preference between 
those. I hope the authors could explain this if needed.

Regards,

Erkki

>-----Original Message-----
>From: ext Juha Heinanen [mailto:[email-masked]] 
>Sent: 07.April.2006 09:58
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]
>Subject: RE: [Sip] Outbound: Multiple flows and forking
>
>[email-masked] writes:
>
> >    The UA MUST send a REGISTER via one or 
> >    multiple proxies belonging to the outbound-proxy-set.
> >    For reliability reasons the UA SHOULD send a REGISTER
> >    for at least via one primary and one backup proxy.
>
>what is the reason for designating the proxies as primary or secondary?
>
>-- juha
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Apr 2006 10:15:37 +0300

> preferred over the backup flow.

to me, load balancing sounds a better idea that using primarily the
primary proxy.

-- juha

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 7 Apr 2006 09:32:42 +0200

> >what is the reason for designating the proxies as primary or

Thanks for bringing this up. I've been thinking about doing so myself.

I'm not too fond of dividing my servers into primary and secondary 
servers either. Secondary servers seem to be out of order when they are 
needed (when the primary goes down) far too often. Bad (or 
underdimensioned) hardware is used, configuration is out of sync etc.

This could of course all be blamed on the server operator not doing it's 
job, but I don't like standards introducing primary vs. secondary 
servers anyways. See more below though.

>  3.3  Multiple Connections from a User Agent

Quote from that section :

 " Designs having only one set were also considered, but in this case   
   there would have to be some way to ensure that the two
   connection did not accidentally resolve to the same host."

I guess the reason for the primary/secondary separation is that the 
author(s) forsee that multi-homed proxys will be more common than the 
current norm in the future. Probably as an effect of IPv6 was my 
thought.

If a proxy is multi-homed, presumably to obtain better network 
connectivity, what is the bad thing about getting two flows from a user 
agent to that same physical proxy? The explanation to that that I have 
come to think of is that if primary/secondary separation is removed, 
and a provider has two hosts with two IP addresses each, the UA would 
resolve the single proxy set to

   ProxyA-IP1, ProxyA-IP2, ProxyB-IP1, ProxyB-IP2

If the UA then decides that two flows is adequate, it would be a pity if 
it picked ProxyA-IP1 and ProxyA-IP2.

> preferred over the backup flow.

In case of two (or more) edge-proxys, the stored Path for the most 
recently registered binding would indicate to the Registrar which 
edge-proxy to use as "primary".

For the proxys, I agree the flows are equal. This, together with clever 
provisioning systems that let different UAs use ProxyA as primary and 
ProxyB as secondary, and vice versa, makes the primary/secondary be 
"just" a DNS issue, like the draft suggests, I guess.

/Fredrik