Hi guys,

as I see in the tcpdump:

- with the received header the R-RURI in the INVITE looks like:

Request-Line: INVITE sip:dev-lab1@192.168.44.101:40885;line=fjafxbr9 SIP/2.0


- without the received header the R-URI in the INVITE looks like:

Request-Line: INVITE sip:dev-lab1@212.46.162.97:40885;line=7wsv12yg SIP/2.0


Could the INVITE been rejeced/dropped by the UAC, if the R-RURI contains the 
public instead the private IP or another port etc.?

From UAC perspective, the R-RURI (puclic IP) by incoming packets doesn't match 
the R-RURI (private IP) by outgoing packets.


Kind regards,

Julian Santer

Am 20.11.18 um 15:51 schrieb Julian Santer:
Hi guys,

if I don't use the received column on the edge server, but I call 
fix_nated_contact instead, it seems to work.

if (nat_uac_test("127"))
{
    fix_nated_contact();
}

consume_credentials();

if (! add_path())
{
    send_reply("500", "Internal path error, registration not stored");
    xlog("L_ERR", "Adding PATH (with received) failed - LF_BASE");
    exit;
}

Is this the right way or could I break something else with this change?


Kind regards,

Julian Santer

Am 19.11.18 um 18:41 schrieb Julian Santer:
Hi guys,

we need to switch from nat_traversal to nathelper.
The reason is the keepalive mechanism.

The nat_traversal module sends OPTIONS with the following to header: 
sip:UAC_IP:UAC_PORT
Most of the UAC's answers with a 404 Not found.
On AVM Fritzbox with firmware >= 6.04, this OPTIONS may activate a security 
feature.
So after a certain time, the Fritzbox blocks all packages send from our proxy.
As we have ca. 80% AVM Fritzbox as UAC, we got a big problem.
So we deactivated the nat_keepalive vor this UAC's and we have to enable the 
keepalive Feature on the Fritzbox.

The better solution would be, if we could send OPTIONS with a to header like: 
sip:username@UAC_IP:UAC_PORT.
As I understood the nathelper module could send OPTIONS like this. Because it 
is looking into the userloc table. Right?

The nathelper module is on our edge server, the registrar on our core server.
For the "normal" UAC's (no received entry in usrloc) the keepalive's are now 
sent as expected.
But for the "nated" UAC's (received entry in usrloc) the keepalive's are like 
before: sip:UAC_IP:UAC_PORT (values in the received column from usrloc).
The REGISTER send to the core got the path header looking like:
Path: <sip:IP_EDGE;lr;received=sip:IP_UAC:40885>

Is there a possibility to add the $fU on the received part of the path header (the user in the path module adds a string to the path part, but not to the received part)?
Or is there a possiblity on the registrar to store the $fU in the received 
column?
On the nathelper keepalive mechanism I don't see any possibility to add the $fU.

We are using the version 2.2.6 from the official debian source list.

The config on the edge server's looks like:
#### nat helper module
loadmodule "nathelper.so"
modparam("nathelper", "natping_interval", 0)
modparam("nathelper", "ping_nated_only", 0)
modparam("nathelper", "natping_partitions", 1)
modparam("nathelper", "natping_tcp", 0)

### REGISTER

$var(nat) = null;

if (nat_uac_test("127"))
{
    $var(nat) = TRUE;
}
else
{
    $var(nat) = FALSE;
}

consume_credentials();

if ($var(nat) == TRUE)
{
    if (! add_path_received())
    {
        xlog("L_ERR", "Adding PATH (with received) failed - LF_BASE");
        send_reply("500", "Internal path error, registration not stored");
        exit;
    }
}
else
{
    if (! add_path())
    {
        send_reply("500", "Internal path error, registration not stored");
        xlog("L_ERR", "Adding PATH (with received) failed - LF_BASE");
        exit;
    }
}

route("R_RELAY_TO_REGISTRAR");
exit;

### OPTIONS

if (method=="OPTIONS")
{
    if ($si == "CORE")
    {
        topology_hiding("U");
        if (! t_relay("0x05"))
        {
            send_reply("500", "Internal server error - failed to relay");
            xlog("L_ERR", "Unable to relay OPTIONS - LF_BASE");
        }
    }
}


The config on the core server looks like:
loadmodule "usrloc.so"
modparam("usrloc", "user_column",           "username")
modparam("usrloc", "domain_column",         "domain")
modparam("usrloc", "contact_column",        "contact")
modparam("usrloc", "expires_column",        "expires")
modparam("usrloc", "q_column",              "q")
modparam("usrloc", "callid_column",         "callid")
modparam("usrloc", "cseq_column",           "cseq")
modparam("usrloc", "methods_column",        "methods")
modparam("usrloc", "flags_column",          "flags")
modparam("usrloc", "user_agent_column",     "user_agent")
modparam("usrloc", "received_column",       "received")
modparam("usrloc", "path_column",           "path")
modparam("usrloc", "socket_column",         "socket")
modparam("usrloc", "use_domain",            0)
modparam("usrloc", "desc_time_order",       0)
modparam("usrloc", "timer_interval",        60)
modparam("usrloc", "db_url",                "DBURL")
modparam("usrloc", "db_mode",               2)
modparam("usrloc", "matching_mode",         0)
modparam("usrloc", "cseq_delay",            20)
modparam("usrloc", "nat_bflag",             6)

#### nat helper module
loadmodule "nathelper.so"
modparam("nathelper", "natping_interval", 56)
modparam("nathelper", "ping_nated_only", 0)
modparam("nathelper", "natping_partitions", 1)
modparam("nathelper", "sipping_bflag", 8)
modparam("nathelper", "sipping_from", "sip:keepalive@DEFAULT_REALM")
modparam("nathelper", "sipping_method", "OPTIONS")

# We want to send a keepalive on each registered UAC
if (proto == UDP)
{
    setbflag(8);
    xlog("L_INFO", "Nat keepalive sip_ping_flag - LF_BASE");
}

if (! save("location", "vp1"))
{
    xlog("L_ERR", "Saving contact from EDGE failed - LF_BASE");
    exit;
}

Thank you for any hint.

Kind regards,
Julian Santer
Raiffeisen OnLine

ps: @Bogdan: this is why we have ca. 550 entry's in the address table (permission module). If we solve the keepalives, only ca. 50 entry's are remaining.

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to