FS sends invite to private IP of client behind NAT

[Dee]

Hello everyone

I have an issue where FS is sending invite to the private IP of my soft phone which is connected to a router behind NAT

Is there a simple way for force FS to use the public IP of the clients when sending invite.


Have tried add param sip-force-contact = NDLB-connectile-dysfunction to the internal profile but it doesn't work. FS still randomly sends invite to the internal IP of clients behind NAT even though FS also has the public IP.


Any suggestions to fix this?

 

[DigitalDaz]

Paste a siptrace of a call

 

[Adrian Fretwell]

... And possibly a siptrace of the registration messages?

 

[Dee]

Please see the redacted version of the invite. The extension being dialled is 1008 and but FS is sending the invite to the internal IP of the extension --- 192.168.4.10 which obviously mean the call doesn't connect. I need to force FS to use the public iP of the client no the LAN IP.




INVITE sip:1008@192.168.4.10:50260;app-id=xxxx.co.uk.voip.prod;pn-tok=EXXXXXX;pn-type=apple;pn-prid=xxxxxxxx

C3XXA84XXXXXX36CF79:voip;pn-provider=apns;pn-param=XXXX.uk.voip;pn-silent=1;pn-timeout=0;pn-msg-str=IM_MSG;pn-call-str=IC_MSG;pn-groupchat-str=GC_MSG;pn-c

l-snd=notes_of_the_optimistic.caf;pn-msg-snd=msg.caf;transport=tcp SIP/2.0

Via: SIP/2.0/TCP XXXXXX216;rport;branch=XXXX2Qc

Route: <sip:1008@XXXXXXXXX.7:50260>;app-id=XXXXX.uk.voip.XX;pn-tok=XXXXXXXXX5B632C3C636A8XXXXXXX;pn-type=apple;pn-prid=XXXXXXX6Cssss

6XX6A8XXXXX:voip;pn-provider=apns;pn-param=AXXX.XXXXXXo.uk.voip;pn-silent=1;pn-timeout=0;pn-msg-str=IM_MSG;pn-call-str=IC_MSG;pn-groupchat-str=GC_MSG;p

call-snd=notes_of_the_optimistic.caf;pn-msg-snd=msg.caf;transport=tcp

Max-Forwards: 69

From: "1001" <sip:1001@XXXXXXXXX.net>;tag=j5gXg7ZrZ6Z6H

To: <sip:1008@192.168.4.10:50260;app-id=XXXXXXXco.uk.voip.prod;pn-tok=XXXXXXXXXXXXXXF79;pn-type=apple;pn-prid=XXXXXXX

CXXXXX0XXXXX9:voip;pn-provider=apns;pn-param=AXXXXXX.XXXX.uk.voip;pn-silent=1;pn-timeout=0;pn-msg-str=IM_MSG;pn-call-str=IC_MSG;pn-groupchat-str=GC_MSG;pn-cal

snd=notes_of_the_optimistic.caf;pn-msg-snd=msg.caf;transport=tcp>

Call-ID: XXXXXXX-923aXXXX

CSeq: 5XXXX6 INVITE

Contact: <sip:mod_sofia@XXXXXX:5060;transport=tcp>

User-Agent: FreeSWITCH

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

Session-Expires: 120;refresher=uac

Min-SE: 120

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 524

X-FS-Support: update_display,send_info

Remote-Party-ID: "1001" <sip:1001@XXXXXXXXXnet>;party=calling;screen=yes;privacy=off

 

[Dee]

am thinking there must be some kind of configuration to force freeswitch to use the public IP always when sending sip invite

 

[Adrian Fretwell]

You need to look at how 1008 is registering.

 

[Dee]

1008 is registering with the public IP.

Also in fusion GUI - You can see the LAN IP ( private) and the public IP on the registration page

 

[Adrian Fretwell]

Also in fusion GUI - You can see the LAN IP ( private) and the public IP on the registration page

That is pretty normal.

FreeSWITCH will send invites to the IP in the contact header in the registration message, if FS realises that the contact header differs from the actual IP and Port that the request was sent from it will assume NAT is involved and adjust the stored contact details accordingly. That is why a sip trace of the registration process may help us in working out exactly what is going on.

 

[Dee]

Thanks - the registration process is adjusting processing...
Initially, it registers with 192..FS can see it is a internal IP in the contact and sends 401 unauthorized, and subsequently it send the correct IP again and FS sends 200 ok and it registers well...with the correct ip.


However this means I have a record of two registrations...the first one ( internal) which was rejected and the second which was accepted.

When a call comes in, it appears freeswitch just attempts to use the contact details in the first registration which result means the call cannot connect

 

[hfoster]

Have you got rport enabled? Unless your FreeSWITCH is behind NAT, you rarely need to adjust anything for a standard registration sourced from behind NAT.

 

[Dee]

I have the paramter added to internal profile

NDLB-force-rport
safe
true


Is there anything else you think i need to enable?

 

[Adrian Fretwell]

Initially, it registers with 192..FS can see it is a internal IP in the contact and sends 401 unauthorized, and subsequently it send the correct IP again and FS sends 200 ok and it registers well...with the correct ip.

Something is not right here, an endpoint should not change the contact IP it sends based on it receiving a 401. Did you get this information from a proper packet capture?

 

[Dee]

Something is not right here, an endpoint should not change the contact IP it sends based on it receiving a 401. Did you get this information from a proper packet capture?

Yes - I got this from sngrep.

 

[Adrian Fretwell]

The screenshot is largely meaningless without all the detail. Your sngrep is showing 8 messages, we would need to see the contents of all of those messages and the to and from IPs and ports.

If you user the F2 key you can save as pcap. Seeing that would be helpful, but I fully appreciate that you may not with to share it without redacting some detail.