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.