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

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

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.

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?

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.

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.

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

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!

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!