Applying Carrier / Gateway Resources

[AzorianMatt]

So forgive me if this turns out to be a very obvious question to many of you but I've only been working with the platform for a couple days. I did manage to build my own cluster in that time so I'm quickly learning the structure of the platform. With that being said, I've had to piece many things together from the outdated documentation (which I understand, not complaining). Unfortunately what I have not been able to piece together is how to properly apply resources in a "resources" database that I've created in the CouchDB server. I have read that resource selectors are the replacement for the old Offnet implementation. I however get a 404 from the API server when trying to access the /v2/resource_selectors API resource. I noticed that when the databases was initially deployed, a database called "offnet" was created which makes me wonder if my installation isn't still using that. I'm running the 4.3 release if this helps at all.

I have inbound calling working decently but I am struggling with the outbound stuff.  For the record, I may be missing some key database concepts since I'm not experienced with CouchDB at all. My background is primarily on MySQL, MSSQL, and NoSQL. I get the impression that Couch differs slightly from the typical document storage server but this may be my temporary ignorance on the matter.

Thank you in advance to anyone that can and will help!

Edited September 26, 2021 by AzorianMatt (see edit history)

[Irfan]

If your issue is pointing outbound call to your carrierrs. Here's my suggestion.

Instead of using API or DB directly, ill recommend you to using monster-ui. There a opensource version from commnity contribution to manage resources/carrier here https://github.com/baloeng/monster-ui-resources

 

From those app you can add global carrier or resource account level to your provider.

Once your create global carrier, offnet callflow with "no_match " numbers will be here. If dont, create manually for outbound like below.

[AzorianMatt]

Well that was very helpful! That gets me a bit closer to the goal of a successful outbound call but I'm still struggling. So this app helped me understand what I was misunderstanding about the database structure and placement of the data therein but I'm still having issues. It appears that it's not using the resource info properly because if I do supply a username/password for the gateway, it doesn't seem to register to my upstream carrier. If I leave out the username and password and instead configure a dialing prefix which my upstream carrier supports as an alternative to SIP registration, it still doesn't work but I can see the prefix being applied on the outgoing call. It just doesn't appear quite correctly since it uses e164.

Any suggestions?

Well scratch that. I had something slightly wrong I suppose. Looks like that got it working! Thank you so much!

[mc_]

Resources do not register to upstream carriers, as this would break the resiliency of the platform for that carrier. Most carriers allow you to specify a list of IP addresses to deliver calls to (should be your Kamailio IPs). If the carrier you are using requires registration, there are some old old instructions floating around to setup a FreeSWITCH config to force the registration to proxy through one of your Kamailio servers. Or you can setup a vanilla Kamailio to register to the carrier and setup your vanilla Kamailio as a "resource" in KAZOO.

You'll find the "resources" API here: https://docs.2600hz.com/dev/applications/crossbar/doc/resources/

Suggestion that you don't manipulate the CouchDB databases directly; the API server code (Crossbar) does a lot of things in addition to accepting API requests and putting them into the database. The handful of things that do require db access are typically one-offs, set it and forget it type things.

And welcome! We're always open to improved docs if you have suggestions and PRs! Let me know when you want to start learning Erlang too ;)

Oh, and if an API doesn't seem to work, make sure it is running on the API servers: `sup crossbar_maintenance start_module cb_resource_selectors` for instance. Just prepend "cb_" to the API endpoint's name for the Erlang module to initialize. This should add it to the list of modules to start as well.

[AzorianMatt]

The abstraction on resources not supporting upstream auth makes sense so I get that which isn't a problem. My primary carrier and likely others to follow all support adding prefixes to the route in order to provide authentication in combination with IPv4 ACLs.

The problem with the crossbar app is I don't understand it very well and I'm not finding a lot of good documentation. I have been scanning the repository base to understand it better but without knowing Erlang, it remains pretty unhelpful.

If you all help me get through this difficult learning period, I will certainly give real consideration to adopting Erlang into my tool belt. That will only help me better support my own goals with this project certainly but it's difficult right now because Erlang does not have a lot of similarities seemingly between all the languages I'm already fluent or at least descent in. (PHP, Node/JavaScript/ECMAScript, Java, C#.Net)

With that being said, it was late while I was testing our the recommendation so while I managed to make 1 single outgoing call work, I lost it as quick as I had it. I'm having trouble finding modern references to how the dial plans are actually managed and stored. I could use some assistance in figuring out the last remaining pieces missing to make this a basic 2-way calling system. I'm familiar with most of the logging locations and I get plenty of info out of the freeswitch logs if you want me to pull something to assist. It appears as though I'm being SIP auth challenged when I send a call outbound. This shouldn't be happening I wouldn't think so any info is helpful. I have references to using the "dialplans" and "dial_plan" key of a given account record but those don't seem to have the proper impact on the flow of a call. If you wouldn't mind taking a look, I dumped everything from the freeswitch log that had a matching call id of both call legs and attached them in text files. The inbound log dump represents the initiating call from an internal SIP registered device and the outbound log represents the cluster's outward call that was initiated by the SIP device. I have replaced all sensitive information with placeholder data that matches across both sets of logs for easy reference.
 

inbound-call-log-dump.txt outbound-call-log-dump.txt

Edited September 27, 2021 by AzorianMatt (see edit history)

[AzorianMatt]

For the record, I am learning a bit about the storage of the dial plans now after having referenced this document: https://docs.2600hz.com/dev/doc/internationalization/numbers.

I am however running into more troubles with the documented information resulting in failures. For example, I've ran the command to load the dialplans module for crossbar and that seemed to be fine. However, when following the instructions to flush the CouchDB caches, I get the generic invalid number of arguments error for all three scenarios of no account id supplied, account id supplied, and account and document id supplied. I'm referencing the code base for what would the appropriate commands (if any) but again, everything is still a bit cryptic until that "click" moment when I finally pick up on the syntax.

[mc_]

404 on your link so just in case: https://docs.2600hz.com/dev/doc/internationalization/numbers/

I think your sentence-ending period got linked as well, throwing off the URL.

If you have used FreeSWITCH before, KAZOO doesn't use the dialplan XML - every call is handled in real-time by KAZOO. The primary call processing app is named 'Callflows'.

From an API perspective: https://docs.2600hz.com/sysadmin/doc/install/configure_kazoo/

You should get a device, number, callflow, and resource setup and make calls using that.

If there are specific parts of the docs that don't work for you, you can use the Edit (pencil icon) which should bring you to the github repo that backs these doc sites if you have suggestions. If a command fails, please include the command tried and the output; we can help see if the docs are wrong or your invocation.

[AzorianMatt]

I will gladly contribute back to the documentation (where I won't be more harmful than helpful) and especially contribute deployment guides if all works out.

Alright, so I have managed to get outbound partially functional at least. If I redirect an inbound PTSN call back out to the PTSN (such as forwarding the call back to my phone that I'm calling from) then I can get it to work. I'm having issues with my SIP device calling but now that I can see how to view debug info on the Kazoo core itself, I suspect I'll be able to discover more about that problem.

Edited September 28, 2021 by AzorianMatt (see edit history)

[AzorianMatt]

I am however confused by your response about dial plans. I realize that Kazoo is processing calls in real-time but when an outgoing call is made, you still need a dial plan somewhere to determine internal vs external, local vs national calls do you not? Is this not what the "dialplans" document of the system_config database is for as well as the "dial_plan" key of a specific account, user, and device? Am I misunderstanding the documentation?

[mc_]

In KAZOO, a "dialplan" allows configuring ways to adjust the dialed number. For instance, in the US of A, you could dial a local number without the area code; with dialplans, KAZOO can adjust that 7-digit dialed number to the full 10-digit (or full E164) version before Callflows processes it. But dialplans are not a "typical" feature folks tend to use.

[AzorianMatt]

I suppose that response further confuses me then because take that very simple and common scenario of 7 digit dialing. What part of the system does the typical customer configure to achieve that same outcome? Would the dialplans feature not be used for this or is there a different facility built-in to the Callflow app for this? I suppose I don't understand how many don't use this on a regular deployment.

Side question, does anything obvious come to mind on a scenario where in inbound call from the PTSN will properly forward back out of my carrier to another Offnet number ONLY when I set it to retain the inbound call's caller id data? The moment I change that, the outbound forward fails and I suspect it's for this same reason that my internal outbound calls fail no matter what. I'm still working on understanding some of the log messages so I'm sure the answer is there, I just don't know how to read it yet.

[mc_]

Yeah, there are a number of ways to do it. Most use the e164 converters; see https://docs.2600hz.com/dev/doc/internationalization/numbers/#converters

[AzorianMatt]

I noticed that feature when scanning that page yesterday. What I haven't found when searching is a reference on how to implement that converter configuration at account, user, and device level which I assume it can be given the nature of many other features.

Thankfully I have everything else working at this point which is a relief. It's been an intense 5 days learning the basics of this platform. May arguably be overkill for my target application but it is free and on my own infrastructure and that's what matters here. =D

[bpbp]

On 9/27/2021 at 5:16 PM, Irfan said:

Slightly off-topic, why does your callflow style different from the default 4.3? Custom CSS or are you using the master branch of monster-ui?

Edited September 30, 2021 by bpbp
spelling :) (see edit history)

[AzorianMatt]

I'd say that's 100% off-topic so start a new topic instead of digressing here. It will aid in the future searches of others. :-)

Edited September 30, 2021 by AzorianMatt (see edit history)