2 May
2005
2 May
'05
2:30 p.m.
This is exactly the same problem discussed in another thread on load
balancing and scalability. Klaus Darilion described a scanario for load
balancing using ser. However, we run into the same NAT issues as you have
discussed in this thread:
http://lists.iptel.org/pipermail/serusers/2005-April/018240.html
One option is to make sure that NAT bindings are open. This will be a hack
no matter what you do as long as the client does not support using SRV with
equal weigths as *concurrent* servers, i.e. the client registers with
both/all servers. I believe this is not the intention of the spec.
The other option is to always use the SER server where the client registered
for INVITEs to that client. Klaus suggested Contact manipulation and
implementation of the Path header to accomplish this. The problem is
(surprise) that such implementation can also be characterized as hacks. In
the above thread, I suggested using the following algorithm to simulate Path
in a registration server (I don't know if it will work...):
<Quote>
record_route();
if(method=="REGISTER") {
if(src_ip==server1) {
save("location_server1"); # Does save reply to Contact or to
srcip:port?
} else if(src_ip==server2) {
save("location_server2");
}
break;
}
if(INVITE for one of our clients) {
if(lookup("location_server1")){
t_relay_to_udp("outbound proxy1");
} else
if(lookup("location_server")){
t_relay_to_udp("outbound proxy2");
} else {
sl_reply("404", "User not found");
break;
}
}
Thus, faking Path by using src_ip and storing the location in different
tables.
I'm not sure how save() is implemented (where it replies).
</Quote>
Of course, you will still have dependency on a single server for all users
registered on that server. Thus, you must use a Linux HA type setup (or what
I would prefer: Let each public IP delivered by _sip SRV by the virtual IP
of an LVS-based cluster as discussed in the above thread).
Comments?
g-)
Jan Janak wrote:
This is a hack, but:
You can redirect the REGISTER request to the 2nd server. SER-1
receives a REGISTER and processes it with save_noreply(). It then
redirects the REGISTER method to the 2nd server using
sl_send_reply("301", "Moved Permamently"); The 2nd server will
detect
that the REGISTER has been redirected and will generate 200 OK (a
parameter in the request-uri could be used for the detection).
If you set the expires to a short value (using max_expires parameter
of registrar module) than the user agent can keep NAT bindins open to
both servers.
Note:
1) The user agent has to support REGISTER/3xx (not all of them do)
2) I did not test this.
3) It really is a hack.
Jan.
On 02-05-2005 13:07, Andreas Granig wrote:
Juha Heinanen wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers the other option might be to make ser-1 to send
an options request
to uac-1 using ser-2's address in contact.
should have been "in via header".
How would you do this best?
Since the source address and the source port have to match SER-1's
address, IMHO you can't just use an external script to perform this
directly without SER-1, because you can't bind to SER-1's address.
If you inject the OPTIONS into SER-1 via FIFO or sipsak/sipp, the
request goes thru, but SER-1 adds it's address as topmost Via, so the
response always comes back to SER-1 first. Is it possible to suppress
the insertion of the own Via-Header?
Or even better: is there a way to send the OPTIONS from inside the
SER-Config without calling or using external scripts? Don't think so
(beside writing a module)...
Suggestions?
Andy
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers