[SR-Users] question about reply route

Karsten Horsmann khorsmann at gmail.com
Sat Jun 29 16:11:31 CEST 2019


Hi,

Or you could configure
one listen <natip> advertise pubip
And a second listen internal ip (could be from the same private subnet) and
you point your Asterisk to the private ip.


Cheers
Karsten


Joel Serrano <joel at textplus.com> schrieb am Sa., 29. Juni 2019, 06:51:

> Using the “advertise” option in the listen= param will cause the route/via
> headers to use whatever you configure there regardless of what the actual
> interface IP is.
>
> One option is for you enable a second port for communication with
> asterisk, and leave 5060 with the advertise for your trunk...
>
>
> On Fri, Jun 28, 2019 at 19:28 Iván Aponte <ivan.aponte at gmail.com> wrote:
>
>> Hello,
>>
>> I have a question about record route and via headers. My scenario is
>> the following:
>>
>> [asterisk] ---- [kam] -------- [trunk]
>> 10.142.0.27     10.142.0.6    200.x.x.x
>>
>> I have an asterisk an a kamailio in a private ip network
>> (10.142.0.0/24). Kamailio has the address 10.142.0.6 but is also
>> natted 1:1 to a public ip (35.0.0.6).
>>
>> My problem is that when the invite are replied the asterisk replies to
>>  the external  ip (35.0.0.6) instead of the internal ip (even though
>> the kamailio replies goes through the internal network) . I tried
>> adding  a reply route to change the advertised address to no avail.
>> any advice would be appreciated.
>>
>>
>> this is my conf:
>>
>> LISTEN="listen=udp:0.0.0.0:5060 advertise 35.0.0.6:5060"
>> disable_tcp=yes
>> loadmodule "jsonrpcs.so"
>> loadmodule "kex.so"
>> loadmodule "corex.so"
>> loadmodule "tm.so"
>> loadmodule "tmx.so"
>> loadmodule "sl.so"
>> loadmodule "rr.so"
>> loadmodule "pv.so"
>> loadmodule "maxfwd.so"
>> loadmodule "usrloc.so"
>> loadmodule "textops.so"
>> loadmodule "siputils.so"
>> loadmodule "xlog.so"
>> loadmodule "sanity.so"
>> loadmodule "ctl.so"
>> loadmodule "cfg_rpc.so"
>> loadmodule "acc.so"
>> loadmodule "counters.so"
>> loadmodule "permissions.so"
>> loadmodule "ipops.so"
>>
>> modparam("jsonrpcs", "pretty_format", 1)
>> modparam("tm", "failure_reply_mode", 3)
>> modparam("tm", "fr_timer", 30000)
>> modparam("tm", "fr_inv_timer", 120000)
>>
>> modparam("rr", "enable_full_lr", 0)
>> modparam("rr", "append_fromtag", 0)
>>
>> reply_route {
>>    xinfo("source $si");
>>     if(!is_in_subnet($si, "10.0.0.0/8")) {
>>      set_advertised_address("10.142.0.6");
>>    }
>>    else {
>>      xinfo("not in subnet");
>>    }
>> }
>>
>>
>> request_route {
>>
>> # per request initial checks
>> route(REQINIT);
>> # CANCEL processing
>> if (is_method("CANCEL")) {
>> if (t_check_trans()) {
>> route(RELAY);
>> }
>> exit;
>> }
>>
>> # handle retransmissions
>> if (!is_method("ACK")) {
>> if(t_precheck_trans()) {
>> t_check_trans();
>> exit;
>> }
>> t_check_trans();
>> }
>>
>> # handle requests within SIP dialogs
>> route(WITHINDLG);
>>
>> ### only initial requests (no To tag)
>>
>> # authentication
>> #route(AUTH);
>>
>> # record routing for dialog forming requests (in case they are routed)
>> # - remove preloaded route headers
>> remove_hf("Route");
>> if (is_method("INVITE|SUBSCRIBE")) {
>> record_route();
>> }
>>
>>
>> # dispatch requests to foreign domains
>> route(SIPOUT);
>>
>> if ($rU==$null) {
>> # request with no Username in RURI
>> sl_send_reply("484","Address Incomplete");
>> exit;
>> }
>>
>> }
>>
>> # Wrapper for relaying requests
>> route[RELAY] {
>> if (!t_relay()) {
>> sl_reply_error();
>> }
>> exit;
>> }
>>
>> # Per SIP request initial checks
>> route[REQINIT] {
>> if($ua =~ "friendly-scanner|sipcli|VaxSIPUserAgent") {
>> # silent drop for scanners - uncomment next line if want to reply
>> # sl_send_reply("200", "OK");
>> exit;
>> }
>>
>> if (!mf_process_maxfwd_header("10")) {
>> sl_send_reply("483","Too Many Hops");
>> exit;
>> }
>>
>> if(is_method("OPTIONS") && uri==myself && $rU==$null) {
>> sl_send_reply("200","Keepalive");
>> exit;
>> }
>>
>> if(!sanity_check("1511", "7")) {
>> xlog("Malformed SIP message from $si:$sp\n");
>> exit;
>> }
>> }
>>
>> # Handle requests within SIP dialogs
>> route[WITHINDLG] {
>> if (!has_totag()) return;
>>
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> if (loose_route()) {
>> if ( is_method("NOTIFY") ) {
>> record_route();
>> }
>> route(RELAY);
>> exit;
>> }
>>
>> if (is_method("SUBSCRIBE") && uri == myself) {
>> send_reply("405", "Method Not Allowed");
>> exit;
>> }
>> if ( is_method("ACK") ) {
>> if ( t_check_trans() ) {
>> # no loose-route, but stateful ACK;
>> # must be an ACK after a 487
>> # or e.g. 404 from upstream server
>> route(RELAY);
>> exit;
>> } else {
>> # ACK without matching transaction ... ignore and discard
>> exit;
>> }
>> }
>> sl_send_reply("404","Not here");
>> exit;
>> }
>> route[SIPOUT] {
>> if (uri==myself) return;
>> append_hf("P-hint: outbound\r\n");
>> route(RELAY);
>> exit;
>> }
>>
>>
>>
>>
>> --
>> Iván Aponte
>> Office: +58(212)9923193
>> Mobile: +58(412)2774713
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190629/a3a967e1/attachment.html>


More information about the sr-users mailing list