Subject: RE: [Sip] Path to Working Group Item

From: "George Foti (LMC)" <[email-masked]>
Date: Sat, 2 Mar 2002 08:13:08 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, March 02, 2002 7:46 AM
> To: George Foti (LMC)
> Cc: Rosen, Brian; [email-masked]'
> Subject: RE: [Sip] Path to Working Group Item
> 
> 
> George Foti (LMC) writes:
> 
>  > You now what the requirements are. Suggest alternatives 
> that *address* those
>  > requirements without breaking SIP, which you haven't done. 
> But opted to cry
>  > wolf. Your only alternative has been to discount the requirements.
> 
> that is not true.  i have suggested that you use three things 
> instead of
> the path header:
> 
> - dhcp to locate the proxy of the visited network
Fine and thats what is being done in this case
> - dns with load balancing to figure out the proxy of the home network
> - loose source routing to get the requests to the home network
> 

You misuderstood the requirement here. The proxy assigned to a suscriber at
home is not static, not known apriori. It is rather dynamic and assigned
only at registration. So DNS is not an option. 

As far as using loose source routing, than some entity, that is today
statless, will have to become stateful to know where to loose route for each
subscriber.
In other words we bastardized the architecture.

Now you may argue about the architecture, and thats okay, but doing it from
the sidelines does not work.
You need to be fully engaged to understand the architecture in the first
place before you make claims that we rejected solutions purposly.

> and i haven't heard of any *convincing* arguments why that is not
> enough.  
> 
> the only requirement i remember discounting is pinning of a particular
> home proxy, which i consider a bad idea in general.  load balancing
> helps to reduce the load of the entry proxies which can then route the
> request further, if necessary, to a particular service proxy.
> 
> what comes to the requirements in general, i don't think that the sip
> working group should take the 3gpp requirements as given from top down
> by your gods, but should be allowed to consider first if they make
> any sense.
> 
> -- 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: [email-masked]
Date: Sat, 2 Mar 2002 15:21:12 +0200

> only at registration. So DNS is not an option. 

huh, then your requirements have even less to do with the sip protocol
than i thought.  the sip specs say that the proxy of a user can be found
from the dsn using the srv records.  now you say that that is not true.
it would be really high time that you stop wasting the bandwidth on the
SIP mailing list with these kinds of requirements.

 > place before you make claims that we rejected solutions purposly.

for me it is enough that i try to understand the SIP architecture.
yours is something very different and doesn't belong to this mailing
list.

-- juha