1 May
2007
1 May
'07
7:21 p.m.
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.
--
Greetings,
Alex Hermann
Speakup
2 May
2 May
9:33 a.m.
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.
11:06 a.m.
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?
--
Greetings,
Alex Hermann
4:12 p.m.
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
4:28 p.m.
On Wednesday 02 May 2007 15:12, Juha Heinanen wrote:
Alex Hermann writes:
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.
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.
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.
--
Greetings,
Alex Hermann
6417
days inactive
6418
days old
5 comments
3 participants
participants (3)
-
Alex Hermann -
jh＠tutpro.com -
Klaus Darilion