Koozali.org: home of the SME Server
Obsolete Releases => SME VoIP (Asterisk, SAIL etc) => Topic started by: SARK devs on June 03, 2007, 01:00:50 PM
-
HI all
OK...
6 new asterisk and two new SAIL rpms have gone up to the mirrors. These cover the three basic flavours we currently support; Regular 1.2 Asterisk, Bristuff/Florz 1.2 Asterisk (for HFC users) and 1.4 Asterisk. The release nuimbers are as follows:-
smeserver-asterisk-1.2.10-8.i686.rpm
smeserver-asterisk-zappri-MPP-1.2.6-6.i686.rpm
anabri-asterisk-florz-1.2.10-8.i686.rpm
anabri-asterisk-zappri-florz-1.2.6-7.i686.rpm
smeserver-asterisk-1.4.1-7.i686.rpm
smeserver-asterisk-zappri-MPP-1.4.0-5.i686.rpm
All can be found on Ibiblio
http://mirror.contribs.org/smeserver/contribs/selintra/RPMS/
All have been given a new "kernel release tolerant" fix. In theory, you shouldn't have to move modules around anymore to support the ever changing CentOS kernel releases. However, we need your help testing this feature so please install on a fresh server or server-image and report back your experiences. You should be able to install, do yum updates etc etc without having to worry about the Asterisk Kernel modules. This is a first out with this feature so YMMV.
There are also 2 new SAIL rpms...
With Asterisk 1.2 (regular or Bristuff) you should run the latest 2.1.14 release
ftp://81.149.154.14/Pre-Releases/selintra-sail-2.1.14-457.noarch.rpm
With Asterisk 1.4 you MUST run the latest 2.1.15 release
selintra-sail-2.1.15-468.noarch.rpm
ftp://81.149.154.14/Pre-Releases/selintra-sail-2.1.15-468.noarch.rpm
Both these releases have some new "mass-deployment" features, the most important of which is central directory and Speeddial for Aastra and Snom phones. You can find details on the Docs site..
http://selintra.com/docs/cgi-bin/view/Main/DocChapterHdrs
This feature allows you to create a freeform directory in headers and have it automatically downloaded to all the phones on your network (provided they are Snoms or Aastras). If you want us to include other phone types then please shout, obviously they MUST support remote directory provisioning (many don't).
2.1.15 ONLY has a full mISDN implementation built by Herve Pendeville. It is very impressive and supports many more card types than Bristuff including Junghanns, Beronet, AVM Fritz and most single HFC based cards. Both single and multi HFC units can be run in either NT and TE mode (or even mixed for the multis) meaning that you can run the system as a Gateway to a legacy ISDN2 based PBX. Pretty damn cool. Herve has done a top rate job with this implementation. 2.1.15 also has had some bug fixes applied and supports mySQL CDR logging again.
From now on, you will see fewer 2.1.14 releases as we run down the 1.2 support and hopefully many more new 2.1.15/1.4 enhancements.
Kind Regards
Selintra
-
selintra
Can't find these files at the location ... did you guys take em back off or is it a sync problem
smeserver-asterisk-1.4.1-7.i686.rpm
smeserver-asterisk-zappri-MPP-1.4.0-5.i686.rpm
Can only find:
smeserver-asterisk-1.4.1-3.i686.rpm
smeserver-asterisk-zappri-MPP-1.4.0-4.i686.rpm
Regards,
Tib
-
Hi Tib,
Looks like something odd. I'll reload and see if that fixes it.
Thanks for letting me know.
Best
S
-
HI again Tib,
I looked on our FTP account and the files appear to be there. However, I've deleted them and now they are reloading so you should have them shortly.
Also there was an error in the announce - the correct 2.1.15 SAIL version is -468 and the correct 2.1.14 version is -457. You can get them at
ftp://81.149.154.14/Pre-Releases/
Best
S
-
Hi Selintra,
I like to use:
smeserver-asterisk-1.4.1-7.i686.rpm
smeserver-asterisk-zappri-MPP-1.4.0-5.i686.rpm
and german language sound-file:
sme-ast-de-de-gpl-sounds-1.0.0-1.noarch.rpm
What config-files must i edit and how to get german sound ?
regards
fpausp
-
Hi
You need to edit each sound channel (zap, sip, iax) that you intend to use. In headers for each one you can add
lang=de
I think that should do it for you.
Kind Regards
Selintra
-
Hello selintra
I can see all the files now .. thanks
Will try them out soon.
Regards,
Tib
-
Hi Selintra,
Thanks your help german-sound is working with "language=de" in Headers (sip.conf, iax.conf, zapata.conf), now i like to get a isdn-card working.
I tested three severel cards in the PCI Cards Section (1 x hfc, 2 x different avm models) with no luck.
Output of PCI Card Scan is:
Loading zaptel...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
Is there anything else to install or configure ?
regards
fpausp
-
Hi
re HFC BRI Card
This is probably because you are using an HFC card which we've not seen before or you are NOT running the ISDN version of asterisk (anabri-asterisk...). Are you running 2.1.14 or 2.1.15?
If you are running 2.1.14 you can find full instructions how to add support for your card here...
http://www.selintra.com/docs/cgi-bin/view/Main/DocChapter258
If you are running 2.1.15 then it will be a few days before we have instructions for you.
Kind Regards
Selintra
-
Hi again,
I installed:
nmap-3.70-1.i386.rpm
perl-Term-ReadKey-2.21-1.1.el3.rf.i386.rpm
selintra-sail-2.1.15-453.noarch.rpm
sme-ast-de-de-gpl-sounds-1.0.0-1.noarch.rpm
smeserver-asterisk-1.4.1-7.i686.rpm
smeserver-asterisk-zappri-MPP-1.4.0-5.i686.rpm
tftp-server-0.39-2.i386.rpm
xinetd-2.3.13-4.4E.1.i386.rpm
with:
rpm -Uvh *.rpm
/sbin/e-smith/signal-event console-save
The hfc-card should work because it does in an previous version of asterisk/selintra.
regards
fpausp
-
Hi
I notice you have installed SAIL-453, which is the one we initially siggested in the announce, however there are some known mISDN related errors in that release. Please try -468 instead.
Best
Selintra
-
will try -468 on evening.
bye !
-
http://mirror.contribs.org/smeserver/contribs/selintra/RPMS/
All have been given a new "kernel release tolerant" fix. In theory, you shouldn't have to move modules around anymore to support the ever changing CentOS kernel releases. However, we need your help testing this feature so please install on a fresh server or server-image and report back your experiences. You should be able to install, do yum updates etc etc without having to worry about the Asterisk Kernel modules. This is a first out with this feature so YMMV.
Hi Selintra, how is this supposed to work? The kernel modules are now in /etc/selintra/up, and asterisk won't find them in my case. So I again copied them to /lib/modules/2.6.9-42.0.10.EL
-
how is this supposed to work?
It is not only in UP, there is also a version in SMP. It works by copying the modules to /lib/{uname -r}/extras in the startup daemon (if they aren't present).
Did you try starting asterisk with
/etc/init.d/asterisk start
?
Best
S
-
Hi again,
yes, I started with /etc/init.d/asterisk start, but nothing was copied. Where is the copy-command defined? I can't find it in /etc/init.d/asterisk
BTW: I use anabri-asterisk-florz-1.2.10-8.i686.rpm and anabri-asterisk-zappri-florz-1.2.6-7.i686.rpm. There only UP exists.
So I just had a look at the NON-ISDN-Version of init.d/asterisk. There the copy-command exists, but not in the ISDN-Version.
-
Hi KB
Thanks for this. You spotted a bug. I've just looked back through the asterisk package server history and I found an error in the -8 packaging.
I've put up a -9 version which I would very much like you to test. I can't load it to ibiblio from here so I've opened up a temporary ftp server for you. You should be able to get -9 with....
wget ftp://selintra.com/anabri-asterisk-florz-1.2.10-9.i686.rpm
Kind regards and thanks
Selintra
-
Hi Selintra,
I can't find the new file on that ftp so far.
Manuel
-
Try now
:-)
-
Now it works. I tried deleting the modules in 2.6.9-42.0.10.EL and they are copied there again when asterisk restarts.
Thanks
Manuel
-
Excellent
Thanks for your help KB. I'll load -9 to ibiblio this morning.
Best
Selintra
-
Hello Selintra,
As always, my compliments :D
I've run into a small stumbling block and was wondering if I could get your help. Version 2.1.15-468 runs flawlessly on SIP channels but I keep getting a failure when dialing into the ZAP channel:
== Parsing '/etc/asterisk/asterisk.conf': Found
== Parsing '/etc/asterisk/extconfig.conf': Found
Connected to Asterisk 1.4.1 currently running on garthog (pid = 4407)
Verbosity is at least 5
-- Remote UNIX connection
-- Starting simple switch on 'Zap/1-1'
[Jun 9 09:15:48] NOTICE[4563]: chan_zap.c:6327 ss_thread: Got event 18 (Ring Begin)...
[Jun 9 09:15:48] NOTICE[4563]: chan_zap.c:6327 ss_thread: Got event 2 (Ring/Answered)...
-- Executing [s@mainmenu:1] GotoIf("Zap/1-1", "1?s-Zap1-1|1") in new stack
-- Goto (mainmenu,s-Zap1-1,1)
-- Sent into invalid extension 's-Zap1-1' in context 'mainmenu' on Zap/1-1
-- Executing [i@mainmenu:1] BackGround("Zap/1-1", "invalid") in new stack
-- <Zap/1-1> Playing 'invalid' (language 'en')
== CDR updated on Zap/1-1
-- Executing [0@mainmenu:1] Goto("Zap/1-1", "5000|1") in new stack
-- Goto (mainmenu,5000,1)
-- Executing [5000@mainmenu:1] AGI("Zap/1-1", "selintra|InCall|") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
-- AGI Script Executing Application: (Dial) Options: (SIP/5000|15|tTwW)
-- Called 5000
-- SIP/5000-0998fc60 is ringing
-- Got SIP response 480 "Temporarily Unavailable" back from 192.168.0.100
-- SIP/5000-0998fc60 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
-- AGI Script Executing Application: (Background) Options: (silence/1)
-- <Zap/1-1> Playing 'silence/1' (language 'en')
-- AGI Script Executing Application: (Voicemail) Options: (u5000)
-- <Zap/1-1> Playing 'vm-theperson' (language 'en')
-- <Zap/1-1> Playing 'digits/5' (language 'en')
-- <Zap/1-1> Playing 'digits/0' (language 'en')
-- <Zap/1-1> Playing 'digits/0' (language 'en')
-- <Zap/1-1> Playing 'digits/0' (language 'en')
-- <Zap/1-1> Playing 'vm-isunavail' (language 'en')
-- <Zap/1-1> Playing 'vm-intro' (language 'en')
-- <Zap/1-1> Playing 'beep' (language 'en')
-- Recording the message
-- x=0, open writing: /var/spool/asterisk/voicemail/default/5000/tmp/Mx9Zg4 format: wav49, 0x9904ff0
-- User hung up
-- Recording was 5 seconds long but needs to be at least 8 - abandoning
== Spawn extension (mainmenu, 5000, 1) exited non-zero on 'Zap/1-1'
-- Executing [h@mainmenu:1] Hangup("Zap/1-1", "") in new stack
== Spawn extension (mainmenu, h, 1) exited non-zero on 'Zap/1-1'
-- Hungup 'Zap/1-1'
As you can see, I get the dreaded "That option is invalid" on inbound ZAP channel calls but ZAP does in fact work. The PBX allows me to dial out normally and when I press "0" during the inbound error message, it will in fact ring the phone and operate normally.
Kernel version is 2.6.9-42.0.10.EL and it's on a completely clean install.
Thank you,
R
-
Hi R
You've got us beat with this one. It's failing in the oldest part of the SAIL code. That GoToIF cascade is just about the only surviving code from SAIL V1, so it's pretty well tested code!
Can we see the "mainmenu" context? You can display it in the general edit panel.
It almost looks as though part of the context has been removed/stomped.
Kind Regards
S
-
Of course!
/etc/asterisk/extensions.conf
[mainmenu]
include => extensions
exten =>
s-Zap1-1,1,agi(selintra,Inbound,Zap1-1)
exten => s,1,GotoIf($["${CHANNEL}" = "Zap/1-1"]?s-Zap1-1,1)
exten => s,2,agi(selintra,CheckState,)
exten => fax,1,GoToIf($["$FAX" = ""]?3:2) ;no FAX defined - hangup
exten => fax,2,GoTo(extensions,${FAX},1)
exten => fax,3,Congestion
exten => fax,4,Hangup
exten => t,1,GotoIf($["${OPEN}" = "YES"]?t,4)
exten => t,2,Voicemail(su${SYSOP})
exten => t,3,Hangup
exten => t,4,Goto(extensions,${SYSOP},1)
exten => t,5,Hangup
exten => h,1,Hangup
exten => i,1,Background(invalid) ;
exten => i,2,Hangup
/etc/asterisk/zapata.conf
[channels]
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
relaxdtmf=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
faxdetect=incoming
context=mainmenu
signalling=fxs_ks
group=2
channel=1
Thank you,
R
-
Hi R,
We have a fix for you. You will find a -470 release on the SAIL download site...
ftp://81.149.154.14/Pre-Releases/selintra-sail-2.1.15-470.noarch.rpm
This will sort out your incoming ZAPline issue.
Kind Regards
S
-
Hi all,
I've got the following installed:
[root@master sail]# uname -r
2.6.9-42.0.3.EL
[root@master sail]# rpm -q selintra-sail
selintra-sail-2.1.15-468
[root@master sail]# rpm -q smeserver-asterisk
smeserver-asterisk-1.4.1-7
[root@master sail]# rpm -q smeserver-asterisk-zappri-MPP
smeserver-asterisk-zappri-MPP-1.4.0-5
[root@master sail]#
and a X100P card. When I try to probe for the card, I get the following:
Loading zaptel...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
I'm I missing something?
Thanks
L2
-
Hello L2,
What does modprobe zaptel report? Anything at all, or does it silently load? I found a similar problem with 1.4.0-5.i686 and the ELSmp kernel but not the EL.
Thanks Selintra :)
Great! BTW, the update on the FTP site is zero bytes long. Could you send it over to the FTP again? Thank you,
-
modprobe zaptel happily and quitely loads...
I've tried with both the EL and ELsmp.... At first I thought it was the smp kernel, but the up generated the same results..
-
Ooops... I lied.
When running the SMP kernel...
modprobe zaptel
FATAL: Error inserting zaptel (/lib/modules/2.6.9-42.0.3.ELsmp/extra/zaptel.ko): Invalid module format
and the probe times out on UDEV.
So, to recap..
On the EL kernel, modprobe loads the module, but SAIL doesn't see the card.
On the SMP kernel, the module doesn't load... From what I've been reading, this seems to indicate that the module was compiled with a different kernel.
I'm new to this, so my interpretations may be wrong.
Anyhoo, If anybody can enlighten me, that would be most apprecieated. I've got SAIL 2.1.15-443 running on another box (VoIP only ) and I'm very happy with it...
Thanks again Selintra.
L2
-
FATAL: Error inserting zaptel (/lib/modules/2.6.9-42.0.3.ELsmp/extra/zaptel.ko): Invalid module format
Yep, I'm getting the same (except mine was 2.6.9-42.0.10.ELsmp). Couldn't get my TDM400 running with the smp modules. In fact I had to drop back to sail-453 with a UP kernel, smeserver-asterisk-1.4.1-3 and smeserver-asterisk-zappri-MPP-1.4.0-4. I also noticed the -470 release on the ftp site was 0 bytes.
I also noticed this in dmesg if it means anything:
zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
zaptel: disagrees about version of symbol struct_module
Lloyd
-
Hi Guys,
We hit the same problem ourselves last night and had to back a system off to 42.0.3. I think we may have overstretched the "just move the modules" theory. (42.0.3 should be fine tho' so I'm not sure about Llandry's issue).
We'll give it a proper look over the next few days but this is just to confirm that we too have hit problems with .10. Probably just need a recompile from sources but watch this space.
Best
S
-
Hello Selintra,
The Zaptel / Kernel issue has been a problem for a long time. :? SME Server isn't a dev platform (and rightfully so) but perhaps building an install script for Asterisk / Zaptel might be an option instead of maintaining RPM's?
I know... I know... this is a crude example and pardon my lack of knowledge on the SME Server platform; but bear with me.
Temporarily install the packages needed to compile Asterisk and Zap:
yum –y update
yum --enablerepo=* install gcc gcc-c++ kernel-devel kernel-smp-devel bison ncurses-devel audiofile-devel subversion libogg-devel tftp-server ntp doxygen
signal-event post-upgrade; signal-event reboot
ln -s /usr/src/kernels/2.6.9-55.plus.c4-smp-i686 /usr/src/linux-2.6
ln -s /usr/src/kernels/2.6.9-55.plus.c4-smp-i686 /usr/src/linux
cd /usr/src
svn checkout http://svn.digium.com/svn/asterisk/trunk asterisk
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
svn checkout http://svn.digium.com/svn/libpri/trunk libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/trunk asterisk-addons
cd /usr/src/zaptel
./configure; make menuselect
# "X" out
make clean; make linux26; make install
cd /usr/src/libpri
make install
cd /usr/src/asterisk
./configure
make install
make progdocs
make config
Load everything up properly then CLEAN UP!!!
yum remove gcc gcc-c++ kernel-devel kernel-smp-devel ncurses-devel audiofile-devel doxygen
Just a thought,
R
-
Hi R
Just a thought
...and a good one. We've discussed this many times. As you may know, A@H/Trixbox/ whatever it's called nowadays, installs asterisk in the way you describe and it has some advantages from a kernel-release point of view but, of course, once its in, they have the same problem to keep up with the Kernel releases that we have. The great beauty of rpm is that it can be regressed if you get it wrong and this is incredibly important for our paying customers. They won't allow us to take their phones away from them while we rebuild the system if we get a release wrong. With rpm, we can be back to the previous release in less than a couple of minutes if we screw up (and we do screw up - :-) ).
In truth, we only maintain asterisk to maintain SARK/SAIL, it's a job we would rather not have to do...
SARK/SAIL, doesn't much care which asterisk release it's running against (well, 2.1.15 needs 1.4, but 2.1.14 will run with pretty much any earlier release) and furthermore, doesn't care how the asterisk image was built so we would be happy to encourage/help anyone who has a better/different idea when it comes to building asterisk on SME Server, and we do like your idea.
:-)
Thanks for the good input.
Best
S
-
OK..
Being adventurous, I followed rcasado's lead and created and compiled the zaptel module myself.. I went so far as to update the kernel using the centosplus repository.
I now have a zaptel module that installs nicely... ( at least, modprobe zaptel, doesn't complain )
But, sail still doesn't see the card..
lspci -vv yeilds:
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 96 (250ns min, 32000ns max)
Interrupt: pin A routed to IRQ 185
Region 0: I/O ports at 2100 [size=256]
Region 1: Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Don't know where to go from here.
Thanks
L2
[/code]
-
More info to fuel the fire..
On a hunch, I added my card to the database and got a little further ( I think )
Now when I probe for the card I get the following:
Found following card...
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Requesting Load of wctdm ...
Loading zaptel...
Loading wctdm...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
It finds the card this time, but after a commit, I still get:
PCI Telephony Cards
There are currently no PCI Telephony cards registered on the system.
In the UI..
Thanks
L2
-
More info to fuel the fire..
On a hunch, I added my card to the database and got a little further ( I think )
Now when I probe for the card I get the following:
Found following card...
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Requesting Load of wctdm ...
Loading zaptel...
Loading wctdm...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
It finds the card this time, but after a commit, I still get:
PCI Telephony Cards
There are currently no PCI Telephony cards registered on the system.
In the UI..
Thanks
L2
Hi llandry,
Think you just selected the wrong driver in your database :
Loading zaptel...
Loading wctdm...
Loading ztdummy...
Most probably you did something like
/sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wctdm zzeor EOR
Try with 'wcfxo' instead of 'wctdm' ;-)
/sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wcfxo zzeor EOR
Best,
Hervé
-
Yes indeed Hervé,
After staring at it for awhile I noticed that and changed it...
so now I have the following in the db:
[root@master ~]# db selintra-work show pci:1057:5608:1055:0001
pci:1057:5608:1055:0001=sysdev
probe=wcfxo
zzeor=EOR
[root@master ~]#
and this when I probe...
Found following card...
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Requesting Load of wcfxo ...
Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
and the following after the commit:
PCI Telephony Cards
There are currently no PCI Telephony cards registered on the system.
So, still no luck...
I do thank you for your patience.
L2
-
Hi R
Just a thought
...and a good one. We've discussed this many times. As you may know, A@H/Trixbox/ whatever it's called nowadays, installs asterisk in the way you describe and it has some advantages from a kernel-release point of view but, of course, once its in, they have the same problem to keep up with the Kernel releases that we have. The great beauty of rpm is that it can be regressed if you get it wrong and this is incredibly important for our paying customers. They won't allow us to take their phones away from them while we rebuild the system if we get a release wrong. With rpm, we can be back to the previous release in less than a couple of minutes if we screw up (and we do screw up - :-) ).
In truth, we only maintain asterisk to maintain SARK/SAIL, it's a job we would rather not have to do...
SARK/SAIL, doesn't much care which asterisk release it's running against (well, 2.1.15 needs 1.4, but 2.1.14 will run with pretty much any earlier release) and furthermore, doesn't care how the asterisk image was built so we would be happy to encourage/help anyone who has a better/different idea when it comes to building asterisk on SME Server, and we do like your idea.
:-)
Thanks for the good input.
Best
S
Maybe just need to add a 'sail panel entry' called 'Update asterisk modules' that launches the script, and make copies of the right files at the right place if new kernel detected ... ?
Just a though ;-)
Best,
Hervé
-
Yes indeed Hervé,
After staring at it for awhile I noticed that and changed it...
so now I have the following in the db:
[root@master ~]# db selintra-work show pci:1057:5608:1055:0001
pci:1057:5608:1055:0001=sysdev
probe=wcfxo
zzeor=EOR
[root@master ~]#
and this when I probe...
Found following card...
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Requesting Load of wcfxo ...
Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...
Zaptel view of card in /proc/zaptel/1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"
and the following after the commit:
PCI Telephony Cards
There are currently no PCI Telephony cards registered on the system.
So, still no luck...
I do thank you for your patience.
L2
No problem ;-)
Now you got both drivers loaded :
Loading zaptel...
Loading wcfxo...
Loading wctdm...
Loading ztdummy...
You should only have 'zaptel' and 'wcfxo'.
Did you rebooted your system ?
Did you erased the previous 'PCI' entry (wctdm) in database ?
Think you are very close to the solution :-)
Herve
-
Hervé,
I thought I deleted the entry before... I just need to supply the key correct?
db selintra-work -delete key
Although I'm getting close, I'm packing it in for the night.
Again, merci for all your help.
L2
-
Hervé,
I thought I deleted the entry before... I just need to supply the key correct?
db selintra-work -delete key
Although I'm getting close, I'm packing it in for the night.
Again, merci for all your help.
L2
Yep, but in fact they are two databases ( selintra & selintra-work ... ), need to commit to 'copy' selintra work onto selintra.
Would suggest the following ( I have to go to work now ;-) ) :
- Check again the PCI id to be 100% sure it meets your card ( XP100 clone ? ) using lspci commands as described in the 'sail documentation'.
... Subsystem is currently maybe not correct :
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
- do again ' /sbin/e-smith/db selintra-work set pci:xxxx:xxxx:xxxx:xxxx sysdev probe wcfxo zzeor EOR ' using the right PCI ID
- do a 'commit' in sail panel
- reboot
- initialize and probe + commit
- reboot again
... Not the shortest way, but since I have to go ... ;-).
Best,
Hervé
-
Hi Llandry,
Sorry you're having bother with PCI mate.
The PCI detection stuff is, outside of the AGI itself, the most complex code in the system (ask Herve - he's just added the mISDN support in 1.4 and it gave him grey hair! - only joking Herve ;-) ).
There are a few bugs in there, but the routine will usually work very well first pass. It's when you change things that it starts to get a little pernickety.
It's not even as if I can blame anyone else because I personally wrote the PCI code so I stand guilty as charged.
In particular ZTDUMMY is a pain. because once PCI has decided it needs to load it, that's it, it will not release the damned thing.
Anyhoo, all this doesn't help you except to say that I am just finishing up automated PRI recognition & support for Digium cards. Two promises....
I will fix as many bugs as I can find and I will get 'round to opening up the card recognition database with a GUI component.
Best
Jeff@selintra
-
Thank you both for your help...
I can't get help like this from a commercial product :)
Hervé, I followed you advice and still no go.... It still loads the wcfxo, wctdm and ztdummy drivers...
Jeff, I removed the selintra-sail rpm, dropped the asterisk database, rebooted and re-installed the rpm and it sill picks up the wctdm driver that I had set in error previously. Is there some other file that may not be removed when I un-install?
Thanks a bunch guys...
L2
-
We're getting closer..
I've done a bunch of clean up in the selintra-work database and removed erroneous references to the ztdummy and wctdm drivers..
I unloaded the wctdm, ztdummy, wcfxo and zaptel drivers from memory.
I then probed for the card again and go this:
Found following card...
01:03.0 Communication controller: Motorola Wildcard X100P
Subsystem: Efar Microsystems: Unknown device 0001
Flags: bus master, medium devsel, latency 96, IRQ 185
I/O ports at 2100 [size=256]
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Requesting Load of wcfxo ...
Loading zaptel...
Loading wcfxo...
No Zaptel Telephony Boards found - check admin-error log for probe failures...
Signalling asterisk daemon to load ZTDUMMY for timing purposes
And this is what is on the logs:
Jun 13 09:41:16 master kernel: Zapata Telephony Interface Registered on major 196
Jun 13 09:41:16 master kernel: Zaptel Version: SVN-branch-1.4-r2645
Jun 13 09:41:16 master kernel: Zaptel Echo Canceller: MG2
Jun 13 09:41:22 master kernel: ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 20 (level, low) -> IRQ 185
Jun 13 09:41:22 master kernel: Failed to initailize DAA, giving up...
Jun 13 09:41:22 master kernel: wcfxo: probe of 0000:01:03.0 failed with error -5
Jun 13 09:41:22 master kernel: Registered tone zone 0 (United States / North America)
I've double check the signature of the card and:
pci:1057:5608:1055:0001
is indeed the correct string.
So.... Is my card bad maybe? or, have I made such a mess that maybe I should start from scratch :)
Thanks
L2
-
A bit late but just to confuse stuff.
To use trunk is NOT recommended in a production environment, here are new functions being tested and features can go from stable to totaly unstable from one minute to another.
svn checkout http://svn.digium.com/svn/asterisk/trunk asterisk
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
svn checkout http://svn.digium.com/svn/libpri/trunk libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/trunk asterisk-addons
svn checkout http://svn.digium.com/svn/asterisk/branches//x.x asterisk
svn checkout http://svn.digium.com/svn/zaptel/branches/x.x zaptel
svn checkout http://svn.digium.com/svn/libpri/branches/x.x libpri
svn checkout http://svn.digium.com/svn/asterisk-addons/branches/x.x asterisk-addons
Branches is the part that are released as stable releases and is the same as the one that can be downloaded as tar packages. x.x is the version of asterisk example 1.2, 1.4 and so on.
-
Hi Llandry
I've had a quick look at the code and this may be a timing problem.
Do this...
stop zaptel with zaptel -s
Then...
lsmod
make a note of any digium drivers loaded...
unload them with rmmod driver name...
e.g. rmmod ztdummy
finally unload zaptel itself with...
rmmod zaptel
check that they've all gone with...
ls /proc/zaptel
/proc/zaptel should not exist at this point because udev should have deleted it.
OK, load wcfxo...
modprobe wcfxo
then do...
cat /proc/zaptel/1
Tell me what you get....
:-)
best
j@selintra
-
[root@master etc]# modprobe wcfxo
Notice: Configuration file is /etc/zaptel.conf
line 0: Unable to open master device '/dev/zap/ctl'
1 error(s) detected
FATAL: Error running install command for wcfxo
[root@master etc]# ls /proc/zaptel
[root@master etc]#
Obviously... I'm having more issues then I originally suspected...
What I'm tempted to do is start from scratch... I've done alot of playing around and kernel updates and the like...
Since now I know that the card was not in the original Selintra db, I'll reinstall a fresh copy of SME, re-install the latest version of Sail and, add the card to the db before I try to probe... That should give us a clean slate to work with...
My day job is interfering with this, so I'll attempt it later tonight.
I'll keep you posted.
Luc.
And again.... Your help is second to none. :)
-
Hi Luc
What happened isn't necessarily wrong. Udev takes a few seconds to build /dev/zap.
Just wait a moment (I've seen it take up to 20 seconds on a small system) and try the modprobe again.
If it doesn't work at the second time of asking then yes, you've probably got a problem.
S
-
The second time I try to install wcfxo, no complaints...
lsmod yields:
wcfxo 11424 0
zaptel 197668 1 wcfxo
crc_ccitt 2241 1 zaptel
but still nothing in /proc/zaptel
Thanks
L2
-
then I think the board may not be quite as it should be.
udev builds one entry (at least) for each Digium board in /proc/zaptel. It numbers them 1,2,3...n.
Doing a cat on these files should show you the board and it's characteristics. As an example; heres a TDM card Span (just after the modprobe)...
# cat /proc/zaptel/1
Span 1: WCTDM/0 "Wildcard TDM400P REV I Board 1"
1 WCTDM/0/0
2 WCTDM/0/1
3 WCTDM/0/2
4 WCTDM/0/3
Here's the same card after ztcfg has been run and asterisk has started...
# cat /proc/zaptel/1
Span 1: WCTDM/0 "Wildcard TDM400P REV I Board 1"
1 WCTDM/0/0 FXOKS (In use)
2 WCTDM/0/1 FXOKS (In use)
3 WCTDM/0/2 FXSKS (In use)
4 WCTDM/0/3 FXSKS (In use)
Unfortunately I don't have an X100P to hand but it looks like a single FXO channel TDM board.
best
S
-
Hi L2,
... Maybe some interrupt problem that makes the card to not register on wcfxo ... ?
==> cat /proc/interrupts ... any conflict ?
==> Does the PC BIOS allows you to force IRQ on used slot ?
Disabling auto IRQ assignments, PNP Operating system ... and stuffs like that may sometimes help. Really depends of the BIOS settings capabilities.
==> Did you tried using ( if any ) another PCI slot ?
Best,
herve
-
Hervé,
Yes my friend... its been moved to all the slots available with no change...
I haven't tried the clean install yet, my day job is starting to affect my moonlighting :)
That will teach me to buy stuff off eBay, just to save a few pennies :? ...
If I can't get this thing to work, I'll just go a get a TDM400 from Digium..
Thanks again..
L2
-
This may not be the place to ask this question, if so, I apologize in advance.
As previously stated, I'm new to this Telephony stuff.
My DID and Termination supplier for VoIP supports the G.729 codec. Would I benefit from licensing G.729 ?
Although I will be traffic shaping, would the benefit of added bandwidth out way the cost ( which I'm not to concerned about @ $10/channel) and the CPU requirements?
I'm running a dual PIII 1.13Ghz box, and, for now, don't expect to have more then 5 concurrent calls. I will have quite a bit of data traffic though.
Thanks
L2
-
Both these releases have some new "mass-deployment" features, the most important of which is central directory and Speeddial for Aastra and Snom phones. You can find details on the Docs site..
http://selintra.com/docs/cgi-bin/view/Main/DocChapterHdrs
This feature allows you to create a freeform directory in headers and have it automatically downloaded to all the phones on your network (provided they are Snoms or Aastras). If you want us to include other phone types then please shout, obviously they MUST support remote directory provisioning (many don't).
Hi Selintra,
I'm running selintra-sail-2.1.15-468.noarch.rpm but the seldir.conf and selspeed.conf files aren't in the headers section as shown in the docs link for the universal directories.
This is something that would be nice to implement. Am I missing something?
Thanks
Mark.
-
I'm running selintra-sail-2.1.15-468.noarch.rpm but the seldir.conf and selspeed.conf files aren't in the headers section
Awwwwwwwwwwwwwwwwwwwwwwww! Doh! Doh! Doh!
We missed the database tuples for selspeed and seldir in the -468 cut!!
How dumb is that?
We are putting up the automated PRI releases this evening. Promise they'll be in there.
:oops: :oops: :oops:
Kind Regards
Selintra
-
Nice one.
Also the Aastra 480i looks absolutely great for the money.
The directory feature has convinced me this is the way to go regarding phone models.
Thanks again,
Mark.
-
Llandry
re G729
would the benefit of added bandwidth out way the cost ( which I'm not to concerned about @ $10/channel) and the CPU requirements?
Short answer is absolutely. G.729 is the Dr Cure-all for VoIP. The big issue is your upload bandwidth and how much of it you actually get in practice (after contention). On a standard broadband circuit (ADSL)you will normally only get 256Kbs uplift. This will usually only give you 2 concurrent Alaw/Ulaw calls. The third call will almost certainly jitter. On the same 256K you should get at least 6 G729 calls without problem. Alaw/Ulaw uses around 68K per call in each direction (with message header overheads), G.729 uses around 12K and the sound quality is so near as to be almost indistinguishable from G711 (alaw).
At 10 bucks a channel I think that's seriously good value.
Also, with SAIL, you don't need to worry too much about extra CPU usage because SAIL can automatically optimise your system for G729 passthrough (by setting G729 in Globals). G729 only uses CPU if you are actively transcoding between it and something else. SAIL minimises this by forcing the transcoding off to the carrier on one side and the phones on the other. The only time SAIL will actually transcode is during Music-on-Hold and voicemail operations (record and playback).
Cool huh?
:-)
Best
Selintra
-
As I said before...
I couldn't get this kind of support if I paid for it 8)
I think I'll give G.729 a try on my home PBX, then implement @ the office.
And yes, you guys ( and I'm assuming gals as well ) do have a Cool product!!
I had never touched Telephony before and I had a full PBX running in a matter of hours.
Thanks
L2
-
Hi Selintra,
Just installed the new 473 version of SAIL.
The Seldir and Selspeed conf files are now in Headers (as you already know) but thanks.
I was having a few problems with 468 with DTMF tones being received, and sip debug showing:
* DTMF-relay event received: 1
etc.. but the tones were being completely ignored. Then other times they'd work fine.
I'll keep you posted how this goes with 478.
Thanks a lot
Mark.
PS, I love the Dump facility. How cool is that!!
-
Hi Mark,
Careful with seldir - we just found a little bug in it this afternoon.
Do a commit on your system (anywhere - doesn't matter) and then take a look at the message logs. You are looking for a file-not-found during a copy operation...
/bin/cp /tftpboot/seldir
If you find it then the bug is definitely in 473.
You can fix it temporarily by going to the linux console (as root) and doing...
touch /tftpboot/seldir
Best
S
-
Hi Selintra,
I had a look and found this, is this it?
Jun 16 20:08:26 fry esmith::event[6556]: expanding /tftpboot/seldir
Jun 16 20:08:26 fry esmith::event[6556]: /bin/cp: cannot stat `/tftpboot/sel_aastra_dir': No such file or directory
It's the only reference I could find relating to seldir.
Still getting intermitent ignoring DTMF tones in 478, even though they are being received.
Any ideas?
Regards
Mark.
-
yes that's the bug.
Thanks for your help in verifying it. Looks like -475 will be along shortly - :-)
Re DTMF
DTMF from where to where? Phone to asterisk? Phone to third party IVR? inbound to IVR?
If it's from your phones then we need to know what kind of phones you got. :-)
Best
S
-
Apologies,
It's inbound to IVR.
With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:
* DTMF-relay event received: 2
Stating the tone received EVERY time, however sometimes asterisk will receive the tone like:
* DTMF-relay event received: *
<--- Transmitting (no NAT) to 217.10.79.23:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 217.10.79.23;branch=z9hG4bKe77c.22dc452.0;received=217.10.79.23
Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKe77c.428de504.0
Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK662e94fb;rport=5060
Record-Route: <sip:217.10.79.23;lr=on>
Record-Route: <sip:217.10.79.8;ftag=as1186addc;lr=on>
From: "Unknown" <sip:Unknown@217.10.66.71>;tag=as1186addc
To: <sip:448458692823@217.10.79.8>;tag=as3e5907c1
Call-ID: 2f04fca74ea4edc036d6e635271a44a2@217.10.66.71
CSeq: 105 INFO
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:8692823@192.168.1.2>
Content-Length: 0
Then:
Sometimes asterisk will just continue reading the IVR, completely ignoring the tone
Sometimes asterisk will respond instantly
Sometimes several seconds will pass, then it will respond
If or when it does respond it carries on as normal reading the correct IVR option:
<------------>
-- AGI Script Executing Application: (Background) Options: (silence/1)
-- <SIP/8692823-09aa74f0> Playing 'silence/1' (language 'en')
-- AGI Script Executing Application: (Wait) Options: (1)
-- Playing 'usergreeting0000' (escape_digits=129#) (sample_offset 0)
If it helps (I have no idea if it will however, so ignore as appropriate ), this is on AMD platform, and the running kernel is:
CentOS (2.6.9-42.0.10.EL)
Thanks a lot,
Mark.
-
selintra fix your email server. You are bouncing tons of emails every day with a message of:
Mail already has my delivered-to
Any mail sent from any smeserver to anything@selintra.com is bouncing.
-
Re mail,
Well, all I can say is we're receivng mail just fine from everyone else, we've had no complaints (other than yours) so we weren't aware of any problems. It's just a vanilla mail server on a vanilla SME 7.1 system.
What e-mail address are you attempting to send to?
Best
S
-
I've tried sending to admin@selintra.com from the admin account at my domain and from contribs.org and get email similar to the following. This is the latest bounce that contribs.org admin group has received. We receive quite a few of these every day.
Hi. This is the qmail-send program at selintra.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<admin@selintra.com>:
This message is looping: it already has my Delivered-To line. (#5.4.6)
--- Below this line is a copy of the message.
Return-Path: <admin@contribs.org>
Received: (qmail 8891 invoked by uid 101); 17 Jun 2007 08:15:07 -0000
Delivered-To: admin@switch.selintra.com
Received: (qmail 8887 invoked by alias); 17 Jun 2007 08:15:07 -0000
Delivered-To: alias-localdelivery-admin@selintra.com
Received: (qmail 8884 invoked by uid 453); 17 Jun 2007 08:15:07 -0000
X-Spam-Status: No, hits=0.5 required=5.0
tests=NO_REAL_NAME,SPF_PASS
X-Spam-Check-By: selintra.com
Received: from mail.contribs.org (HELO mail.contribs.org) (216.17.211.37)
by selintra.com (qpsmtpd/0.32) with ESMTP; Sun, 17 Jun 2007 09:15:03 +0100
Received: from localhost (localhost [127.0.0.1])
by mail.contribs.org (Postfix) with ESMTP id 61CAD2801B
for <admin@selintra.com>; Sun, 17 Jun 2007 02:14:58 -0600 (MDT)
X-Virus-Scanned: amavisd-new at contribs.org
Received: from mail.contribs.org ([127.0.0.1])
by localhost (mail.contribs.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gxshEAQKRYi0 for <admin@selintra.com>;
Sun, 17 Jun 2007 02:14:57 -0600 (MDT)
Received: from contribs.org (unknown [192.168.250.37])
by mail.contribs.org (Postfix) with SMTP
for <admin@selintra.com>; Sun, 17 Jun 2007 02:14:57 -0600 (MDT)
Received: (qmail 32261 invoked by uid 100); 17 Jun 2007 08:14:56 -0000
To: Undisclosed-recipients: ;
Subject: Topic Reply Notification - SAIL - Using the hash key as the send key
Reply-to: admin@contribs.org
From: admin@contribs.org
Message-ID: <b98efb061b344ed45ef83917a8014c4d@forums.contribs.org>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
Date: Sun, 17 Jun 2007 01:14:56 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP
X-MimeOLE: Produced By phpBB2
Hello,
You are receiving this email because you are watching the topic, "SAIL - Using the hash key as the send key" at Contribs.org. This topic has received a reply since your last visit. You can use the following link to view the replies made, no more notifications will be sent until you visit the topic.
http://forums.contribs.org/index.php?topic=37446.msg167963#msg167963
If you no longer wish to watch this topic you can either click the "Stop watching this topic link" found at the bottom of the topic above, or by clicking the following link:
http://forums.contribs.org/index.php?topic=37446.0
--
Thanks, Contribs.org Staff
-
Hi Slords,
We can only apologise. Since we know even less about Qmail than we do about almost anything else, and since we are a POP3 shop, we've simply flattened and reinstalled the mail server.
With luck this should have cured the problem.
Thanks for the heads up and, once again, sorry for any inconvenience caused.
Kind Regards
S
-
Well folks...
Here's the update.... all good...
I've successfully implemented the X100P card in my home system. Single PIII.
I also successfully implemented a TDM400 with 1 FXO and 1 FXS on the dual CPU PIII running an SMP kernel..
Thanks all...
I couldn't have done it without your excellent support.
Now... one more quick question.... My FXS port on the TDM400 will be connected to a Fax machine... I've setup autofax detection in Globals to extension 3999, but how do I define the extension? I do not see an FXS "device" when I define extensions.
Thanks
L2
-
My Bad.... Spoke to soon...
The TDM400 got recognized as a TDM01b, not the TDM11b that it should...
Once I plugged in the 12V Connector Duh!!! :oops: All is well and I now see the Analogue extension
Thanks
L2
-
Hi Llandry,
Glad you got there. Don't worry, every newcomer to TDM boards quickly discovers that they work just fine without the 12V power, except the FXS ports don't come up!
It uses the power to generate the ring voltage for the phone.
As an aside, when you run purely with FXO ports we've had odd instances where plugging the power up is actually detrimental over long periods with the boards sometimes ending up in strange states. As a result we tend not to plug 'em up when they are purely FXO.
Best
S
-
Apologies,
It's inbound to IVR.
With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:
Hi Mark,
Re your previous observation on 1.4 DTMF. We have seen the same problem, particularly on voicemail. It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens. SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.
We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2
Watch this space....
Best
S
-
Hello Selintra,
A couple of quick questions on 2.1.15-483, 1.4.1-8 Asterisk & 1.4.0-5 MPP. (I set these up on a clean install w/ yum all updates.)
For some reason, I can't get the music on hold to operate properly. I did go into the musiconfold.conf and changed it to /var/lib/asterisk/moh then verified that MoH is selected on the trunks... but to no avail... I still get a ring even though the /var/lib/asterisk/moh subdirectory is populated with the default music files.
Also, I noticed a difference in the way Sail is managing email. When I set up an email address on an extension, emailing the voicemails works properly but when I don't, things go awry... In the past, I would set the supervisor email address in the globals section to admin@mydomain.com as a catch all. Sail would forward voicemail to the admin@mydomain.com account if the extension's email address was left blank. Since the update, emails are going to admin@localhost.mydomain.com... (even though I've set it up to go to admin@mydomain.com) therefore causing a qmail-send error. Has this configuration changed? Perhaps that wasn't its intended use but it was very handy to have a catch-all account. :)
Thank you,
Richard
-
Apologies,
It's inbound to IVR.
With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:
Hi Mark,
Re your previous observation on 1.4 DTMF. We have seen the same problem, particularly on voicemail. It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens. SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.
We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2
Watch this space....
Best
S
Thanks for the response S.
I'm just in the process of rolling out new hardware anyway so I'll give asterisk 1.4.1 another go anyway.
When you release 1.4.4 I'll let you know if it made a difference.
Regards
Mark.
-
Apologies,
It's inbound to IVR.
With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:
Hi Mark,
Re your previous observation on 1.4 DTMF. We have seen the same problem, particularly on voicemail. It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens. SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.
We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2
Watch this space....
Best
S
Thanks for the response S.
I'm just in the process of rolling out new hardware anyway so I'll give asterisk 1.4.1 another go anyway.
When you release 1.4.4 I'll let you know if it made a difference.
Regards
Mark.
Hi Selintra,
Just tried this on brand new Intel Hardware, and the problem is exactly the same. The DTMF tones are being received by Asterisk, as you can see them in the debug, but the intermittent delayed or ignored responses are still there in the IVR.
I agree with your comments that this is an Asterisk thing, as it's Asterisk that's receiving the DTMF tones at the time they're ignored.
I might give 1.2 a go with Sail 2.1.14 but was wondering, is the Sail 2.1.15 "selintra-work" file compatiable with 2.1.14 if I do a restore?
Thanks a lot
Mark
-
Hi Selintra
I wanted to ask you how can I auto start the TDM02B support without the selintra package, since i wasn't able to do it, i couldn't find any script for that and my results where very odd.
I do:
modprobe zaptel
modprobe wcfxo (I got an error message here)
modprobe wctdm (I got an error message here too)
modprobe wcfxo (now it works (???? WTH???))
modprobe wctdm (now it works too (?? ZOMG!!))
/sbin/ztcfg -f
/sbin/ztcfg -vvvv
ok this works when I do it manually, but if I put this on a scritpt and run it (of course without the -vvvv) it doesn't work, and I don't get it why.
Also I don't get it why the second time I modprobe wctdm and fxo it works and the first one gives me error message.
I have a Digium TDM 400 with 2 fxo ports, on a I945GCCR mobo, pentium D 925, 1G DDR2, SME 7,1 fully updated, and I'm running asterisk 1.4.1-8 and zappri-MPP-1.4.0.4
I installed everything except the selintra package.
Now I decided to install on another box the selintra package which detected and configured the TDM nicely, however I'm very get used to configure asterisk by hand, is it a bad idea to use your package just for initial config and then configure every .conf by hand?.
(at least until i get used to the new interface, that seems very nice btw :D but needs hands on to figure it out :) )
thanks!.
Light.
-
Hi Light
First things first. There's no reason why you shouldn't use our rpms to do the board config and then just hack away at the base files as long as you don't ever go back to our front-end (because there is no reverse engineering - we won't know what you've done and if you issue a commit in our package it will over-write all of your good work)..
Alternatively, if you just want Vanilla asterisk rpms the Laimbock consulting ones are worth a look.
Or... With Yum, you can very quickly install a devpack of your own and compile asterisk from source. It takes about 40 minutes from start to finish and it isn't hard. Just remember to yum remove the devpack when you've finished.
As to your strange modprobe results...
In earlier asterisk releases, there was no wctdm driver (it was aliased to wcfxo), however it does exist in its own right in current releases. So, the ONLY probe you need for a TDM board is...
modprobe wctdm
Probing wctdm will automatically load the module(s) it depends on (zaptel). You can see the relationship by doing "lsmod" after the probe.
Now, at first load you may get an error. This is due to the time udev takes to build the /dev trees for the device. It's no big deal and, as you've already discovered, if you wait a second or two and probe it again, it works. You can watch this happen by looking at /dev/zap/. It won't exist before you do the probe but it will magically appear afterwards. That's udev doing its stuff, but it takes a few seconds.
Lastly you can simply start zaptel itself with "ztcfg". By the way, it's not a good idea to call ztcfg more than once. It's fine for TDM boards but some boards get extremely upset if you start zaptel repeatedly without first stopping it with zaptel -s.
Hope this helps
;-)
-
Hi Selintra
Thanks a lot for the info!.
I will take a look at the laimbock rpm but, until i have this little problem with the TDM card i was very happy with your release, very stable btw :) i have 4 servers running it and works like a charm. (none of them has tdm cards, but this new one).
I was thinking about compile it myself but, since my blood pressure tends to go up in direct proportion to the amount of missing dependences, it would be a lot healthy to avoid it :mrgreen: :mrgreen:
I follow you suggestion but the only way, that I can start automatically in a script (so far) is doing something like this:
modprobe wctdm
sleep 3
modprobe wctdm
sleep 1
ztcfg
sleep 1
ztcfg
the first ztcfg gives me error too when loaded inside the script (if I load by hand it works the first time, but not in the script).
so far doing this start perfectly :) hope it doesn't upset my tdm card because is the only way i found to make it work.
the weird thing is that I check if the /dev/zap exists before the first ztcfg and it does, but still gives me error the first time when inside the script.
if you have any idea, or recommendation to avoid this nasty solution I will be glad to test it :)
thanks a lot.
c-u
Lightman.
-
Hi Light
OK.. This might work for you.
The way in which our config works is that it sets values in the selintra database for which drivers to probe. Here's what you can do...
Install our asterisk rpms and the latest (505) sail rpm.
OK now do...
db selintra setprop wctdm status YES
This will turn on the value to load wctdm gracefully through our code.
Now, provided you have set zaptel.conf and zapata.conf correctly for your card, you can start your asterisk image with...
/etc/init.d/asterisk start
That's it.
Best
S
-
Hi Selintra,
I've been looking through your documentation on 1.4 and I was wondering about SLA (shared line appearance) and Sail. I know that 1.4 is at best buggy right now but SLA can be a deal maker / breaker for some small phone systems. Yeah, I know :? limited... but some people, no matter how hard you try, just don't get the concept of a parked call. ugh...
Are there any plans to take advantage of this?
Thank you,
Richard
-
Hi Richard
Are there any plans to take advantage of this?
You bet. It was the reason we went to 1.4 as early as we did. We just haven't had the bandwidth to do anything with it yet. In our opinion, key systems are great for small offices and we don't understand why it has taken Digium as long as it has to figure this out for themselves. Having said that, it doesn't seem to have occurred to many of the phone manufacturers either. There's really only Snom and Aastra phones which have enough assignable buttons to handle SLA and BLF in tandem.
If you want to get to grips with sla and have some spare bandwidth we'd be happy to support you.
Best
S
-
Ohhhh... I see myself putting on the crash helmet already :lol:
Most businesses in my area will obtain about 400K to 600K upload speed on their broadband and ping times are usually good, but that's pretty common in the USA. This can be a stumbling block for some larger companies but it may be quite acceptable for smaller firms... Especially since thruput mode in Sail has always been quite good. I've always used Sail in server only mode and have compensated for QoS with a solid router. Personally, I use the DrayTek 2900VG because I've had good luck with them, plus they include a couple of FXO ports. (Not an advertisement, just personal experience... your mileage may vary.)
I clearly understand your point about the phone manufacturers and was thinking the same thing. One unit that looks interesting is the Grandstream GXP2020. (http://www.grandstream.com/gxp2020.html) Yeah, they're economy type phones, no doubt about it, but it may make for a good test unit. I'll order one of these in the next week or two and let you know.
Well... Now that I have the helmet firmly placed on my head... :lol:
Are there going to be any new releases to version 1.4 / 2.15 in the near future?
As always, Thank You,
Richard
-
Hi Light
OK.. This might work for you.
The way in which our config works is that it sets values in the selintra database for which drivers to probe. Here's what you can do...
Install our asterisk rpms and the latest (505) sail rpm.
OK now do...
db selintra setprop wctdm status YES
This will turn on the value to load wctdm gracefully through our code.
Now, provided you have set zaptel.conf and zapata.conf correctly for your card, you can start your asterisk image with...
/etc/init.d/asterisk start
That's it.
Best
S
Would this work with a Sangoma Remora card?
Based on Sangoma docs my understanding was that I would need to do new builds of Asterisk, zaptel, and sangoma's wanpipe drivers in order to make their card function properly. So far I have done fresh make installs of asterisk 1.2.23, patched zaptel 1.2.19 modules for sangoma, and installed sangoma wanpipe 2.3.4-12 drivers successfully through the Setup script that Sangoma includes. It even automatically builds a zapata.conf and zaptel.conf.
After that I installed Sail -505 which of course replaces those files (I did backup the originals before installing Sail). Anyway, when I run the probe script in the server-manager web interface or selsniff I get
Found following card...
01:01.0 Network controller: Sangoma Technologies Corp. A200/Remora FXO/FXS Analog AFT card
Subsystem: NEC Corporation: Unknown device 0500
Flags: bus master, medium devsel, latency 255, IRQ 201
Memory at fdcf0000 (32-bit, non-prefetchable) [size=64K]
Requesting Load of wctdm ...
Loaded wctdm...
Zaptel view of card in /proc/zaptel/1
Span 1: WRTDM/0 "wrtdm Board 1"
1 WRTDM/0/0 FXSKS (In use)
2 WRTDM/0/1 FXSKS (In use)
3 WRTDM/0/2 FXSKS (In use)
4 WRTDM/0/3 FXSKS (In use)
5 WRTDM/0/4
...
24 WRTDM/0/23
Unknown Card type in slot 1 - ignoring...
After reading the Selintra admin docs on PCI card detection I tried adding the card to the selintra-work db with
# db selintra-work set pci:1923:0040:a200:0500 sysdev probe wctdm zzeor EOR
This was based on the output from lspci -vn
# lspci -vn
01:01.0 Class 0280: 1923:0040
Subsystem: a200:0500
Flags: bus master, medium devsel, latency 5, IRQ 201
Memory at fdcf0000 (32-bit, non-prefetchable) [size=64K]
I also tried substituting various module names for 'wctdm' like wcfxo, wct4xxp, wanpipe, zaptel. As you can see I have no idea what the heck I'm doing so any advice would be greatly appreciated. :)
I've read postings that mention these cards before but have failed to find documentation for a successful install. Just blurbs like "I cant make it work. NM I got it, k thanks!" If I finally get it to work the least I'd like to do is post a log/journal of my complete install from start to finish. Preferably I will digest what had to be done and then create some kind of documentation or script to share with the community. There are a lot of folks using third party pci cards like Rhino and Sangoma.
-
Hi Rezo,
I'm afraid that SAIL doesn't support Sangoma cards. Right now we just don't have enough spare capacity to create another version of the asterisk code (which we would almost certainly have to do for Sangoma). If enough people ask us to support it then we will, but up to now you are the only person who's asked.
Kind Regards
Selintra
-
Well I already compiled Asterisk and the Sangoma patched zaptel drivers so that Asterisk is successfully communicating with the card on SME Server 7.2. For some reason I thought that would satisfy the requirement of having to install smeserver-asterisk and smeserver-asterisk-zappri-MPP rpms. I can launch the Asterisk cli and see the active zap channels.
I may have misunderstood what your package provides but is SAIL not simply a "frontend" so to speak for Asterisk. Simplifying the process of creating trunks, extensions, greetings, etc. ? Would it actually require a major working of SAIL to make it work with my fresh install of Asterisk or is there something different about smeserver-asterisk-xxx.rpm from a manual compile of asterisk?
I guess I can look into using FreePBX but since SAIL seemed like it was targeted for users of SME I figured I would try it out first.
-
Hi Rezo
How good is your Perl?
Best
S
-
hi selintra,
that question makes it sound like an evil grin should have accompanied it :wink:
my perl skills are rudimentary at best but i have dealt with scripting in various formats for quite some time. I was not out to reinvent the wheel and see the reason for little interest in it for you if your customer base doesn't need the support either. I was in the hopes that it would not be too difficult to make SAIL control a zaptel device that asterisk was already recognizing. I did find a post where someone else said they got their A200 card to work with SAIL. The post seemed to indicate their problems were solved once they compiled the patched drivers (which ive already done) and then changed the info that identifies the pci card. I think this is where I am getting stuck??
Since you replied to this thread you might remember it http://forums.contribs.org/index.php?topic=36464.0
note: that makes at least two people who inquired about compatability with the sangoma a200?? :)
-
OK good.
Our Perl skills are, quite frankly, crap so you may find the code a little tortuous. As you've guessed, you've done most of the hard work already but you will need to hack the SAIL code a little. Also, it's difficult for us to do much more than point you in the right direction because we don't have a Sangoma card here to practice on.
The module you need to hack is called sarkPCI and you will find it in /etc/e-smith/web/functions/. PCI does the automatic recognition and configuration of the various cards we support. Let's start with the error message you are getting; - it is generated in a subroutine called genHandle which you will find at or near line 928 (depending upon which version of SAIL you have). genHandle reads through the /proc/zaptel/ entries examining the loaded cards and then handing off to the correct routine(s) to create the zapata and zaptel entries necessary for asterisk to recognise the cards. It recognises the cards by simple regex pattern matching. Your card has been processed as a result of your request for SAIL to modprobe wctdm (when you defined your card type to the database). Unfortunately, PCI doesn't recognise the 'WRTDM' signature (look at or near line 1000). So, you'll need to make a small mod in this routine to recognise your card. Once you've done that you will need to create a "builder" routine to store your card data into the database and to build the necessary trunks/extensions for it. Most of this is already done for you in various subroutines within PCI but you will have to decide which ones to call and when. The "builder" routine which comes closest to doing what you want is called 'tdmHandle' (it builds the entries for regular TDM boards). You will need to copy and hack it to create a 'sanHandle', or whatever you want to call it. To be honest, this stuff is harder to explain than it is to do. If you are familiar with scripting languages then you shouldn't have too much trouble with PCI.
Happy hacking and do let us know how you get on. Also if there's anything you don't understand or want help on then drop us a line here.
Have fun
S
-
Alright pointing me in the right direction is definately a good start. Before I get in over my head on this let me just be clear on the following things...
Is it actually necessary for me to rely on the sarkPCI script to detect my card automagically? I understand that it is responsible for detecting what kind of card I have, how many and what kind of channels, etc.; then I guess later this would lead to the generation of a set of zaptel.conf and
zapata.conf files for asterisk and create certain records in the SAIL databases.
The Sangoma driver package includes a utility that will auto-generate a proper set of zapata.conf and zaptel.conf files so there is a lot of valuable info provided with that. Also lets assume I already know all the tidbits of information about card (like which driver modules need to be loaded and in what order, which pci slot its in, how many fxo and fxs channels there are, stuff like that) would it be possible for me to create the necessary DB entries by hand as well as the asterisk conf files?
I took a brief look at the sarkPCI script and the tdmHandle routine but I'm not exactly sure what some of the variables are suppose to stand for. If I do need to rely on sarkPCI can I just create a feed the script what it needs to know with a routine that already has what it needs to know hardset with something like
sangHandle
{
$chan=4
$signal=fxo
$DB->set_prop('PCI-1','channel4','fxo')
$DB->set_prop('blah', 'foo','bar')
}
I know there would be a lot more to it than that but I tend to organize my thoughts better with examples. If I knew what was suppose to result from the run of the routine it would make understanding the script much easier. I'm a triple threat when it comes to this because I'm new to SME, Asterisk, and SQL so I'm probably missing the knowledge that would make these things standout.
-
Hi Rezo,
As long as you've taken a copy of PCI before you start (and even if you don't), you'll be fine. The worst thing that can happen is that you'll break it. No big deal. :-) . Let's quickly examine what it does and then attempt to answer your questions...
The main program starts off in a module called modProbe which is actioned as a result of the user hitting the "Probe" button. It issues an lspci and then sorts through the output looking for cards it recognises. Every time it finds one, it issues the correct modprobe to load the driver. You don't need to do anything with these routines, you just need to load the DB record with the card fingerprint and the driver name (which you've already done). So... for you wctdm will be loaded.
Once this phase has finished, the program waits for udev to make the /dev and /proc trees. Then it executes genHandle to parse /proc/zaptel looking at each individual card and building the file entries to generate the zaptel and zapata entries. It also builds the trunk and/or extension entries to complement the zap entries.
Now, as to you questions and example. Yes, you can absolutely hand create the entries in the database with setprop and bypass PCI altogether. You might also take the output from the Sangoma generators and create a little batch routine to plug them into the database (have a look at /etc/selintra/selmerge as an example). You don't have to do it in PCI. The whole point of the Selintra DB is that many programs can add to it independently. Alternatively, as a half-way house, you can create a simple sangHandle in the way you've shown.
We'd like to encourage you to have a go at going the whole hog (in whatever steps you want to take) so that we can incorporate what you've done into the main code. It doesn't matter how many iterative steps it takes and how you do it (as long as you aren't up against a time line from a customer).
In short, if you have the time, then we'd encourage you to give it a go. The quality of your questions shows that you'll be fine. If not then there's no harm done and we will get 'round to it when a paying customer shouts loud enough. :-)
Best
S
-
Hi Light
OK.. This might work for you.
The way in which our config works is that it sets values in the selintra database for which drivers to probe. Here's what you can do...
Install our asterisk rpms and the latest (505) sail rpm.
OK now do...
db selintra setprop wctdm status YES
This will turn on the value to load wctdm gracefully through our code.
Now, provided you have set zaptel.conf and zapata.conf correctly for your card, you can start your asterisk image with...
/etc/init.d/asterisk start
That's it.
Best
S
Hi Selintra, Thanks for answer!
I was quite close to that, since I read the start script asterisk in init.d and I try stuff like: db selintra set wctdm status enabled and yes but no sucess.
I was close, but not enough :) hehe.
I'll do that, the script seems quite complete and a lot better than what I have done so far :D
let U know if it worked
thanks a lot!!.
c-u
Light.
-
At the end of all this my goal would be to go whole hog so that you can add Sangoma to your tested and working list. The 'approved list' will probably have to wait though. :lol:
I did go over the probelines section of sarkPCI and figured out what was happening at that stage. While playing around in the shell console I discovered that wctdm is not a module that is needed for the Sangoma cards. The correct driver to modprobe is wanpipe.ko which will then insmod modules sdladrv.ko, crc-ccitt.ko, zaptel.ko, wanrouter.ko, wanpipe.ko in that order. If you have the optional hardware cancellation as I do you also need to insmod wanec.ko. After wanpipe and the other modules have been loaded you then have to execute a utility that is a part of the Sangoma driver package called `wanconfig`. The full command is `/usr/sbin/wanconfig card wanpipe1 up`. wanpipe1 is a config file created by the Sangoma setup script and represents your first span but I'm not sure when you would need to call up wanpipe2, wanpipe3, etc . It might be for when there is more than one pci card.. but that doesnt apply to me with the A200 since additional cards are bridged to the first one. At this stage /proc/zaptel and /dev/zap should be up. A script `/usr/sbin/wanrouter` can do all of the above steps with one command. It can optionally be set to run ztcfg -vvvv automatically at the end of the script.
In a previous post I pasted the output of the sarkPCI script when it would probe for telephony cards. I had defined it with the property of being a wctdm device with my addition of pci identifiers to selintra-work. What was a little confusing is that it appeared wctdm was bringing the card to life, but actually it wasn't. The /proc/zaptel/ and /dev/zap trees were already present before sarkPCI ran because I had already loaded the sangoma drivers while in the console using `wanrouter start`. This realization led me to playing with modprobe a bit to see just when the zaptel tree would appear. The proper sequence was what I outlined above `modprobe wanpipe; modprobe wanec; wanconfig card wanpipe1 up` I also noticed that if you modprobe wanpipe first and then modprobe wctdm afterwards the second modprobe will return some kind of error. It doesn't seem to harm anything if you load both but I think it is better to do wctdm.ko first in case someone's system actually has both a TDM card as well as a Sangoma card. Seems as though wctdm tries to do something with the sangoma card if its already initialized because wctdm is seeing it at that point as a zaptel device of some kind.
Another thing of interest is that 24 channels are listed when you `cat /proc/zaptel/1` even though my card only has four available channels (presently 2 FXO modules). The A200 card can have extra daughterboards bridged to the primary one. Each board can hold 2 modules, either FXO or FXS. Each FXO or FXS modules provides two channels. The A200 can be maxed out to 24 channels with the addition of 5 daughterboards and 10 fxo/fxs modules. This probably makes the A200 similar to a TDM2400P rather than a TDM400P.
In review of all this information, perhaps some of it superfluous, and your valuable and much appreciated guidance I will try mucking about in sarkPCI with what looks like in a the least some additions to sub probelines, sub genhandle, and a sub sangHandle. Maybe calling it wrtdmHandle would be better?
My main main puzzler, at the moment, is to make a sangHandle routine so that sarkPCI will do the work of passing off the needed information to the rest of your application. What info do I actually need to supply in this routine? I can see that things are being added to the database but I'm not certain what information is being added. I gave a previous example in hopes I could get a little more detail of what needs to happen there. What should the entries I need to make to the database(s) be and how would they be structured?
-
Hi rezo
This looks like good work. Drop me an e-mail and i'll get the necessary file objects etc to you.
jeff@selintra.com
-
excellent! i sent an email out, looking forward to your response :D
-
Hi
I don't know if this is the proper thread for this, but since we all are talking asterisk here :)
I have the asterisk 1.4 working without the selintra package (command line thing :D ), with a TDM400 board.
asterisk works good but I have 2 serious problems.
1) my PSTN Provider 50% of the times doesn't understand what I dial, and I get incorrect number, reorder, you name it, and it's completely random, and watching at the console the dialed numbers are correct.
2) when I talk via the PSTN (using the TDM400 card) I have a high pitch, short duration tone, (about 1Khz, 200ms) it repeats at random intervals from 1 to 6 seconds throughout the entire conversation, I don't have to say that this is most annoying thing!.
this doesn't happens when I talk from 1 sip phone (polycom 301) to another phone (SPA-2102 for ex), only when I go through the TDM card
one other thing, sometimes, when I access the voicemail, the audio eats small portions of the phrases, (like if you shrink the conversation, I don't know how to explain it) may be it's related to the TDM card.
any ideas?
I'm using SME 7.1 , and Asterisk 1.4.1.8-i686
the machine is a ASUS K8V-MX (Via K8M800) with sempron 3000 skt 754, 512MB ddr 400 kingston, digium TDM400 2x FXO modules.
Could it be the chipset?, I don't think that sempron 3000 is not enough to attend 2 PSTN and 6 sip phones, but i could be wrong :)
please help!, I try to tune echo settings, turn on/ off , enable jitter buffer in zapata, but nothing changes.
replaced the motherboard by another one (same model) and power supply, but still the same noise/dial problem.
My next move if I can't find any solution is to complete replace the computer and go to something like intel D945GCCR, but if I can avoid the cost would be great.
thanks
lightman
-
Hi...
You don't say what country you are in or who your telco is so it's a bit difficult to advise you further. However, I would suspect that you may have the card impedance set wrongly for your country.
S
-
Sorry, I'm in Argentina, the telco is Telefonica
I don't think that this is the case as I have an almost exact software configuration (actually this machine is a COPY (I copy the scripts from the working one), same TDM card, the only difference is motherboard, processor and memory, al the rest remain the same of the machine that it's actually working perfectly.
but again, I could be wrong :D
where should I set impedance parameters?, I have never seen those in the zaptel.conf, I thought that it would be a world wide standard (was that naive? :D )
[UPDATE]
Replaced the motherboard with a D954GCNL with core duo processor, and DDR2 memory and the problem seems to stop, so it seems that the problem is that DAMN TDM400 card that doesn't like cheap motherboards :lol:
however D954GCNL is not well supported in centos 4.5 as a result, I have lots of problems with the nic cards, so I have to switch to another mobo.
in the mean time if you have any tune/mod i can do to test in the machine that has problems would be great.
also I've tested switching from ATA to SATA drives, the annoying high pitched tones reduced but they are still present when using the cheap mobo (via + sempron 3000).
thanks
Light
-
Hi Light
It looks as tho' you've proved beyond doubt that it is indeed a hardware issue, but it isn't one we've ever seen. But the's not surprising, we pretty much standardize on Intel chipsets and CPU's for our mid-range stuff and VIA Nehemiah for our embedded systems and we don't have problems.
To set the impedance for your board you must make a small change to /etc/init.d/asterisk...
Find the following code at or around line 124
/sbin/modprobe wctdm # opermode=$COUNTRY
Change it to...
/sbin/modprobe wctdm opermode=ARGENTINA
Stop asterisk and unload wctdm and zaptel with rmmod. Alternatively, if you are unfamiliar with lsmod/rmmod, simply reboot your machine.
As to other things you can do with the TDM...
You can tune it to your phone lines by running fxotune which will run a series of echo tests and place the output into a file which can be loaded at run-time. SAIL can do all of this for you. Simply press STOP in PCI Cards and the fxotune buttons will appear. Press tune and go make a cup of coffee (it takes a while to run).
You can run OSLEC or HPEC advanced echo cancellation. Both are excellent. If you grab and install smeserver-asterisk-zappri-MPP-1.2.13-1.i686.rpm, then this rpm has OSLEC fitted as standard.
For those interested, the valid list of "opermode" settings for the TDM400/800/2400 is...
FCC
TBR21
ARGENTINA
AUSTRALIA
AUSTRIA
BAHRAIN
BELGIUM
BRAZIL
BULGARIA
CANADA
CHILE
CHINA
COLUMBIA
CROATIA
CYRPUS
CZECH
DENMARK
ECUADOR
EGYPT
ELSALVADOR
FINLAND
FRANCE
GERMANY
GREECE
GUAM
HONGKONG
HUNGARY
ICELAND
INDIA
INDONESIA
IRELAND
ISRAEL
ITALY
JAPAN
JORDAN
KAZAKHSTAN
KUWAIT
LATVIA
LEBANON
LUXEMBOURG
MACAO
MALAYSIA
MALTA
MEXICO
MOROCCO
NETHERLANDS
NEWZEALAND
NIGERIA
NORWAY
OMAN
PAKISTAN
PERU
PHILIPPINES
POLAND
PORTUGAL
ROMANIA
RUSSIA
SAUDIARABIA
SINGAPORE
SLOVAKIA
SLOVENIA
SOUTHAFRICA
SOUTHKOREA
SPAIN
SWEDEN
SWITZERLAND
SYRIA
TAIWAN
THAILAND
UAE
UK
USA
YEMEN
-
hi selintra,
I've sent a few emails over the last couple of weeks to the email address you posted but havent received a reply yet. Not sure if they weren't delivered properly or if you havent had a chance to get back to me. If possible please send the info you wanted to share with me to tjojunk-sme@yahoo.com
-
HI Rezo,
We sent an intial reply. I can only apologies if you didn'r receive it. We're still working on a best fit solution for you. Reply in a few days
Best
S