[SR-Users] SIP communication does not reach phone when STUN is used

[Kevin Olbrich]

Hi!

I noticed a minor problem when I set up the STUN config of my phone.
When the server is set, I am unable to reach the endpoint from kamailio
(Phone1 -> Kamailio -> Asterisk -> same Kamilio -> no outgoing SIP flow to
Phone2).
If I do not set it, it seems to fallback to it's RFC1918 address which is
then detected by nat_uac_test() and I can reach the phone.

During my tests with Asterisk directly, this did not make any difference.
Seems like Asterisk checks more than FLAG 19/8 in nat_uac_test().
If I am right, I strictly used the SIP source port for answers instead of
any self-detection using STUN or similar.

My kamailio node is connected to the internet directly and 95 percent of
(planned) phones are behind random NATs.

In example kamailio.cfg there are these settings:

# Caller NAT detection
> route[NATDETECT] {
> #!ifdef WITH_NAT
> force_rport();
> if (nat_uac_test("19")) {
> if (is_method("REGISTER")) {
> fix_nated_register();
> } else {
> if(is_first_hop()) {
> set_contact_alias();
> }
> }
> setflag(FLT_NATS);
> }
> #!endif
> return;
> }


AND (modified for direct RTP flow):

 # RTPProxy control and signaling updates for NAT traversal
> route[NATMANAGE] {
> #!ifdef WITH_NAT
> if (is_request()) {
> if(has_totag()) {
> if(check_route_param("nat=yes")) {
> setbflag(FLB_NATB);
> }
> }
> }
> if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return;
> if(nat_uac_test("8")) {
> fix_nated_sdp("15");
> if (is_request()) {
> if (!has_totag()) {
> if(t_is_branch_route()) {
> add_rr_param(";nat=yes");
> }
> }
> }
> if (is_reply()) {
> if(isbflagset(FLB_NATB)) {
> if(is_first_hop())
> set_contact_alias();
> }
> }
> #!endif
> return;
> }


I checked the docs but I am not sure which FLAGs are safe to use (or break
things).

Any thoughts or hints are welcome.

Thank you very much!

Kind regards
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181005/5fb93e83/attachment.html>