How do I flip that around where I’m the provider not the client. Basically on my cloud PBX I would have two Trunks, “MYWholesaler” and “MYCustomer”. So when my customer dials out from their PBX, they have their system setup to send outbound SIP calls to my cloud server and bounces right out to my wholesaler, carrying their caller ID that their PBX sends, etc. And same thing for their incoming calls, it would come in from MYWholesaler and bounce right out via MYCustomer and go to their PBX as an incoming call to their PBX. I just want my customer to authenticate with me using their IP just like I do with my wholesaler using my IP. That way my customer can simply have whatever SIP based PBX solution they want in their office and they just use my IP as a trunk on their system.
If you are a “provider” I suggest you look into using a true sip proxy to provide that sort of service. Asterisk is a back2back user agent and isn’well designed for what you want nor does it scale well.
You could set up many trunks, one for each client using the peer type but the far end host would each need to be a static IP .
@dicko is correct. Asterisk really doesn’t do what you want it to do in a way that scales well.
It isn’t the type= or host= that’s going to mess you up. With that connection setup, it’s the call routing. How do you plan to route the calls for a specific customer to their PBX without some kind of authentication that establishes a phone number? The DID will get processed by your server and routed, but which connected PBX are you going to send to call to? Your description makes it sound line “all of them”, which I’m pretty sure isn’t what you are shooting for. You only have one trunk, so everything is going out on that trunk, and all of your subscribers are connected to that trunk. That means that each of them is going to have to eschew a “default” incoming route because the first PBX that answers will just get the call, regardless of dialed number.
Thanks for the responses. Dicko, when you say “true sip proxy” what are you referring to? Do you mean a different type of appliance or server that would handle the call routing?
Also, my couple trunks to my wholesaler would handle the incoming and outbound calls for all my customers. When my customer receives a call, my goal was to have my wholesaler send calls for all customers to my host and then based on the dialed DID, it will send it out the appropriate customer’s trunk via inbound route configurations and send it to their PBX on site.
I do agree with that there should be a better way to do this rather than using a this clunky way of doing it. So I guess my question is what is out there that could handle this?
That answer changes one of the key dynamics of your original question.
You are going to set up a trunk for each of your customers and have a “use this route if this number was dialed” rule. This is where the system gets bogged. The trunks are scanned in order for “authorized number” connections and the search in linear. You start at the top and work your way down to the bottom. You also have to set up a trunk and outgoing rules for each of the connections to your customers.
Finally, Sangoma has announced that “Chan-SIP” is going away in deference to the new “PJ-SIP” channel driver, which doesn’t do “simple” SIP connections anymore (passwords are required, no more host-based authentication, etc.) It sounds like any structure you set up to support this is going to be deprecated relatively shortly, which means annoying and losing more of your customers.
Google for “SIP PROXY” and you will find quite a bit of information about this.
I have googled sip proxy but get millions of ads on signing up with a sip provider. I already have one and that’s not what I’m trying to do. I will keep searching thanks for the thoughts.
Kamailio is a truly flexible SIP Proxy, but for the full PBX experience I prefer Asterisk/FreePBX as SEMS/Kamailio doesn’t quite cut it, so unless you need to provide PBX features, and from a quick look, you don’t , Maybe just use Kamailio on it’s own.
If you need individual client PBI then have the extensions register to the FreePBI and the FreePBI use Kamailio for Trunking in and out. Don’t try and use one instance of FreePBX for more than one client, if you do, you will soon find out why that was a bad idea
You can do this with FreePBX / Asterisk using the Extensions module. Set up each of your clients as if they were a phone and route to/from them as if they were a phone.
The trick is when you define the extension, use a smart extension numbering scheme so that you don’t end up with conflicts amongst your customers, set a blank password, and in the Host field, specify their IP address instead of “dynamic”. FreePBX will warn you about having an empty Secret field, but you can proceed anyway.
The conflicts go further, in the voicemail contexts, in the local extensions numbering, directory access , in fact any endpoint numbering, be that RG’s Queues etc., the list goes on and on . . . . FreePBX is just NOT that scalable, you will see when or if you try it . . .
Dicko, understood. Is it not scalable because there’s just so much gong on with all those items you listed during call setup compared to what Kamailio has to process during call setup?
I’m spinning up a VM and starting to learn it. Very excited, thanks.
That’s why a Proxy is so good, it handles the SIP signalling and delegates the resultant call plus any SDP sessions resultant to the relevant endpoint, it is much better SIP compliant than chan-sip or chan-pjsip in asterisk, you will see . . .
There’s the rub, bridging calls in itself will scale out very quickly in a B2BUA, not so much with a Proxy, what happens when the network goes down to the Asterisk box? no BGP or fail-over possible. the call is bridged even if you can off-load the RDP session.
Good thoughts. It sounds like if I want to get away with 2 or 3 customers, using bridging via what Bill described, I can do it. But going beyond I need to learn some other methods.
The bridging call concept is a whole other thing spinning in my mind. Right now my voip wholesler’s sip proxies are nice because you trunk with them to setup the call, but the RTP stream is actually directly with the carrier, like Level3. So for the important part, the RTP stream, the wholesaler is taken out of the picture and thus you have less hops. (I’m sure that is common thing to do and my wholesaler is not “extra amazing”) Either way that’s pretty cool. I want to learn how that works!
It is seriously productive to learn “other software” to achieve what your desire. SIP is SIP with all its RFC’s and complexities , some SIP stacks are less able, some more. You will, I am sure, be happy with Kamailio when you explore it. It’s well worth the effort.
. . .