[Asterisk-doc] preliminary notes/docs for quicknet hardware

[Leif Madsen]

> -----Original Message-----
> From: asterisk-doc-admin@lists.digium.com [mailto:asterisk-doc-
> admin@lists.digium.com] On Behalf Of Scott Edwards
> Sent: Thursday, May 27, 2004 9:49 PM
> To: asterisk-doc@lists.digium.com
> Subject: [Asterisk-doc] preliminary notes/docs for quicknet hardware
> 
> > My target audiance is from the asterisk-doc's itself.
> > Enjoy. (needs proofing etc...)
> 
> This set of documentation is prepared in part, by Scott Edwards.
> 
> If at any time you feel this documentation is insufficent, or lacking in
> some area, you are free to update us.  Remarks about "there's nothing
> here"
> will go unanswered because we'd rather spend time writing it.
> 
> I've spent countless hours to get the ixj driver working with the Quicknet
> Internet Phone Jack.  I only have the ISA version at this time.
> 
> The summary for getting this card to work with asterisk is as follows:
> 
> First, the card must work with the telephony API layer for the Linux
> kernel.
> Without this level of support, you still have hardware or driver issues.
> (again, that's not an asterisk problem!)  I'm using Debian, and may have
> done some things the 'Debian' way.
> 
> First, let's start with the bad news.  The 2.4.26 kernel.org ixj driver
> does
> not appear to work.  (feel free to correct me, with some documentation to
> back it up if I'm wrong)
> 
> This will result in syslog entries like:
> May 22 18:44:03 bell kernel: preparing failed -16
> 
> Also, asterisk will throw these errors: (with the correct phone.conf)
> [chan_phone.so] => (Linux Telephony API Support)
> WARNING[1024]: File chan_phone.c, Line 907 (mkif): Unable to open
> '/dev/phone0'
> ERROR[1024]: File chan_phone.c, Line 1040 (load_module): Unable to
> register
> channel '/dev/phone0'
> WARNING[1024]: File loader.c, Line 269 (ast_load_resource): chan_phone.so:
> load_module failed, returning -1
> WARNING[1024]: File loader.c, Line 363 (load_modules): Loading module
> chan_phone.so failed!
> 
> Lets compare procinfo stats on the ixj node from different versions:
> 
> kernel.org ixj driver:
> bell:~# cat /proc/ixj
> $Id: ixj.c,v 4.7 2001/08/13 06:19:33 craigs Exp $
> $Id: ixj.h,v 4.1 2001/08/04 14:49:27 craigs Exp $
> $Id: ixjuser.h,v 4.1 2001/08/05 00:17:37 craigs Exp $
> Driver version 1.0.1
> sizeof IXJ struct 21156 bytes
> sizeof DAA struct 642 bytes
> Using old telephony API
> Debug Level 0
> bell:~#
> 
> Notice how there is only 8 lines?  There should be more. (many more if you
> have multiple cards)  I was able to prove there was a big issue, after
> taking the card from the machine, and trying to replicate it.  Yes, this
> (possibly both) ixj driver will appear to load if the card is not present.
> The results above are identical with and without the card using the
> kernel.org ixj driver. (pay close attention to the cvs version, date, and
> commiter here soon)
> 
> Before you rush off and grab the CVS release from www.openh323.org, lets
> make sure you have the prerequisites for compiling this driver (this now
> being openh323 relase).
> 
> Compile a kernel with:
> 
> isapnp support as a module
> versioned kernel module symbols (required for modversions.h to be created)
> telephony support (I always used it as a module)
> NO support for ANY ixj (because it's kernel.org, and it will possibly
> conflict with the openh323.org CVS release)
> 
> Also, I decided to rename my /etc/isapnp.conf out of the way prior to the
> following steps.
> 
> Make, install and boot the kernel as usual. Prefibly (lazy sp) off the
> machine you are going to use it on.  Use uname -a to confirm you're
> running
> the new kernel.
> 
> On Debian, you should check /etc/modutils/ and below for any references to
> ixj.  Ignore aliases, as they are ok.  Also, if you're running Debian,
> check
> with these docs when the next steps says 'run modprobe ixj' on the command
> line.
> 
> Now you'll want to grab the CVS driver from www.openh323.org at
> http://www.openh323.org/driver/cvs.html
> 
> Debian users may run update-modutils BEFORE modprobe ixj.
> 
> Hopefully, after following their guide, you've just ran modprobe ixj, and
> you're waiting for more.
> 
> Notice in the next block of /proc/ixj, how the version numbers are
> smaller,
> however a different commiter for ixj.c is present, and the dates are
> actually NEWER then kernel.org. (this is clearly a result of a source
> fork.
> one for kernel.org, and the other for openh323)
> 
> $Id: ixj.c,v 4.19 2002/09/10 09:10:57 rogerh Exp $
> $Id: ixj.h,v 4.2 2001/09/27 04:52:04 craigs Exp $
> $Id: ixjuser.h,v 4.2 2001/08/29 12:55:20 craigs Exp $
> Driver version 1.2.2
> sizeof IXJ struct 21160 bytes
> sizeof DAA struct 642 bytes
> Using old telephony API
> Debug Level 0
> 
> Card Num 0
> DSP Base Address 0x0300
> DSP Type 8020
> DSP Version 01.12
> Serial Number 00a0c0de
> Card Type = Internet PhoneJACK
> Readers 1
> Writers 1
> Capabilities 11
> Caller ID data not sent
> Play CODEC 16 bit Linear
> Record CODEC 16 bit Linear
> AEC Off
> Rec volume 0x100
> Play volume 0x100
> DTMF prescale 0x40
> Hook state 0
> Port POTS
> Base Frame 00.00
> CID Base Frame  0
> Timer Checks 3335470
> RX Ready Checks 4146184
> TX Ready Checks 3869362
> Frames Read 2243
> Frames Written 894
> Dry Buffer 3283
> Read Waits 0
> Write Waits 3
> Status Waits 8221844
> Status Wait Fails 0
> PControl Waits 0
> PControl Wait Fails 0
> Is Control Ready Checks 0
> Is Control Ready Check failures 0
> 
> Ok, now we have a nice looking proc status showing the card was found.
> Now it's time for asterisk to take over.  as a quick note, the kernel
> telephony API access is handled in asterisk via phone.conf.  asterisk by
> default won't have it enabled, check the last lines of the conf for more
> info. You can also check the phone.conf entries in this documentation.
> 
> I hope this was helpfull! I will be reinstalling from scratch soon while
> trying these docs to see what else I need to add.  In the meantime, I wish
> you luck!

Thanks Scott.  This seems like a very informative doc.  Have you looked
through the current outline and decided where this may fit in?  I saw that
jsmith mentioned in the IRC channel that we may want to add this to an
appendix?  I personally think this could almost be added to an installation
chapter, but it might be quite lengthy for that (however once it is reworded
down to match the current "feel" of the book (whatever that is right now...)
then it will probably be much shorter (or at least not appear to be so many
lines).

I guess I'm just hesitant to rely on placing everything in the appendices.

Thanks,
Leif Madsen.