Internal extension of one PBX as a SIP trunk of another

[oferlap]

Is it possible to chain two 3CX PBXs using SIP trunk mechanism?
a friend of mine has his own 3CX PBX on premise, and so do I.
He defined an internal extension for me in his system, which I successfully set using any SIP client, 3CX app and a multi account SIP phone to name a few.
but my goal is to be able to call him for free without the need to switch accounts on my apps and phones.
So, I created a generic SIP trunk in my system, used my friend's extension provisioning credentials,
firstly I tried using Authentication ID and Password from "phone provisioning" tab of the extension, then I tried the extension number as the username, both failed to register for the same reason - credentials don't match.
Is it even possible for an arrangement of this sort to work?
If so, are there any other parameters which need to be set so that it registers as if it were a SIP client?

Thanks

 

[Marconi]

Ideally you would use a bridge to connect the 2 PBX systems (see here) but, in theory, it's possible to link the systems using internal extensions.

You would (probably) need a dedicated extension on each end (certainly you'd need it on one end) and it would take some experimentation to get the settings right. You'd probably want to put in a whitelist entry on each side so that the connection isn't blocked while you're trying to get it working. It would be similar to connecting an unsupported phone and you wouldn't get any help from 3CX for it.

 

[leejor]

I'd also look to establish a bridge trunk. Taking a detailed look at the Activity Log, at both ends, may give you more info on what isn't set quite right.

 

[oferlap]

I seem to have found at least one problem so far, but I don't know how to fix it - my PBX tries to register 10007@friends_domain, which isn't the correct extension number, which is a four digit one.
but, unlike SIP clients or IP Phones, whether supported or not, there are no separated fields here for SIP ID and Authentication ID, and that 5 digit internal trunk number, looks permanent and automatically set.
Perhaps a change in one of the Inbound/Outbound rules might du the job, that seems to be the only route left.

 

[oferlap]

OK, after some experimenting with white listing as suggested, problem is solved.

Authentication ID should be the Extension number.
Authentication Password is the extension's Password.
3 way Authentication Password should be enabled, and Authentication ID string is it's field value.

The rest is a matter of outbound rules so that calls are routed correctly.

 

[YiannisH_3CX]

You could have made your life easier and used IP based trunks that do not require authentication or dedicated extensions.

 

[oferlap]

Would you please elaborate? is it possible to achieve using only what's available within 3CX itself, no 3rd party services are required?

The main reason BTW, why we wanted to have the option to reach each other directly, apart from experimenting the subject, is the obvious superior sound quality when using codecs like Opus and G722, which are generally not supported by larger scale trunk providers.

 

[YiannisH_3CX]

Would you please elaborate? is it possible to achieve using only what's available within 3CX itself, no 3rd party services are required?

You can create an IP based trunk using the Generic SIP Trunk template and add the IP and port (you can also use the FQDN) of the remote 3CX PBX you want to call. The same from the other side. Use a fake number on each side and you can make calls from one PBX to the other.

The Outbound/Inbound rules should be adjusted accordingly.

 

[oferlap]

After some trial and error implementing your advice, I now have a better understanding of DIDs and IP Based Trunks
so I also managed to switch my VoIP provider's settings into IP based.

For anyone willing to implement the same idea, here is a tip:
after creating IP Based trunk on each side, Define DIDs for each extension you would wish to reach - any fake number would do the job, but I found it easier to prepend a digit to the actual extension number(s).
This way I can set inbound caller ID rules within the settings of each Trunk, so that the prepending digit is removed when receiving calls, and what's being displayed is the extension number which the callee can then easily return to.
Outbound rule(s) on each side are also easier to set up this way, for there is only a need to prepend a digit to the remote extension number being dialled, before it is sent through the other side's trunk.