<font color='black' size='2' face='arial'>
<div>It has been posted several times here, and it is on the ohnosec site, that app-rpt is based on Asterisk 1.4 and not the latest release of Asterisk(1.8).<br>
<div style="FONT-FAMILY: arial,helvetica; COLOR: black; FONT-SIZE: 10pt">-----Original Message-----<br>
From: Shane Morris <firstname.lastname@example.org><br>
To: Matthew Pitts <email@example.com><br>
Cc: app_rpt mailing list <firstname.lastname@example.org><br>
Sent: Mon, Dec 3, 2012 1:07 pm<br>
Subject: Re: [App_rpt-users] Some information, from my brain...<br>
<div style="BACKGROUND-COLOR: #fff; MARGIN: 0px; FONT-FAMILY: Tahoma, Verdana, Arial, Sans-Serif; COLOR: #000; FONT-SIZE: 12px" id=AOLMsgPart_0_2cb37584-c072-4c74-9856-6029688829cd><PRE style="FONT-SIZE: 9pt"><TT>Hi Matthew,
It appears that support for app_rpt was dropped in the mainline from
the SVN version on onnosec, and the present <FONT size=2>version</FONT>. I know what
you're thinking - I thought it too, compile up the latest sources,
and... it don't work. Working with that, I attempted to compile the
version of Asterisk on the SVN, with the app_rpt and chan_voter
modules - and ran into these issues.
I could be wrong, but I am pretty certain the latest Asterisk doesn't
support app_rpt. Ergo, I did a "make menuselect" and no option
existed. That was sorely disappointing.
Matthew, I hope I'm wrong...! =)
On Tue, Dec 4, 2012 at 3:44 AM, Matthew Pitts <<A href="mailto:email@example.com">firstname.lastname@example.org</A>> wrote:
> I will have to double check, but I could swear I saw Asterisk listed as one of
the available packages for Raspian Linux on the Raspberry Pi; if that is indeed
the case, I would.think it would be possible to figure out what they did and
code something that will enable the use of APP_RPT on the Pi.
> Matthew Pitts
> Sent from my Verizon Wireless 4G LTE smartphone
> -------- Original Message --------
> Subject: [App_rpt-users] Some information, from my brain...
> From: Shane Morris <<A href="mailto:email@example.com">firstname.lastname@example.org</A>>
> Date: Mon, 03-Dec-2012 05:03
> To: app_rpt mailing list <<A href="mailto:email@example.com">firstname.lastname@example.org</A>>
> I wrote two emails today, one dealing with the subject of the use of
> ARM platforms for app_rpt/ chan_voter software, and one dealing with
> the audio capabilities of modern laptops, particularly Macbook Airs.
> The intent follows:
> So after alot of wrangling, I've found out something:
> DAHDI and Zaptel support on ARM Linux kernels version 3.0 and above
> just doesn't happen. I personally believe this is because most ARM
> systems lack a PCI slot of any description, and pretty much will
> forever lack PCI slots (the last ARM I heard of that had PCI was the
> Ionynx PC from the UK, running RiSC OS - oops?). Now this doesn't give
> Digium an incentive to code up some support for non-existant hardware,
> under the pretense that app_rpt and chan_voter needs tonezone and a
> handful of other elements from Zaptel (or DAHDI), does it? Which means
> you effectively cannot, for the foreseeable future, use an ARM
> platform as the controller for a PMR network.
> That means that, for the first time in five years, I'm considering
> buying an x86 platform. Huh, you say, this is Shane we're talking
> about here, he don't do x86! Unless a certain set of conditions are
> met, no, I don't...
> Meet the Fit PC-3. You might know it, or the Fit PC-2. I admit to
> knowing the Fit PC-2 quite well. A nice piece of gear. What I didn't
> know was they updated to an AMD APU based system, and qualified the
> PC-3 for use with Linux Mint. Uh huh, headless Ubuntu, here I come!
> And this little, fanless, 17Watt total draw bad boy will run all of
> the usual suspects in a PMR network that you may so desire...
> Which is what I desire. ARM can be such a pain in the ass sometimes...
> This system, with 4GB of RAM, no HDD, and postage from Israel (I don't
> think it'll get here before Christmas, but thanks for asking), is the
> princely sum of $485, max, including Paypal "tax." We pay the nobles a
> damn stiff fee for civilisation, don't we? I have a 40GB SSD here,
> just about ready to go. I also have some 12VDC gear, ready for this
> little thing to strut its stuff.
> As I want it to run headless, I'll probably get it to talk SSH
> ("Shhhhhh!") to the outside world, but I do have a 12VDC compatible 15
> inch DVI monitor, with HDMi to DVI cable. Yes, yes, it uses cold
> cathodes... gah, its so hard to get good help these days. I don't
> actually have to have the monitor on for an entire weekend, only when
> things hit fans in interesting, intersecting ways they're not supposed
> to. If that happens, and I can't log into my PMR controller, I think
> the network is pretty much toast by that point.
> I don't believe I'd need a failover, I remember reading something
> along the lines of underclocking will occur until such time as a heat
> issue can resolve itself, the thing, with SSD, has no moving parts (no
> pesky fans to fail!) and as long as you don't hook the power up
> backwards, this thing is pretty much unkillable. Dual core APU at
> 1.0GHz, as mentioned, 4GB RAM, 40GB SSD. Running a nice, recent
> revision of something that can operate in console/ SSH mode. I don't
> want an X server to slow me down. This thing is a PMR controller, not
> a Facebookin' machine.
> So, I've solved all my problems with ARM platforms in one fell swoop.
> This is good you say, I'm finally making progress. Lucky I found out
> with the RPi about the DAHDI/ Zaptel driver situation, and of course,
> the existence of the Radio Thin Client Module as well (thanks Jim! I
> owe you a tall, cold beer one day!). The RTCM is the basis for
> VoterCard, the PMR full transmit simulcast controller for Simoco
> For use of a laptop system with IAXRpt, one finds that most laptops
> audio systems are inadequate, especially in the high noise, and high
> tension area of a command centre. The Macbook Air is further
> disadvantaged by the fact it has no microphone port, simply an inbuilt
> microphone which is prone to picking up alot of noise, and in a
> command situation, broadcasting four operators voices over one channel
> is a recipe for failure, and yes, even danger...
> However after all the work I had invested into getting IAXRpt running
> on my MBA, I felt it appropriate to address what I see as Apples total
> shortcomings in the audio department. Before I go on to explain how I
> addressed these issues, I will elaborate - the running of the Windows
> application IAXRpt under Mac OS X is simple, using a version of WiNE
> for Mac OS X. The particular wrapper software I use is called
> WineBottler. However, I could not use the stock "for OS X 10.6"
> revision software, as it did not support audio in any way, shape or
> form. I actually had to download WineBottler, with 10.6 core, and
> replace the core with 10.7 audio enabled core. As far as I know, the
> 10.7 core WILL NOT run on anything less than 10.7. Of course, I don't
> have anything to try now, do I?
> So, a quick look on eBay located a USB sound card, with advertised Mac
> OS X capabilities - have you ever tried putting a Winmodem into a Mac
> G4? =P This was mine for under the $5 mark. Similarly, another quick
> search turned up a headset appropriate for the USB sound card with
> singular headphone and boom mic, as well as separate plugs for the
> audio paths. Compatibility was assured - but I just had to TEST it!
> Today I got the sound card after about a month of waiting. After
> inserting the USB card, I looked through the sound settings - "Generic
> USB Sound Device" came up, and the connection type was "USB" (versus
> "Built In"). After setting the appropriate settings, I took a deep
> breath, and started "Above the Storm" by Alpine Fault in iTunes...
> I was listening to those strums, explained to me as being similar to
> those of Nightwish, through my headphone! Noise and auditory
> interference would now be minimised. But what about sending audio?
> Would the mic work too?
> Opening GarageBand, I quickly selected "Voice" and made a recording.
> My nasally voice popped out of the headphone. I was satisfied that the
> Mac would work. Now the real test: would WiNE (and thus, IAXRpt) work?
> I am unable to test sending audio, although the error tone came out
> loud and clear from IAXRpt. It appeared I wouldn't have to change any
> settings on the IAXRpt (Windows) side like I was expecting - it must
> be transparent to the Windows software where the audio is actually
> COMING from or GOING to... gotta love that old Mac reliability to just
> bloody well work...!
> Hopefully this helps anyone in my position, and updates you all on the
> progress of the RPi project. It is a little unfortunate, but I have
> found out alot along the way - Jim, I do owe you that beer for
> pointing out the RTCM to me. And if you have any news concerning the
> status of the ARM drivers, I'm all ears...
> App_rpt-users mailing list
> <A href="mailto:App_rptemail@example.com">App_rptfirstname.lastname@example.org</A>
> <A href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target=_blank>http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</A>
App_rpt-users mailing list
<A href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target=_blank>http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</A>
<!-- end of AOLMsgPart_0_2cb37584-c072-4c74-9856-6029688829cd --></div>