I have no idea... Sounds like an app_rpt question to me. Please take your question over there.
There is NO SUPPORT for the experimental stuff at all. If it works, great. If it does not, Sorry you will have to fix it yourself. It is just an environment file flag and a couple of scripts. Should easy for the average programmer to figure out.
One other thing users should keep in mind?... all security for these connections is turned off. No key exchange, anyone can connect. Even your grandmother running speak freely on her laptop. No assumption the folks are even Hams. If this bothers you do NOT set the environment flag. You have been warned, heheh.
On Feb 1, 2009, at 21:19, Eric Fort wrote:
why add decode to app_rpt? This and many other functions in app_rpt
seem not to belong there but seem they ought to be done in asterisk
proper and acted upon via the dialplan. Unless I misunderstand
something it would seem proper to leave DTMF unmuted and process the
DTMF using Asterisk.
On Sun, Feb 1, 2009 at 6:02 PM, Randy Hammock <rhammock@...> wrote:
On Feb 1, 2009, at 5:42 PM, Tony Langdon, VK3JED wrote:
Oh well. Guess I'll have to talk to Jim about adding DTMF decode
5) Whether you want DTMF tones to be muted or not.No TCP, no FIFO ;)
If DTMF tones are muted, will the DTMF data still be available via
FIFO? chan_irlp does not listen for DTMF tones coming in from a
IRLP node (that I'm aware of), it uses the back channel like a normal
capability to the incoming IRLP audio stream so that connecting IRLP
nodes can make Asterisk calls if they so desire (if it does not do
that already). After all, a chan_irlp based IRLP node is not much
different than a normal IRLP node that is connected to a repeater
control except that the app_rpt "repeater controller" has virtually
an infinite number of ports to which it can cross-connect.
Randy Hammock KC6HUR
If there are no horses in heaven, then when I die, I want to go where
--- IRLP-Owners YahooGroups List ---Yahoo! Groups Links
Dave Gingrich, K9DC
Indianapolis, Indiana USA