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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users