I disagree. As actual DTMF is not sent and the command is sent to a specific node and only that node is the one that would generate DTMF, why would “a very linked up environment” be an issue?.
Exactly. We already know I am not the only Allstar user using it to link private systems that are not part of the public Allstar network. I really don’t see why having a persistent (and configurable) means of having a node (or nodes) in one’s system generate DTMF.
It’s messy in the sense that the command structure would completely change.
You guys are thinking it terms of standard repeater controllers. That’s understandable. We all do that at first. AllStar isn’t perfect but it works fine. You just have wrap your mind around its unusual approach to some things.
Remember as I said before, you can pass DTMF down links with RTCMs in mixminus mode.
Correction: As @Mike said, DTMF not digitized into the audio stream. It is regenerated from chan_iax messages. Likewise, with RTCMs chan_voter is regenerating DTMF.
Nobody ever claimed it was one size fits all.
It is open source code. You are free to make it what you need to fit your purpose.
The door has left open for anyone to do just that. Nobody is hiding anything.
It is what it is from a standpoint of reliable pubic network communications removing much human error in favor of that reliability.
How? Can you please give examples?
Sending DTMF to every connected node would require a prefix (perhaps the node number) to address the node that is supposed to accept the command. That’s complete change of the command structure in my mind.
Not necessarily and for a couple of reasons I can think of
The linked system made be small (with only 2 or 3 linked repeaters) and sending DTMF to them all simultaneously may not be a big deal. In fact, it could be beneficial depending on configuration
The controller at each repeater site may allow for definition of a site prefix already, hence no need for it within the Allstar command structure
I’m still not tracking here. Sorry. How would that require a change to the command structure? A change as in from *3 or *4 or another command?
Why could or wouldn’t a broadcast work? You already can hear DTMF coming in over links in come cases.
It is the same with most better hardwired controllers. It has been somewhat a standard for any high end controller with remote base/link capability.
That is why the DTMF audio generator capability is built-in. Same as other high end controllers.
For app_rpt you only need to set-up ilink commands to generate dtmf audio output.
A small script could handle complexity with ease.
Personally, I consider this issue solved. But you can always request a re-write or added functionality.
This issue came up many times under ACID and ‘the dude’ would not budge, and understandably so…
Two points here:
“Other high end controllers” do, in some cases, incorporate a DTMF regenerate feature but almost always have the capability of having a predefined command (Prefix) that is prefaced to the DTMF string to be sent. For example, the owner assigns the DTMF digit of “#” for use with DTMF regeneration. So the user only needs enter “#” followed by the digits to be sent and that is that. That is significantly streamlined compared to the Allstar method
Consider the following diagram.
As you can see, there are many different possible DTMF sequences to be sent and scripts alone are not the answer!
The history lesson is appreciated but this kinda isn’t helpful or answers the question.
I agree with @KenHorse that scripts alone are not the answer to this.
Perhaps I will take advantage of this being open sourced code after all…
