Bridge calls between accounts using Pivot

[FASTDEVICE]

Is it possible to bridge across accounts programmatically using Pivot by returning the other accounts resources: main callflow, a callflow extension/ pattern, userID, or deviceID directly? I don't want to bridge via DID. 

[mc_]

Not really. Most operators still bill account A for calling account B, even if the call doesn't leave the system. You might assign "internal" DIDs to your accounts' callflows that you track (that aren't route-able); since you track them you could "dial" "abc123" to route to account A's "123" callflow? Hacky but....

[FASTDEVICE]

Would you please elaborate more on what you are calling "Internal DIDs?" Do I need 2600hz support to set one up, or simply place any 10-digit E.164 format number as the extension of the callflow? 

[tomas_]

I've thought about this before... Wouldn't it be really nice if Kazoo routed any number in the same system internally instead of routing it to external carrier?
 

[FASTDEVICE]

I believe @mc_ is alluding that it can be done, but the number must have an internal DID that can be tracked. However, I don't know what the attribute "track" means.

[tomas_]

Yes but I thought about it besides your question of bridging with Pivot.
My thought was that all calls made to an "internal" number should be routed internally and not via external carrier/trunk....

[mc_]

So when a call goes to the "Resources" callflow action, stepswitch (the app) figures out what carrier(s) to send the call to, right? But first it checks that the dialed number is not already existent on the system; if the number is found and it isn't forced offnet, stepswitch will hairpin the call back into the system for processing. So any numbers known to the Kazoo system will stay local unless forced to go out.

So you could define an "internal" prefix of "+abc" and when you create your callflows, you create an "internal-to-kazoo" DID for that callflow as well. Now your Pivot app returns {"module":"resources", "data":{"to_did":"+abc1001"}}. Since you setup Account B's callflow to include "numbers" :["1001", "+abc1001"], and "+abc1001" is in the number database, stepswitch will hairpin the call to Account B.

This is a hack! But if you accept the headache of managing this, it could be a way to accomplish your goal.

caveat emptor

[FASTDEVICE]

I'm on the 2600hz hosted environment, how do I create an internal-to-kazoo DID?

[tomas_]

Wow, that's exactly what I thought about. Thanks for clarify that!
As always - Kazoo is awesome!

[mc_]

@FASTDEVICE this won't be possible since you won't be able to create the "internal" number properly. If you create it on the hosted platform, it gets tagged as a "local" number; as such, it would be forced outbound to the carrier, even though it exists on Account B's callflow. This prevents accounts from stealing numbers that don't belong to them and receiving calls for those numbers.

Is there a reason why account B's callflow can't have a proper DID that account A can call? As mentioned previously, that DID will not go to the carrier if it has been properly purchased and configured.

[FASTDEVICE]

Well, in short, it's a monthly cost to procure a DID and I need to bridge accounts. I don't need BLF, just the same functionality if it were a DID bridging the account. 

[tomas_]

On 3/16/2018 at 9:53 PM, mc_ said:

So when a call goes to the "Resources" callflow action, stepswitch (the app) figures out what carrier(s) to send the call to, right? But first it checks that the dialed number is not already existent on the system; if the number is found and it isn't forced offnet, stepswitch will hairpin the call back into the system for processing. So any numbers known to the Kazoo system will stay local unless forced to go out.

So you could define an "internal" prefix of "+abc" and when you create your callflows, you create an "internal-to-kazoo" DID for that callflow as well. Now your Pivot app returns {"module":"resources", "data":{"to_did":"+abc1001"}}. Since you setup Account B's callflow to include "numbers" :["1001", "+abc1001"], and "+abc1001" is in the number database, stepswitch will hairpin the call to Account B.

This is a hack! But if you accept the headache of managing this, it could be a way to accomplish your goal.

caveat emptor

Bumped into this now. How to restrict numbers not to force calls offnet?
In our self hosted installation all calls to our DID's seems to be connected to the carrier, and not routed internally.
Is it some setting in each number, or somewhere else?

Br Tomas

[fmateo05]

You can set up the carrier module on the number  to  "other" and it will disable the force_outbound and route calls on-net

 

Edited March 23, 2022 by fmateo05 (see edit history)

[tomas_]

Thanks, but I'm already using "Other" as carrier module on all numbers.

[fmateo05]

I dont think so. on my kazoo install i have also Other and it works by dialing any on-net number.  Try the global carrier setting on the account and dial again

[tomas_]

Oh, just forgot to mention that I'm using a Pivot script to execute calls in the no_match callflow, instead of carrier module...
The pivot script is sending the "resources" module and "to_did" as data. Guess "use_local_resources" should be false. Seems like it's working but I need more testing...

[fmateo05]

hmm... Ok

[mc_]

use_local_resources:true will check the account for carrier docs; use only if the account itself has carriers defined.

DIDs on the system are forced outbound by either carrier module = knm_local OR "force_outbound" set to true (I think just those two).

Try `sup stepswitch process_number {DID}` and see if the output includes forcing the DID offnet. If using local resources, I think you can add the account ID as an argument after {DID}.

[tomas_]

Thanks!
Yes, it seems to work if i set use_local_resources to false, then Kazoo seems to route the call internally and not through the carriers.

I tried the sup command, and it's actually sup stepswitch_maintenance process_number ;)
Thanks anyway, really useful!