[Users] SER as loadbalancer and NAT

[Daniel-Constantin Mierla]

On 01/12/06 20:20, Andreas Granig wrote:
> Daniel-Constantin Mierla wrote:
>> Maybe is better to have: Path: 
>> <sip:own-address;lr;received=received-address> for the server in 
>> front of nat (load balancer). When loose_route() process the header 
>> it can take the received parameter and use it as dst_uri if no other 
>> Route header is present.
>
> Makes sense and seems to be a cleaner solution, yes.
>
>> Otherwise I see troubles to process a Route header which does not 
>> have server's address -- think about peering with other SIP networks 
>> where you cannot control what the server will add as parameters to 
>> Record-Route.
>
> I don't really get your point. In my understanding, this particular 
> Route header, inserted at the proxy, never leaves the own network 
> because it will be removed at the next hop (the load balancer in this 
> case).
I am thinking to a scenario where you peer your network to another ones. 
So you have a connection like:

[Your proxy] <---> [Load balancer] <---> [Foreign proxy]

When the calls come from the foreign proxy, the RR added by Foreign 
proxy is not controllable, so in the case of BYE you may get in 
difficulties to make the decision to remove or not the Route header. You 
may get a solutions based on IP of the Foreign proxies, but it may get 
ugly at a moment.
>
> But I like the idea using the received-param much better anyhow...
>
> So I'd like to port my Path-patch posted on the ser list in October 
> (http://mail.iptel.org/pipermail/serdev/2005-October/005847.html) to 
> openser. There are just one problem: as far as I've read, you're 
> working on a cacheless solution for usrloc, so there might be quite 
> some code conflicts if I start off now. So when do you think will your 
> changes be in CVS?
If you can do the patch in about one week, then it is fine. We are not 
planning any changes next week to registrar/usrloc, so we can work 
afterwards on the version which includes your patch.

Cheers,
Daniel

>
> Andy
>