<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri">Hi,</font><br>
<br>
<div class="moz-cite-prefix">Le 12/09/2016 à 07:22, Richard Bateman
a écrit :<br>
</div>
<blockquote
cite="mid:C6D83B65-08C5-49EF-BB4F-6E7A2DA0AEE5@batemansr.us"
type="cite">
<pre wrap="">Anyway, I'd really like to have some easy way for everyone to be able to tell which repeater the transmission came in on; with the RC-210 my plan was to have a different courtesy tone depending on the source. e.g. 2m repeater originating transmissions would have CT1, 440 CT2, 220 CT3.</pre>
</blockquote>
<br>
You can't. At least, I didn't find how to do that ;-) <br>
<br>
I just managed to get two separate CTs :<br>
- One CT for the users coming from the "radio" (those who are
received on the radio directly attached to the node)<br>
- Another CT for the users coming from the "link" (any other user,
connected to any other node elsewhere, and coming through an IAX2
connection)<br>
<br>
There are also other drawbacks with CTs : no CT at all for VoIP
users (IAX/SIP), and no differentiation also for Echolink users<br>
<br>
<blockquote type="cite">
<pre wrap="">So, my question is this: is it possible to trigger a macro or function or something that I could use to run arbitrary code every time a transmission started which would know which node that transmission came from? Then I could set the CT based on which node is originating the transmission each time.</pre>
</blockquote>
<br>
I've got such a "work in progress" : a daemon that opens a shell on
Asterisk (asterisk -r), switches to "debug" mode, parses the output
to gather information, and can send instructions. All that is driven
by a Python controller (where I'll implement my specific needs :
take the appropriate action when conditions are met). A tiny WEB
interface allows for basic remote monitoring and control. <br>
<br>
But that's still in an early stage (ie, nothing usable). I'll post
it there as soon as it becomes usable in other situations than mine.<br>
<br>
But I'm not sure I'll be able to change CTs according to the
"origin" of the audio flow...<br>
<br>
<blockquote type="cite">
<pre wrap="">I'm a developer with C experience and some background in asterisk so I'm willing to do some work in the app_rpt.c code as well if needed, but I've found diving in without asking first often means solving the problem in a non-ideal way =]</pre>
</blockquote>
<br>
I don't understand C, I never enjoyed it, thus I never managed to
learn it, HI :-) I already had a look at the source of app_rpt, but
that's far out of my skills. That's why I choosed to write a
"companion" software in Python, to be able to write some kind of
"macros" at an upper layer. <br>
<br>
But if you have the skills to dive into the source, I think it would
be a great idea. There are lots of things that may benefit from new
developments/enhancements.<br>
<br>
73 de TK1BI<br>
<br>
</body>
</html>