How can I dial in from another Pbx, I,e 1000@domain. Xyz? I can do it by allowing the remote IP in the ACL, but then calls from extensions on the same IP fail to each other..
What am I missing?
What am I missing?
Dialling in from a second pbx
- Thread starter timerider
- Start date
- Status
There is more than one way of doing this. The way I choose, helps to self document the link and I use a psudo DDI number based on the customers actual DDI number. Let me try to explain...
I will describe one direction (PBX1 to PBX2). The real DDI belonging to the tenant (customer) on PBX2 is 01636123456.
Put the IP address of BPX1 into the Domains ACL on PBX2.
Next, make an outbound route on your chosen tenant on PBX1, I chose a prefix of 82, followed by the three digit extension number of the device on PBX2. I give all the psudo DDI numbers a prefix of 88. Notice the bridge statement is connecting to 88<customer DDI><ext> on the port (5080) associated with the external SIP profile on PBX2.
The outbound route above will drop the call into the public context on PBX2, so we now just need to create an inbound route:
... And that's all there is to it. Customers can make sense of the CDR records that using it produces, and if you set up the reverse direction with the prefix 81 (as set up in the 82 outbound route) in the outbound route, then there is no confusion in making a return call.
I hope that makes some sense, I'm sure you can modify or adapt the concept to fit your needs.
Adrian.
I will describe one direction (PBX1 to PBX2). The real DDI belonging to the tenant (customer) on PBX2 is 01636123456.
Put the IP address of BPX1 into the Domains ACL on PBX2.
Next, make an outbound route on your chosen tenant on PBX1, I chose a prefix of 82, followed by the three digit extension number of the device on PBX2. I give all the psudo DDI numbers a prefix of 88. Notice the bridge statement is connecting to 88<customer DDI><ext> on the port (5080) associated with the external SIP profile on PBX2.
The outbound route above will drop the call into the public context on PBX2, so we now just need to create an inbound route:
... And that's all there is to it. Customers can make sense of the CDR records that using it produces, and if you set up the reverse direction with the prefix 81 (as set up in the 82 outbound route) in the outbound route, then there is no confusion in making a return call.
I hope that makes some sense, I'm sure you can modify or adapt the concept to fit your needs.
Adrian.
Thanks Adrian, I'll look at this in more detail when I get a chance between my other work. Mainly want it so I can retire my other two pbx's, one is an old asterisk (on-site), the other an old freeswitch (off-site). During the migration wanted to be sure all calls still went 'somewhere' as smoothly as possible.
It's been 6+years since we put together the freeswitch box. It's ran super smooth with uptime only interrupted by the odd update, I'll not pretend I understood freeswitch enough then, but most of what I did know I've forgotten :/
This forum is both useful and thought provoking
It's been 6+years since we put together the freeswitch box. It's ran super smooth with uptime only interrupted by the odd update, I'll not pretend I understood freeswitch enough then, but most of what I did know I've forgotten :/
This forum is both useful and thought provoking
- Status