Happy to help! The advice comes from a fair bit of experience deploying
Kamailio into somewhat complex AWS topologies. Wouldn't want to see you
unnecessarily play life on hard mode.
On June 25, 2016 7:07:49 PM EDT, Colin Morelli wrote:
>Alright, I'll give both approaches a shot and see what co
Alright, I'll give both approaches a shot and see what comes up.
Thanks for the fast response time, Alex!
Best,
Colin
On Sat, Jun 25, 2016 at 7:07 PM Alex Balashov
wrote:
> It can work, but it's more trouble than the other approach, which is
> essentially automagic.
>
> -- Alex
>
> --
> Princi
It can work, but it's more trouble than the other approach, which is
essentially automagic.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users m
Awesome, thank you.
If I were to try to avoid opening another point, would it be sensible to
call record_route_advertised_address() with the advertised address twice
manually (once for the inbound and outbound legs with the appropriate IPs
for each)? Internally I assume Kamailio's loose_route() wo
Yep, you'll probably have to educate it as to which outbound interface to
choose, since they're on the same subnet (otherwise mhomed=1 would do the
trick).
That's what the (writable) $fs pseudovar is for.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google N
Thanks for the quick reply!
Binding to two SIP ports isn't out of the question (though I'd like to
avoid it if possible).
However, with this approach, I assume somewhere I must have to instruct
Kamailio which outbound interface to use (i.e. tell it to use 5080 for
forwarded requests to internal h
Understood. I went through this a while back.
As long as you're willing to bind to two different SIP ports (i.e. different
SIP port on your internal signalling), this is the solution:
listen=udp:private.ip:5060 advertise public.ip:5060
listen=udp:private.ip:5080
Combine with enable_double_rr,
Hey Alex,
Thanks for the response. This is the AWS scenario where there's a 1:1 NAT
from the public to private IP.
I've got as far as figuring out how to advertise the public IP. But, when I
forward the request to another node inside the cluster, I assume I want to
double-RR that request so that
Is this the AWS NAT scenario where the public IP is actually not homed on the
host itself, or are you asking about a genuine two-interface scenario?
Either way, look up the "advertise" option to the "listen" core configuration
directive.
-- Alex
--
Principal, Evariste Systems LLC (www.evaris
