On 01/12/06 19:27, Andreas Granig wrote:
Andreas Granig wrote:
But I see this approach isn't RFC compliant, so maybe it's better to forget this hack and go for a clean Path-Header solution...
Just an idea regarding load balancing and NAT using the Path header:
When having a scenario like this:
[uac] -> [nat] -> [sip loadbalancer] -> [sip proxy]
Then I could construct a Path header like the following at the load balancer for REGISTERs:
Path: <sip:<own-address;lr>, <sip:<received-address>;lr>;nat=yes
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.
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.
Cheers, Daniel
Which is saved at the sip proxy when acting as registrar and will be converted into a Route header for subsequent requests towards the uac.
This would allow loose-routing on the load balancer to traverse the client's nat: In addition to removing the first uri (the own) from the Route header, loose_route() would check for the "nat=yes" flag in the next uri and would remove that uri from the Route header too after setting it as dst-uri.
Would this make sense, or are there more-elegant/simpler/better ways for achieving such a loadbalancing scenario (keeping in mind that there might be more than one load balancer and that it has to work with NAT)?
Andy
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users