3CX Sending SIP VIA Header (again)

[eddv123]

I want to re-visit this post here:
https://www.3cx.com/community/threads/sip-via-header.66455/

I am testing an Edgemarc SBC onsite in transparent mode (phones in STUN mode) not my favourite method of setup but want to look at the MOS scores and added security onsite that the device brings.

All working fine, device registers the hosted systems FQDN and endpoints and outbound calls work fine however inbound calls fail every time and it is due to this SIP VIA header sending the local IP address of 3CX (not the public) if 3CX sends the public IP then it would work, the SBC is coming up with an error due to this. SIP via header from 3CX below:

Via: SIP/2.0/UDP 192.168.251.3:5060;branch=z9hG4bK-524287-1---ff5f70753a007c27;rport

It is almost as if the setting for SIP trunks "Send public IP in via header" is required per extension to make this work, with this probably never being considered or implemented I guess my question is, does anyone know anyway that 3CX can be forced to ignore the sending of the VIA header in SIP ?

Alternately anyone who has set up Edgemarc's with 3CX please let me know your configuration experience.

I repeat - there are no settings on the SIP trunks/SIP trunking that will effect this behaviour - the issue is the leg of the call from 3CX to the endpoints inbound.

 

[cobaltit]

So this seems to be an Edgemarc configuration issue if I'm understanding the situation correctly. 3CX is simply reaching out to the endpoint based on the information that was provided when it registered through the Edgemarc. I don't thing there is anything you can do in 3CX. That being said, you might be able to change one of the parameters on the phone (you don't mention the model/brand) which could then be configured via a custom template.

 

[eddv123]

you might be able to change one of the parameters on the phone (you don't mention the model/brand)

These are Yealink's and yes we have tried turning off STUN on the phones (as the Edgemarc is also acting as a STUN server) and using a proxy address as the SBC (I am working with Ribbon UK).

Both produce the same results. Bar trying to build a bridge or tunnel to the device then I agree there are no other settings that could be tried (the device is acting in transparent mode so we don't want to do that).

There is indication online that some partners have got this working in the U.S however.

https://support.cloudcopartner.com/article/319-methods-of-connecting-phones-to-cloudco-pbx
http://voipsystemtech.com/