Hello,
I have a need to deploy Kamailio in AWS in a scenario of this sort:
[Public Internet] <---> Kamailio <---> (Internal AWS servers)
In such a scenario, Kamailio would be multihomed.
Furthermore, in addition to sending out of two distinct network interfaces, the networking idiosyncrasies of AWS needs to be taken into account. AWS hosts only have an RFC1918 address homed natively, front-ended by 1:1 NAT externally. Normally, this is taken care of by advertised_address, which allows Kamailio to make outward representations about the network address by which it can be reached that are different to the IP to which it is bound.
The problem here is that I need to do this conditionally, only on traffic going out the public interface. It should not be done on messages going to the "internal AWS servers".
So, the questions that arise are:
1. Is this sane? Any unforeseen effects, e.g. vis-a-vis RR, provided enable_double_rr is enabled and that two genuinely different network interfaces are used?
2. Do set_advertised_address()/set_advertised_port() accept PV arguments, or are they pre-PV "core function folk traditions" in the same way as rewritehostport() and force_send_socket()?
Thanks!
-- Alex
Hello,
On 23/03/16 18:51, Alex Balashov wrote:
Hello,
I have a need to deploy Kamailio in AWS in a scenario of this sort:
[Public Internet] <---> Kamailio <---> (Internal AWS servers)
In such a scenario, Kamailio would be multihomed.
Furthermore, in addition to sending out of two distinct network interfaces, the networking idiosyncrasies of AWS needs to be taken into account. AWS hosts only have an RFC1918 address homed natively, front-ended by 1:1 NAT externally. Normally, this is taken care of by advertised_address, which allows Kamailio to make outward representations about the network address by which it can be reached that are different to the IP to which it is bound.
The problem here is that I need to do this conditionally, only on traffic going out the public interface. It should not be done on messages going to the "internal AWS servers".
So, the questions that arise are:
- Is this sane? Any unforeseen effects, e.g. vis-a-vis RR, provided
enable_double_rr is enabled and that two genuinely different network interfaces are used?
- Do set_advertised_address()/set_advertised_port() accept PV
arguments, or are they pre-PV "core function folk traditions" in the same way as rewritehostport() and force_send_socket()?
I expect those functions not to support pvs, but I think this is something to address in 5.0 and get all core functions working with pvs.
As you have two cases here, using some IFs to decide what advertised address to be used should not make the config much more complex.
On the other hand, what I prefer in this case is to use different ports for communication with external and internal worlds. Then you can specify the listen on external port with advertise address and the one for internal without. Nothing else should be done in config regarding the advertise address, just select the proper socket for sending the traffic.
Cheers, Daniel
On 03/23/2016 02:32 PM, Daniel-Constantin Mierla wrote:
On the other hand, what I prefer in this case is to use different ports for communication with external and internal worlds. Then you can specify the listen on external port with advertise address and the one for internal without. Nothing else should be done in config regarding the advertise address, just select the proper socket for sending the traffic.
Interesting suggestion, thanks!
How does one apply advertised_address= to a particular listening socket? I thought it was a global directive that applies to all outgoing traffic on all sockets?
On 23/03/16 19:33, Alex Balashov wrote:
On 03/23/2016 02:32 PM, Daniel-Constantin Mierla wrote:
On the other hand, what I prefer in this case is to use different ports for communication with external and internal worlds. Then you can specify the listen on external port with advertise address and the one for internal without. Nothing else should be done in config regarding the advertise address, just select the proper socket for sending the traffic.
Interesting suggestion, thanks!
How does one apply advertised_address= to a particular listening socket? I thought it was a global directive that applies to all outgoing traffic on all sockets?
I meant advertise attribute for listen parameter:
listen=udp:x.y.z.w:5060 advertise a.b.c.d:5060 listen=udp:x.y.z.w:5080
Daniel
On 03/23/2016 02:35 PM, Daniel-Constantin Mierla wrote:
I meant advertise attribute for listen parameter:
listen=udp:x.y.z.w:5060 advertise a.b.c.d:5060 listen=udp:x.y.z.w:5080
Huh! I guess when I go to bed, I should make a habit of curling up with the latest edition of the core cookbook.
Thanks, Daniel. That really helps make life easier!
Daniel,
Utilising the suggestion you advanced, will record_route() automatically take care of populating the advertised address if it is set as an 'advertise' directive on the socket?
On 23/03/16 19:42, Alex Balashov wrote:
Daniel,
Utilising the suggestion you advanced, will record_route() automatically take care of populating the advertised address if it is set as an 'advertise' directive on the socket?
Yep, record-route and via as well as matching myself condition are done automatically -- nothing else to do in config apart of setting send-socket.
Daniel
On 03/23/2016 02:45 PM, Daniel-Constantin Mierla wrote:
Yep, record-route and via as well as matching myself condition are done automatically -- nothing else to do in config apart of setting send-socket.
That's brilliant. Thank you!
On 23/03/16 19:46, Alex Balashov wrote:
On 03/23/2016 02:45 PM, Daniel-Constantin Mierla wrote:
Yep, record-route and via as well as matching myself condition are done automatically -- nothing else to do in config apart of setting send-socket.
That's brilliant. Thank you!
Welcome to virtualized/cloud telco infrastructure :-) !
On 03/23/2016 01:51 PM, Alex Balashov wrote:
Hello,
I have a need to deploy Kamailio in AWS in a scenario of this sort:
[Public Internet] <---> Kamailio <---> (Internal AWS servers)
In such a scenario, Kamailio would be multihomed.
- Is this sane? Any unforeseen effects, e.g. vis-a-vis RR, provided
enable_double_rr is enabled and that two genuinely different network interfaces are used?
I'm not sure if it's sane, but I do this as well.
- Do set_advertised_address()/set_advertised_port() accept PV
arguments, or are they pre-PV "core function folk traditions" in the same way as rewritehostport() and force_send_socket()?
I have a main listen=udp:192.168.25.31 advertise PUBLIC:5060
and then when needed...
set_advertised_address("192.168.25.31");
as in...
if ($rd=~"192.168.25") { set_advertised_address("192.168.25.31"); }
--fred
On 03/23/2016 03:15 PM, Fred Posner wrote:
I have a main listen=udp:192.168.25.31 advertise PUBLIC:5060
and then when needed...
set_advertised_address("192.168.25.31");
as in...
if ($rd=~"192.168.25") { set_advertised_address("192.168.25.31"); }
Cool. It sounds like Daniel's suggestion might make this even easier:
listen=udp:192.168.25.31:5060 advertise PUBLIC:5060 listen=udp:192.168.25.31:5080 # private
Then you can get rid of the logic and just modulate this with
$fs = "udp:192.168.25.31:5060"; $fs = "udp:192.168.25.31:5080";
-- Alex
-
Alex Balashov -
Daniel-Constantin Mierla -
Fred Posner