Why 3cx PBX ver 6.0 put's 0.0.0.0 into contact header?

[heyphets]

Hi guys,

I've been searching through the forum by couldn't find any similar issue.

I have configured VoIP provider in 3cx. Registration is not required, IP for Contact header is set to Internal. Everything works fine for both incoming and outgoing calls. However, in Wireshark traces, I can see that 3cx puts 0.0.0.0 into it's contact header for incoming calls. This is clearly non-compliant with RFC3261, and I'm lucky that my VoIP provider doesn't care about this non-compliance. But I might need to connect to other VoIP providers, that are much more serious about RFC3261 compliance.

Did anybody experience same behavior?

 

[Discovery Technology]

STUN registrations are all happy and working? 3478 is forwarded back to the 3CX server and the firewall tests all pass?

If they do, we'll run a capture on ours and I'll let you know what we see at our end.

 

[tekknow]

Is your 3CX behind a NAT ? Where is the registration coming from behind the same NAT? What other IP shows in those headers? a LAN IP or a Public IP?

 

[heyphets]

ok, guys, here is the story.

I'm not using STUN (removed STUN entries in General Settings) and I'm behind 2 static nats (in fact it doesn't matter whether it's 1 nat or 10 after all ;-) ) .

I've attached diagram. I think the problem is not with nats, but with the fact that server is multihomed. I have phones on 192.168.1.0/24 network, and VoIP trunk connection on 172.16.1.0/24 network. This is done for security purposes. Server is provisioned with static IP routes to SIP Proxy pointing to 172.16.1.1 as gateway (therefore using 172.16.1.3 interface). For 192.168.1.3 interface, default gateway is configured.

Registration is not used, VoIP provider authenticates me by IP address. I've configured 3CX to use "Internal IP" for contact header.
Other headers are just fine, they either contain FQDN (for example from/to fields) or internal IP (172.16.1.3 in Via). And the only thing I need from 3cx PBX is to put 172.16.1.3 into Contact header instead of 0.0.0.0.

 

[heyphets]

Any ideas?

 

[BJReplay]

I would have thought you actually want 3CX to put either x.x.x.x or y.y.y.y in the contact header (I can't really tell from your diagram, but I'm guessing that y.y.y.y is a SIP proxy, and x.x.x.x is the IP address that is connecting to the proxy), and that's what you want going out as your Contact header, and 172.16.1.3 in the Via.

I'm guessing, though, that you've indicated that your VoIP provider doesn't require registration in the provider config, 3CX is putting in 0.0.0.0.

Having not just read the RFC, I don't know the correct behaviour here - should Contact ID always be specified, or can it not be provided if not registering?

I'd guess that if you changed to requires registration, and specified x.x.x.x in the Specified IP option Which IP to use for Contact field setting, you'd see a different result in your capture (e.g. the specified IP).

I have a similar setup (but without the SIP Proxy) - I just specify my static external IP as the Contact ID setting (I do need to register), and let the 2 static NATs route for me.

Finally, I left the STUN settings there in the general settings - 3CX seems to cope better if it can determine the IP via Stun, even if I've got it specified in my VoIP provider settings

 

[heyphets]

Hi BJReplay,

Thanks for reply.

Basically, what are you saying is that 3cx is much more tested with Registering trunks and therefore number of issues there is less. I'll try the "registering" option with my VoIP provider. Still I believe it's a bug and 3cx could look into it.

 

[yopik]

Have same observation, only I see also in the "From" field zeroes in the IP portion.
Certainly this does not comply with RFC3261.
I currently use it in lab only with a few user agents (HT-502 and ZoIPER softphone). There seems to be no problem making voice calls, however when a fax is attempted, either the call is rejected or the fax fails to switch to T.38 on the Re-Invite. I suspect the format of the zeroed IP address causes the HT-502 to refrain from sending the Re-Invite.

 

[heyphets]

ok, I've found a workaround.

I've configured static route for STUN server IP address and restarted the service. Now it has succesfully resolved the IP through STUN and uses Internal IP (as per settings) instead of 0.0.0.0 in the header.