- Joined
- Jul 8, 2020
- Messages
- 2
- Reaction score
- 0
Due to certain network requirements, all of our remote and mobile extensions need to have SIP conversations with 3cx via a Proxy server, like so:
This works fine for outbound calls (to PSTN via SIP Trunk) from the mobile extensions -- with each softphone/app pointing to the Proxy as an "Outbound Proxy" --, but inbound DID calls routed to these mobile extensions are not working.
Can mobile extensions be made to work bi-directionally in this scenario, where SIP traffic must make a hop through a proxy between the client and the PBX?
A bit of detail: The Proxy is (correctly, I believe) adding a Path header to the REGISTERs it sends to 3CX, per RFC 3327. But 3CX does not seem to be respecting this Path header, and does not send INVITEs to the client via the proxy -- in fact, 3CX does not appear to be sending an INVITE at all to the client extension, even though 3CX correctly identifies (per Inbound Rule) the right extension to send to (per verbose 3CX Activity Log). In fact, 3CX does not send an INVITE at all! It just eats the INVITE from the SIP Trunk, and silently fails (again, per 3CX Activity Log).
Does 3CX support such a network configuration? Or, even if not "supported", can it be made to work? Is there some other way to "force" 3CX to make/handle that proxy hop?
Thanks,
Carbonara
Code:
SIP SIP
Client <--------------> Proxy <--------------> 3CX
^ ^
| |
-----------------------------------------------
RTP
This works fine for outbound calls (to PSTN via SIP Trunk) from the mobile extensions -- with each softphone/app pointing to the Proxy as an "Outbound Proxy" --, but inbound DID calls routed to these mobile extensions are not working.
Can mobile extensions be made to work bi-directionally in this scenario, where SIP traffic must make a hop through a proxy between the client and the PBX?
A bit of detail: The Proxy is (correctly, I believe) adding a Path header to the REGISTERs it sends to 3CX, per RFC 3327. But 3CX does not seem to be respecting this Path header, and does not send INVITEs to the client via the proxy -- in fact, 3CX does not appear to be sending an INVITE at all to the client extension, even though 3CX correctly identifies (per Inbound Rule) the right extension to send to (per verbose 3CX Activity Log). In fact, 3CX does not send an INVITE at all! It just eats the INVITE from the SIP Trunk, and silently fails (again, per 3CX Activity Log).
Does 3CX support such a network configuration? Or, even if not "supported", can it be made to work? Is there some other way to "force" 3CX to make/handle that proxy hop?
Thanks,
Carbonara