Local IP in external SIP VIA header

[millsey]

Hi all,

I have identified that 3CX is sending the internal IP address not the external address in the SIP VIA header for communication between the 3CX ans external SIP trunk provider., this causes outgoing INVITES to not be acknowledged and other SIP issues. I have checked that this is in the communication between the 3CX and my SIP trunk provider, and I have checked the network external address and the two places in the Advanced tab of the trunk settings.

This is really strange that it happens for some calls and not others, it looks like a fault in 3CX to me.

If anyone can help with this I would be very grateful. We cannot use SIP ALG as this breaks other parts especially audio.

Regards
Millsey

 

[cobaltit]

I can help.

Step 1 - Get specific. You didn't list your 3CX version, your firewall, your network configuration or your SIP provider. You also haven't given details on how you've determined this is what is happening.

 

[YiannisH_3CX]

Hello @millsey

Please navigate to your trunk settings and then to the Options tab. Enable the option "Put Public IP in SIP VIA Header". Check if that works.

 

[millsey]

Hi YiannisH,

We are using version 14.5 - we have a lot of work to do to migrate to v15 as we use the VAD extensively. We haev been observing this issue from Wireshark.

The external IP address is already in "Put PUBLIC IP in SIP VIA Header" and in "Which IP to use in Connect and Contact". I can see that this is happening in our Wireshark traces, but specifically it does not happen for a period of time then starts happening again. It has just started happening again;

The Wireshark shows a BYE packet from 3CX to our trunk provider's SBC

BYE sip:07763389211@<PROVIDER-IP>:5060 SIP/2.0
Via: SIP/2.0/UDP <3CXINTERNALIP>:5060;branch=z9hG4bK-d8754z-9524476683414955-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:01704515500@<PROVIDERIP>:5060>
To: <sip:<CALLERNUMBER>@<PROVIDERIP>;user=phone>;tag=3745134201-132688
From: <sip:<TRUNKNUMBER>@<PROVIDERIP>:5060;user=phone>;tag=6762420e
Call-ID: [email protected]
CSeq: 2 BYE
User-Agent: 3CXPhoneSystem 14.0.49169.513 (48654)
Content-Length: 0

As the same time, other message types (e.g.OK, ACK) give the correct IP address in VIA. This switches back and forth such that the INVITE header may start using the internal address.

We do use an odd Internal IP range of 89.0.4.0/16 and I just noticed that this range is not in the system parameter "LOCALSUBNETS" - should it be in there to ensure 3CX knows that the internal IP address is actually internal?

We just spotted this as we have moved firewalls, from an old CISCO ASA 5505 with SIL Inspect (ALG) enabled, this device was correcting the packets as we did nto have the issue, to a Watchguard, without SIP ALG as runnign with SIP ALG gives one way audio.


Millsey

 

[YiannisH_3CX]

I do not think that your local subnet can affect the PBX so the VIA header is not populated with your public IP but the only thing i can recommend at this point is to upgrade to the latest version and use an RFC1918 local subnet. That should solve your issue.

 

[millsey]

Hi

Is there a specific known change since 14.5 which is known to resolve this issue? As I said we use VAD extensively so upgrading will literally be 2 weeks work. If we carried out the upgrade and still had the problem that would be an extremely difficult situation for us. Additionally we have 900+ devices on the network, it would be a major project to change the addressing. There must be a reason why the program writes the internal IP address in the VIA header, and so there may be a way to influence that.

Millsey.

 

[YiannisH_3CX]

There were a lot of improvements in the way the PBX works since V14 and we do have supported providers that require the public IP in VIA that work without issues. One example is Gamma. Please note that i would recommend you upgrading to the latest version anyway as your PBX will not be able to activate after 15/09/218 due to a certificate expiring in our activation server. Since you are running V14 you should have received an email regarding this already.