• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

sip trunks config and node4.co.uk

Status
Not open for further replies.

sharmack

Joined
Oct 7, 2008
Messages
20
Reaction score
0
Hi Guys
I've been trying to configure my 3cx pbx v7 to connect to UK provider http://www.node4.co.uk
With SIP trunks settings as follow:
SIPLInk server:sip.node4.co.uk
Customer SIP server:213.249.254.XXX
Inbound number assing to SIP trunk: 08454130XXX
Outbound calls allowed to dial : 01,02 (all local calls up to 120s)

No registration is required neither user ID passwords etc

Everything is working fine with incoming calls. So If you dial 08454130XXX call is routed via node4 to my PBX in the office
then its routed internally to correct ext.
I can answer it have nice very good quality conversation

However we were unable to configure PBX to be able to make outgoing calls
As any attemps ebd up with error like this:
Called failed; Forbiden 403

Node4 people are saying that my public IP address 213.249.254.XXX is not included in VIA header of the SIP message
so their server refuses the connection as not legitimate
I have been trying to manipulate the headers to see if I can include our Public IP in the VIA header but so far no luck

Does anyone know how to configure the VIA header via 3cx so my ip address is inlcuded?
Btw I'm using generic SIP trunk template when setting up new VOIP gateway
I have installed wireshark to trace the call and I can see that my public IP address is not included in any of the messages sent to Node4

My PBX is behind Netgear WGR614 router which does NAT from 213.249.254.XXX to 192.168.0.X
My PBX IP is 192.168.0.8

Cheers
Shaun
 
I've found a few posts on this site detail this problem and similar.

I too have it with a provider that I'm using. The problem seems to be that the Quintum gateway that they are using into the PSTN doesn't like the via header (it's log specifically mentions the top Via" which contains our servers private IP address rather than the publicly IP which has ports forwarded appropritely.

This was all working previously because (without my knowledge) a previous router had a SIP ALG function which was enabled, and substituting the public IP for the private within the SIP header.

For various reasons that router is now swapped out, and the new router is not doing this, and suddenly our outgoing calls won't work anymore. Incoming is fine.

I understand that different pieces of equipment interpret the SIP spec in different ways, but it would be really helpful if the Voip Providers setup had the opportunity to set an option to replace the server IP in the Via header with the externally resolved STUN server. I don't see any other way to resolve this particular situation, and whereas I understand that your reading of the SIP RFC may well be the correct one, surely making 3CX more compatible with other equipment is more useful than just enforcing strict compliance with the RFC's?

Obviously if anyone has any other ways of dealing with this that I haven't found, then please... I'm more than happy to look at those too!

Thanks!


Nich
 
Nick / Shaun,

The issue that you describe is down to the VIA field not being editable within 3CX (and quite possibly your router / firewall editing the VIA field to the outside) to contain a private address instead of your PBX system's outside address.

We can however override this to overcome the issue - if anyone else experiences the same problem and happens to find this post, please call Node4's technical support on 08451232229 or register and log a ticket via our helpdesk system: http://support.node4.co.uk and we can resolve the issue.

Regards

Scott
N4 Tech Support
[email protected]
 
Hi there

As far as I can understand, the Via header is designed for a SIP Proxy behind a NAT device (such as 3CX is) to declare its PRIVATE IP Address and Port, and specify an additional "rport" parameter WITHOUT a value - this so that the next SIP proxy in the chain (in this case node4) can populate the rport parameter with the actual port number which it sees the packet coming from, and additionally add a new parameter "received" to fill it with the actual Public IP address which it sees the packet coming from.

This way, the upstream SIP proxy (in this case node4) will have a record not only of the PBX's private IP Address, but also it's PUBLIC IP Address and Port - effectively a full knowledge of the NAT traversal mappings which have happened. This proxy would then send its responses to the IP Address and Port contained in the "received" and "rport" parameters.

This mechanism is the subject of RFC3581 http://www.ietf.org/rfc/rfc3581.txt, and section 6 titled "Example" seems very clear on the subject.

Am I missing something?

Regards

Kevin Attard Compagno
Technical Support Manager
3CX Ltd.
 
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Members Online Now

Forum statistics

Threads
141,405
Messages
747,499
Members
144,371
Latest member
NYCTECHZONE
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.