Hi all,

I have a scenario where it’s not clear to me what the best approach should be (Kamailio 3.2.0 on Squeeze, although I think it’s a matter of routing logic only).

 

I have a client behind NAT that sends an initial REGISTER request with a Contact containing private ip:port (e.g.

Contact: “GV” <sip:12345@192.168.1.2:54321;transport=tcp>

)

However, after it’s challenged for authentication with a 401, it sends the following REGISTER request with Authorization header and with a Contact containing ip:port equal to the ‘received’ SIP URI (with a combination of ‘rport’ and ‘received’ parameters (e.g.

Contact: “GV” <sip:12345@[receivedIP]:[rport];transport=tcp>

)

In this case kamailio’s routing logic is not marking the REGISTER as natted (no Received field in location and no NAT flags set).

 

You can imagine I have a fairly standard NAT handling:

 

route[NATDETECT] {

        force_rport();

        if (nat_uac_test("19")) {

                if (is_method("REGISTER")) {

                        fix_nated_register();

                } else {

                        fix_nated_contact();

                }

                setflag(FLT_NATS);

        }

        return;

}

 

FLT_NATS won’t be set, and so it won’t FLB_NATB in the following processing.

 

This client receives a call: Kamailio relays the INVITE to it using the stored Contact. The INVITE is correctly received by the client, because the stored Contact refers to the connected socket ([received]:rport).

The trouble starts when then the client replies with a 200 OK containing the private ip:port in the Contact header field (again 192.168.1.2:54321).

The ACK will then have that private ip:port in the R-URI, and its relaying will fail.

 

One of the solutions I’ve found is using always add_contact_alias() in onreply_route when handling the 200 OK, and then use handle_ruri_alias() when defining the destination for the ACK.

 

I know that without traces and the full .cfg this is quite a broad question, but I wonder if you have already had to deal with this kind of client behaviour and can provide advice on the best practices.

This is in particular useful for the re-use of TCP-based connections.

 

Thanks in advance,

Giacomo