Via Header replaced when "Put Public IP in SIP VIA Header" selected

[fracarza]

I have a problem with my SIP Trunk. It registers fine and I can make outbound calls, but inbound calls do not work.

In particular an outbound RTP connection is created but the UAC does not respond to my 200 OK SDP thus not creating the inbound one. After some investigation I found out that this is caused by the option "Put Public IP in SIP VIA Header". When I receive the SDP INVITE in the VIA header there is the UAC IP x.y.z.w, but the 200 OK response contains instead my public IP a.b.c.d. This is rejected by the UAC. On the other hand disabling "Put Public IP in SIP VIA Header" leaves the VIA header untouched, but also naturally does not put the correct IP when it is my PBX that initiates the INVITE and also does not work. Indeed when using a different PBX - which preserves the IP on responses and puts the public IP in INVITEs - calls work correctly in both direction.

TLDR: How do I make it so that SIP packets initiated by 3CX contain my public IP in VIA, while responses contain the original IP.

 

[fracarza]

To give a bit more information, 3CX's behaviour is non-compliant with RFC3261 (8.2.6.2) since it rewrites the VIA header in the response. Unless I'm missing some setting.

 

[YiannisH_3CX]

Hello @fracarza

If you are behind NAT then the PBX should send its local IP in the VIA header during outbound calls and your provider should accept it. Each endpoint the call goes through must add its own VIA header so the call can find its way back on the return.
Since you are forcing the PBX to add its public IP in the VIA header through the options then the PBX will always add the public IP there regardless of what is received.
Your solution would be to install the PBX in a DMZ environment with a full public IP address and leave the option to default or to change providers.

Who is your provider if you don't mind me asking?

 

[fracarza]

If you are behind NAT then the PBX should send its local IP in the VIA header during outbound calls and your provider should accept it.

I don't think it should, but in any case it does not.

Each endpoint the call goes through must add its own VIA header so the call can find its way back on the return.

Only if the packet goes "through" a server then a VIA must be added. The UAS should not add its own VIA in a response, otherwise the UAC would receive multiple VIAs and discard the message.

Since you are forcing the PBX to add its public IP in the VIA header through the options then the PBX will always add the public IP there regardless of what is received.

This is wrong though, and non-compliant with the RFC. In a response the VIA header IP should not be touched, since it doesn't need to "find its way back". In fact not even 3CX does this by default, only when the option "Put Public IP in SIP VIA Header" is enabled. I do not know whether it's a bug (likely) or intentional behaviour that can be switched off.

The provider is Italy's Fastweb.

 

[YiannisH_3CX]

In fact not even 3CX does this by default, only when the option "Put Public IP in SIP VIA Header" is enabled. I do not know whether it's a bug (likely) or intentional behaviour that can be switched off.

I think you misunderstood the option. The option "Put Public IP in SIP VIA Header" forces the PBX to do just that in both directions. It is a force option that tells the PBX that it needs to add its public IP in the VIA no matter what.
It has been designed this and that is the way it works.

I understand that in normal conditions the VIA should be sent back exactly as received as per RFC but in your scenario you are telling the PBX to add its public.

Again your issue is with outbound calls. The provider should accept the local IP in the VIA header as 98% of providers do around the world. The ones who do not (an example i Gamma in the UK) do not mind the reply with the public VIA neither although it's not as per RFC.

I encourage you to have a look at our Italian supported providers list who work as intended with 3CX.

 

[fracarza]

@YiannisH_3CX Thank you! Indeed then I misunderstood the option. However I must still ask, are you sure this is not a bug?

I want requests to have my public IP address in the VIA, while responses should maintain the original IP address. This is the correct behaviour from the RFC point of view, the way 3CX does it breaks compliance and hopes the UAC does not care. Is there any way to achieve this correct behaviour with 3CX?

 

[YiannisH_3CX]

Thank you! Indeed then I misunderstood the option. However I must still ask, are you sure this is not a bug?

Yes I am sure.

Is there any way to achieve this correct behaviour with 3CX?

As I said in my earlier reply, you have 2 options with 3CX. You can install 3CX in a DMZ environment when the PBX is fully public with no local IP or you can switch to a supported provider. Currently there are no other options.

 

[fracarza]

As I said in my earlier reply, you have 2 options with 3CX. You can install 3CX in a DMZ environment when the PBX is fully public with no local IP or you can switch to a supported provider. Currently there are no other options.

Sorry to be repetitive but I want to make 100% sure.

There is, as far as I can tell, no reason whatsoever or advantage for a UAS to rewrite VIA's "sent-by" on responses. 3CX consciously decides to exhibit a completely non-standard and anomalous behaviour, to a trivial situation that other PBXs handle without issue. Moreover, there is no way to get a compliant behaviour through any setting at all.
I understand that my provider is also not completely compliant, but that is something I cannot change. What I can change is 3CX's settings, and I would expect to be able to do something so simple on a professional-level product.

I am sorry but this seems very very baffling to me. I do not want to sound ungrateful for your help, but could you perhaps consult with a colleague whether this is truly intentional? If my previous explanation was not clear, please let me know and I will try to explain myself better.

 

[NickD_3CX]

Hi @fracarza ,

First let me clarify something, the option "Put Public IP in SIP VIA Header" was implemented primarily for certain providers that require the behavior to be exactly as this option works, in other words, to re-write the Via header.

Now, if your provider does not require this, then you need to uncheck it. However, in this case your provider needs to be in a position to handle a Local IP in the Via header. and respect the "Contact" header and reply to that.

My colleague @YiannisH_3CX suggested a work-around if you are for some reason forced to use this provider: set the PBX up in a DMZ with a Public IP directly on its NIC, this way with this option unchecked, 3CX will send the NIC IP, which is also the Public IP to your provider.

If you can't do this, then our next best suggestion is port your numbers to another provider that is tested and is on our list.

Other than this, we as 3CX cannot suggest something else that I can think of.

 

[fracarza]

First let me clarify something, the option "Put Public IP in SIP VIA Header" was implemented primarily for certain providers that require the behavior to be exactly as this option works, in other words, to re-write the Via header.

I find this quite hard to believe as it goes against any industry standard implementation I have ever seen, so it looks to me like a case of "It's not a bug, it's a feature".

In any case this is your product so you can do what you want, I will just have to use something else.

Anyway, thank you very much @YiannisH_3CX and @NickD_3CX for your clarifications!