Hello list members,
I'd like to use multiple proxies/registrars in a SRV managed failover/load-balancing situation. For NAT purposes I could use a couple of dedicated load-balancers with path support to store the NAT enabled route in the location table. The registrars have a shared location table on a database server. This situation works, but....
Is there a possibility to skip the load-balancers?
I want the proxy/registrar to store the NAT-route somehow in the location table, so that when the contact needs to be contacted, the proxy can determine if it can send the request itself, or it needs to forward it via one of the other proxies (the one with which the contact has the NAT relation).
I hope you understand the topology, otherwise I might need to create some ascii-art.
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
Another solution requires a new feature, which should be easily implemented: Openser already stores the socket on which the request was received. Then, during lookup, this socket will be forced with an implicit force_send_socket().
If either - the forced send socket is accessIble via a pseudo variable - during lookup() the socket info is exported as AVP
the request can be forwarded to the proxy which has the NAT binding.
regards klaus
Alex Hermann wrote:
Hello list members,
I'd like to use multiple proxies/registrars in a SRV managed failover/load-balancing situation. For NAT purposes I could use a couple of dedicated load-balancers with path support to store the NAT enabled route in the location table. The registrars have a shared location table on a database server. This situation works, but....
Is there a possibility to skip the load-balancers?
I want the proxy/registrar to store the NAT-route somehow in the location table, so that when the contact needs to be contacted, the proxy can determine if it can send the request itself, or it needs to forward it via one of the other proxies (the one with which the contact has the NAT relation).
I hope you understand the topology, otherwise I might need to create some ascii-art.
On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
I thought of that, but then every REGISTER needs to be forwarded to another proxy to get the path info right. This result in a great amount of traffic between the proxies and extra processing power. I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
Another solution requires a new feature, which should be easily implemented: Openser already stores the socket on which the request was received. Then, during lookup, this socket will be forced with an implicit force_send_socket().
I already found the received socket in the location table, but couldn't find any function which actually used it. The path field is used, but that can't be filled without an extra hop adding the path info (or is there?). So maybe I can use a database trigger to put the received socket info into the path field (but then the path should be ignored when it is the localhost).
If either
- the forced send socket is accessIble via a pseudo variable
- during lookup() the socket info is exported as AVP
the request can be forwarded to the proxy which has the NAT binding.
So this is impossible with the current OpenSER? So everyone with multiple registrars/proxies and NAT must use loadbalancers in front of them?
Alex Hermann writes:
I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
say you have two proxies, then probability that invite arrives at "wrong" proxy is 50%, i.e., half of invites will use resources from both proxies. further, if the "right" proxy happens to be down, you loose completely, i.e., there is no redundancy. doesn't sound very attractive to me.
-- juha
On Wednesday 02 May 2007 15:12, Juha Heinanen wrote:
Alex Hermann writes:
I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
say you have two proxies, then probability that invite arrives at "wrong" proxy is 50%, i.e., half of invites will use resources from both proxies.
I know. But registers will be more frequent in this situation, I don't want them to hop around. And 50% is still a saving.
further, if the "right" proxy happens to be down, you loose completely, i.e., there is no redundancy.
Until a reregister occurs... There's no way around that because of the NAT relation, except hijacking the IP with HA or something similar (and making OpenSER aware of the added IP). The UA's don't support simultaneous registering with multiple proxies.
doesn't sound very attractive to me.
Feel free to suggest a NAT aware solution :)
I think Klaus' suggestion to take the stored socket in the location table into account when sending out the request to the contact is a nice first step to prevent unnecessary hops, while still handling NAT. The unreachable proxy situation is unrelated and happens either way.
-
Alex Hermann -
jh＠tutpro.com -
Klaus Darilion