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
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