Re: [SR-Users] NATHELPER issue - sr-users

23 Jul 2018

Hi Konstantin,

INVITE:

INVITE sip:9613159370@X.X.X.X:5065 SIP/2.0

Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d>

X-AUTH-IP: Y.Y.Y.Y

Via: SIP/2.0/UDP X.X.X.X:5065;branch=z9hG4bK0f8e.68a6417bb4b72bec0eb7c44427dc8731.0

Via: SIP/2.0/UDP
192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556

Max-Forwards: 69

Contact: <sip:967123456@192.168.26.3:31556;alias=Y.Y.Y.Y~31556~1>

To: "9613159370"<sip:9613159370@X.X.X.X:5065>

From: "+967123456"<sip:967123456@X.X.X.X:5065>;tag=5269152d

Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM.

CSeq: 1 INVITE

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

Content-Type: application/sdp

User-Agent: eyeBeam release 1003s stamp 31159

Content-Length: 434

v=0

o=- 5 2 IN IP4 192.168.26.3

s=CounterPath eyeBeam 1.5

c=IN IP4 192.168.26.3

t=0 0

m=audio 8602 RTP/AVP 0 8 101

a=alt:1 4 : F4Vpy7HX BRVjd5rl 192.168.26.3 8602

a=alt:2 3 : ZTQ/VQpO 5uDGgHMJ 192.168.164.1 8602

a=alt:3 2 : ZZPaUsAW LVjbM9qy 192.168.74.1 8602

a=alt:4 1 : 5lOKe54U yTwyWfpC 11.11.0.122 8602

a=fmtp:101 0-15

a=rtpmap:101 telephone-event/8000

a=sendrecv

a=x-rtp-session-id:0CDBBC1F22564B72BDA5AD0B07C2AECF

200 OK

200 OK

Via: SIP/2.0/UDP
192.168.26.3:31556;received=Y.Y.Y.Y;branch=z9hG4bK-d87543-6a165215a2441724-1--d87543-;rport=31556

Record-Route: <sip:X.X.X.X:5065;lr;ftag=5269152d>

From: "+967123456" <sip:967123456@X.X.X.X:5065>;tag=5269152d

To: "9613159370" <sip:9613159370@X.X.X.X:5065>;tag=agtHmrp3Dccrg

Call-ID: c10f30782b42be0fNjNiNTdjNGM1MWIzNDlhNTM4MzAwYWI0NWY2NGRmOTM.

CSeq: 1 INVITE

Contact: <sip:9613159370@X.X.X.X:5060;transport=udp>

User-Agent: FIKAR

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY,
PUBLISH, SUBSCRIBE

Supported: timer, path, replaces

Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize,
call-info, sla, include-session-description, presence.winfo, message-summary, refer

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 200

Remote-Party-ID: "Outbound Call"
<sip:506251539613159370@X.X.X.X>;party=calling;privacy=off;screen=no

v=0

o=FIKAR 4050780586 4050780588 IN IP4 X.X.X.X

s=FIKAR

c=IN IP4 X.X.X.X

t=0 0

m=audio 24496 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

where:

X.X.X.X is Kamailio IP

Y.Y.Y.Y is origination public IP

Regards,

Ali

From: Konstantin Polyakov &lt;piligrim_pk(a)mail.ru&gt; 
Sent: Monday, July 23, 2018 12:08 PM
To: Ali Taher &lt;ataher(a)vanrise.com&gt;
Subject: Re[2]: [SR-Users] NATHELPER issue

Hello Ali,

Could you show your latest INVITE and OK?

Check you SDP bodies in those messages, if you still have there private IPs then you need
to solve usual NAT traversal task in your media software (not proxy).
Kamailio doesn't process media as you know. 
Of course you can try fix_nated_sdp  function from nathelper module but it will not work
for symmetric NAT because you fix SDP with public IP toward proxy but not toward UA.
Your media software or hardware should support STUN or ICE protocols to work correctly via
NAT.

Best regards.

Понедельник, 23 июля 2018, 11:41 +03:00 от Ali Taher &lt;ataher(a)vanrise.com
<mailto:ataher@vanrise.com> >:

Thank you for your reply.

ACK is now sent correctly to public IP , yet I have another issue with RBT  where it’s
still sent to private IP .Yet the call media is sent correctly to the public IP.

There is something strange , as I hear two short different ringing tones then complete
silence till the called party answer the call and RTP flow normally.

How can I handle this case?

Thanks,

Ali

From: Konstantin Polyakov &lt;piligrim_pk(a)mail.ru <mailto:piligrim_pk@mail.ru> >

Sent: Friday, July 20, 2018 3:01 PM
To: sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> ; Ali Taher
&lt;ataher(a)vanrise.com <mailto:ataher@vanrise.com> >
Subject: Re: [SR-Users] NATHELPER issue

Hello Ali,

ACK is sent by UAC to the Contact which is received in OK from UAS.
So from my point of view you need to fix that Contact in OK on your proxy.

My NATDETECT looks like:

    if (nat_uac_test("19")) {

       fix_nated_contact();

    }

I call it for requests and responses.

Best regards.
Konstantin

Message: 23
Date: Fri, 20 Jul 2018 11:13:42 +0300
From: "Ali Taher" &lt;ataher(a)vanrise.com
<file://e.mail.ru/compose/%3fmailto=mailto%253aataher@vanrise.com> >
To: &lt;sr-users(a)lists.sip-router.org
<file://e.mail.ru/compose/%3fmailto=mailto%253asr%252dusers@lists.sip%252drouter.org>
>
Subject: [SR-Users] NATHELPER issue
Message-ID: &lt;070901d42001$939be2b0$bad3a810$(a)vanrise.com
<file://e.mail.ru/compose/%3fmailto=mailto%253a070901d42001$939be2b0$bad3a810$@vanrise.com>
>
Content-Type: text/plain; charset="utf-8"

Hello,

I'm using Kamailio 4.2 as proxy with nathelper enabled.

Yet , the ACK packet sent from the proxy to the origination's private IP.

The ACK is sent as reply on the following 200 OK sent from the origination :

8m2EJN41BN/6WSIP/2.0 200 OK

From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze

To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000

Via: SIP/2.0/UDP
X.X.X.X:5065;branch=z9hG4bK2959.233ecbc5eff949f946d8763ce25e5e6d.0;received=
X.X.X.X,SIP/2.0/UDP
X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKN93cXvv26vDDN

Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze>

Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX
<file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX>

CSeq: 125698370 INVITE

Accept: application/sdp

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE

P-Charging-Vector:
icid-value=B0912C3D70-0720-09394507;icid-generated-at=BC00.XXXXXXXXXXXXXX.XX
;orig-ioi=MXXXXXXXXXXXXXX

Content-Type: application/sdp

Contact: <sip:172.16.45.65:5060;transport=UDP>

Content-Length: 268

v=0

o=- 5838243 5838244 IN IP4 BC00.XXXXXXXXXXXXXX

s=-

c=IN IP4 172.16.45.144

t=0 0

a=sendrecv

m=audio 47588 RTP/AVP 18 96

c=IN IP4 172.16.45.144

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=yes

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-15

a=maxptime:20

Following is the header of the sent ACK packet:

Request-Line: ACK sip:172.16.45.65:5060;transport=UDP SIP/2.0

Record-Route: <sip:X.X.X.X:5065;lr;ftag=XQBQNjvjgp4Ze>

Via: SIP/2.0/UDP
X.X.X.X:5065;branch=z9hG4bK2959.871535fd341bbe3099d0bf60d6460e18.0

Via: SIP/2.0/UDP
X.X.X.X;received=X.X.X.X;rport=5060;branch=z9hG4bKQUpy0jy90etjc

Max-Forwards: 69

From: <sip:+4444331234567@X.X.X.X;user=phone>;tag=XQBQNjvjgp4Ze

To: <sip:+905362695933@172.16.45.65;user=phone>;tag=12033368836000

Call-ID: CbeX8453909200habfGhEfElPce(a)BC00.XXXXXXXXXXXXXX
<file://e.mail.ru/compose/%3fmailto=mailto%253aCbeX8453909200habfGhEfElPce@BC00.XXXXXXXXXXXXXX>

CSeq: 125698370 ACK

Content-Length: 0

Where X.X.X.X is Kamailio server public IP.

Following is part of my config file :

route {

route(NATDETECT);

record_route();

        if(!mf_process_maxfwd_header("10")) {

                sl_send_reply("483", "Too Many Hops");

                exit;

        }

        # Maybe some sanity_check() here.

        if(has_totag()) {

                if(loose_route()) {

                route(DLGURI);

                        if(!t_relay())

                                sl_reply_error();

                        exit;

                } else {

                        if(is_method("ACK")) {

                        route(DLGURI);

                                if(t_check_trans()) {

                                        t_relay();

                                }

                        } else

                                sl_send_reply("403", "Forbidden");

                }

                exit;

        }

.....

}

route[NATDETECT] {

#!ifdef WITH_NAT

        force_rport();

        if (nat_uac_test("19")) {

                if (is_method("REGISTER")) {

                        fix_nated_register();

                } else {

                        add_contact_alias();

                }

                setflag(FLT_NATS);

        }

#!endif

        return;

}

route[DLGURI] {

#!ifdef WITH_NAT

        if(!isdsturiset()) {

         handle_ruri_alias();

        }

#!endif

        return;

} 

Can you please check why the ACK is still sent on private IP ?

Thanks

Ali Taher

"Ali Taher" &lt;ataher(a)vanrise.com
<https://e.mail.ru/compose?To=ataher@vanrise.com> >

С уважением,
Константин Поляков.