Hi,
I'm trying to use Kamailio as an outbound proxy behind a NAT (all clients and kamailio itself are behind the same NAT):
UACs -> Kamailio -> NAT router -> PBX (hosted, public server)
I figured I could detect the external source port used by the router by periodically sending an OPTIONS request to the public server, then capture the rport value in the reply, and use that port as an input to set_advertised_port. Because I'm doing this periodically, it should have the added value of keeping the NAT mapping alive. Otherwise, I should be able to detect it, as the rport value will change.
I managed to periodically send the OPTIONS request, read the rport value on the reply message and store it on a pseudovariable using:
$var(rport) = $sel(v.rport);
But when I try to use that value to set the advertised port, I get an error, as if set_advertised_port only accepted literal values:
if( $var(rport) != 0) { set_advertised_port($var(rport)); }
Not starting Kamailio: invalid configuration file! -e 0(4692) : <core> [cfg.y:3591]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 504, column 24-34: syntax error 0(4692) : <core> [cfg.y:3594]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 504, column 35: bad argument, string expected ERROR: bad config file (2 errors)
So, am I missing something or does set_advertised_port actually only accept literal values?
Thanks Neven Boric
On 08/07/2012 04:34 PM, Neven Boric wrote:
So, am I missing something or does set_advertised_port actually only accept literal values?
Correct, set_advertised_port does not accept PVs. There is an entire category of legacy core functions, and some module functions, for which that is true.
There's an ongoing effort to update many of them to use PVs, but it's ... incremental. :-)
Methodologically speaking, you really, really don't want to run Kamailio behind a NAT as a client, unless the endpoint on the other side of the NAT can deal with it entirely using far-end NAT traversal strategies.
-- Alex
Alex Balashov escribió:
On 08/07/2012 04:34 PM, Neven Boric wrote:
So, am I missing something or does set_advertised_port actually only accept literal values?
Correct, set_advertised_port does not accept PVs. There is an entire category of legacy core functions, and some module functions, for which that is true.
There's an ongoing effort to update many of them to use PVs, but it's ... incremental. :-)
I wonder how hard would it be to do it myself. Just getting to know Kamailio as a user, haven't looked at the code yet. Any pointers? Hopefully some other function where this was recently implemented, so I can browse the commits.
Methodologically speaking, you really, really don't want to run Kamailio behind a NAT as a client, unless the endpoint on the other side of the NAT can deal with it entirely using far-end NAT traversal strategies.
There's this trend here (and I assume elsewhere) of providers offering hosted (i.e remote) PBX and installing an "SBC" on customer premises to access said PBX. I use quotes for SBC, because, from what I've gathered, it can mean different things to different people. In this case, it's a device that can be used to access the remote PBX without worring about NAT issues, handles security, does SIP normalization, topology hiding, maybe encryption, etc. One important feature is survivability, as in UACs being able to talk to each other (and maybe do conferences and other media stuff, so you also need a media server) in case the remote PBX is temporarily inaccessible. I just assumed they are installed behind the NAT, because all manufacturers (AudioCodes, Mediatrix and the like) mention NAT traversal as an important feature. Also, most of the times the clients are SMBs without access (or lacking the knowledge, or just hesitant because of security reasons) to configure port forwarding on their router.
Are you familiar with this scenario? Would you say I'm wrong in thinking these devices are installed behind the NAT? Or that Kamailio is not a good choice for this scenario?
Thanks -- Neven Boric