Jump to content
KAZOOcon: hackathon signup and details here! ×

Bridge calls between accounts using Pivot


FASTDEVICE

Recommended Posts

  • 2600Hz Employees

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....

Link to comment
Share on other sites

  • 2600Hz Employees

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

Link to comment
Share on other sites

  • 2600Hz Employees

@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.

Link to comment
Share on other sites

  • 4 years later...
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

Link to comment
Share on other sites

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...

bild.png.e0704222da96fa309f0ba481e3b8d2d5.png

Link to comment
Share on other sites

  • 2600Hz Employees

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}.

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

×
×
  • Create New...