Re: [freetel-oslec] can't use oslec on bridged pri?
Free software and hardware for telephony
Brought to you by:
drowe67
Menu
▾
▴
Re: [freetel-oslec] can't use oslec on bridged pri?
|
From: Scott G. <sc...@st...> - 2008-05-21 23:15:29
|
I have not as yet been able to identify the problem. I'm currently trying to find the time to get a test system up and running so that I can look into it further. I had done everything I could think of including a full update of the trixbox system - but ran out of time and didn't want to try my customer's patience any more. On Wed, May 21, 2008 at 7:01 PM, Juan Manuel Coronado Zúñiga < jua...@gm...> wrote: > > Hi David and Scott > > Did you finally found a way to solve this issue? > > I'm experiencing same behavior with an R1T1 over an E1 PRI line (oslec > loaded but /proc/oslec/info showing all zeros when Zap channels are > bridged): > > asteriskbox# cat /proc/oslec/info > channels.......: 4 > length (taps)..: 128 > mode...........: [59] |ADAPTION|NLP|CLIP|TXHPF|RXHPF| > Ltx............: 0 > Lrx............: 0 > Lclean.........: 0 > Lclean_bg......: 0 > shift..........: 0 > Double Talk....: 0 > Lbgn...........: 0 > MIPs (last)....: 0 > MIPs (worst)...: 0 > MIPs (avergage): 0 > > I'm using Zaptel 1.2.22.1 and OSLEC 1.0. Have echotrainning disabled and > echocancelwhenbridged=no > > Here's the relevant information (according to previous messages sent by > David Rowe): > > asteriskbox:~# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Pentium(R) 4 CPU 3.00GHz > stepping : 3 > cpu MHz : 2992.715 > cache size : 2048 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 3 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm > constant_tsc up pni monitor ds_cpl est cid cx16 xtpr > bogomips : 5990.54 > > When running dmesg, these are the parts related to OSLEC: > > zaptel: Unknown symbol oslec_echo_can_traintap > zaptel: Unknown symbol oslec_echo_can_free > zaptel: Unknown symbol oslec_echo_can_update > zaptel: Unknown symbol oslec_echo_can_create > zaptel: no version for "oslec_echo_can_traintap" found: kernel tainted. > > asteriskbox:~# modinfo zaptel > filename: /lib/modules/2.6.18-5-686/misc/zaptel.ko > author: Mark Spencer <mar...@di...> > description: Zapata Telephony Interface > license: GPL > version: 1.2.22.1 > vermagic: 2.6.18-5-686 SMP mod_unload 686 REGPARM gcc-4.1 > depends: crc-ccitt > srcversion: 862B2D2F786E59F6491C7C1 > parm: deftaps:int > parm: debug:int > > Still don't have samples of the echo signal but hope to take the some very > soon. > > Best regards, > > -- > Juan M. Coronado Z. > > > On Thu, May 8, 2008 at 6:02 PM, David Rowe <da...@ro...> wrote: > >> Hi Scott, >> >> 1/ Could you please do a "cat /proc/cpu" and post the results. >> >> 2/ After starting a call pls do a "dmesg" and post the results. This >> will let us check the start up messages from zaptel and Oslec. >> >> 3/ What version of Zaptel are you using? >> >> 4/ There is a test I can think of. The "sample" utility, as explained >> here: >> >> http://www.rowetel.com/ucasterisk/oslec.html#sample >> >> samples the signals either side of the echo canceller. Could you please >> collect some samples and email them to me (or the list). If these >> samples are non-zero, its suggests a problem inside Oslec, or in the >> code just around it that feeds samples to Oslec. >> >> 4a/ We had a similar problem with certain CPUs a few months ago, do to >> with measuring the clock cycles in oslec_wrap. Could be the same issue. >> A easy way to check that is to comment out this line in oslec_wrap.c, >> oslec_echo_can_update(): >> >> u32 start_cycles = 0; >> >> if (ec->ec == mon_ec) { >> // start_cycles = cycles(); >> } >> >> Then build oslec.ko, insmod again etc and test. >> >> 5/ As a fall back is there a way I can access yr machine and make a few >> tests calls, inspect the source etc? You can email me off list about >> this - I have some time next week to take a look at it. >> >> Cheers, >> >> David >> >> On Thu, 2008-05-08 at 00:48 -0400, Scott Griepentrog wrote: >> > I've now updated oslec-modules and still the same zeros >> > for /proc/oslec/info and still bad echo. >> > >> > Here is current versions: >> > >> > [pbx src]# yum list |fgrep oslec >> > oslec.i686 0.1-22.1345 >> > installed >> > oslec-modules.i686 0.1-22.1345.2.6.18_53. >> > installed >> > [pbx src]# yum list |fgrep zaptel >> > zaptel.i686 1.4.7-13.3259 >> > installed >> > zaptel-modules.i686 1.4.10-1.2.6.18_53.1.4 >> > installed >> > >> > I'm trying a half-baked install of asterisk to get includes to be able >> > to compile oslec from svn next. >> > >> > On Thu, May 8, 2008 at 12:04 AM, Scott Griepentrog <sc...@st...> >> > wrote: >> > Here is CPU info: >> > >> > May 7 06:37:44 trixbox1 kernel: Initializing CPU#0 >> > May 7 06:37:44 trixbox1 kernel: CPU 0 irqstacks, >> > hard=c0743000 soft=c0723000 >> > May 7 06:37:44 trixbox1 named[1826]: found 1 CPU, using 1 >> > worker thread >> > May 7 06:37:44 trixbox1 kernel: CPU: L1 I Cache: 64K (64 >> > bytes/line), D cache 64K (64 bytes/line) >> > May 7 06:37:44 trixbox1 kernel: CPU: L2 Cache: 512K (64 >> > bytes/line) >> > May 7 06:37:44 trixbox1 kernel: Intel machine check reporting >> > enabled on CPU#0. >> > May 7 06:37:44 trixbox1 kernel: CPU0: AMD Athlon(tm) 64 >> > Processor 4000+ stepping 03 >> > May 7 06:37:44 trixbox1 kernel: Brought up 1 CPUs >> > [pbx ~]# >> > >> > >> > Box is "Rhino Ceros 2": AMD AM2 4000+ Athlon CPU (Gigabyte >> > GA-M61P-S3) >> > see: http://www.rhinoequipment.com/Ceros.html >> > >> > And this is what yum list says about oslec installed: >> > oslec.i686 0.1-22.1345 >> > installed >> > oslec-modules.i686 >> > 0.1-14.1229.2.6.18_53. installed >> > >> > >> > I have not as yet tried svn version, since installing >> > asterisk-devel (via yum) forces me to upgrade asterisk & >> > zaptel too, which Rhino cautions against doing, and quite >> > frankly scares me trying to do on a live customer system. >> > >> > I did however just realize that oslec-modules is old (didn't >> > realize there was two rpm's) and will update that and advise. >> > >> > >> > >> > On Wed, May 7, 2008 at 11:43 PM, David Rowe >> > <da...@ro...> wrote: >> > Hi Scott, >> > >> > > The echo delay I measured is about 200 ms, but >> > that's after going >> > > across a SIP connection over open internet. I'm not >> > at the customer >> > > site to do a local echo test and confirm. I'll try >> > to get a recording >> > > from cmd line directly off the zap. It is however >> > very noticeable. >> > > It's bouncing off the far end analog loop. Do you >> > think that Oslec >> > > can deal with this situation? >> > >> > >> > It depends where the delay is. Part of that 200ms >> > will be in your sip >> > phone, * sip stack etc. If the delay between the >> > zaptel driver and the >> > echo is < 32ms, you are in luck. If the delay is > >> > 32ms, but is "pure" >> > delay, you could possibly hack zaptel to remove it. >> > But this is very >> > site specific. >> > >> > If the echo path is something like: >> > >> > Zaptel - PRI - T1 line - far end hybrid - far end >> > phone >> > >> > You may be in luck. >> > >> > > I'm also confused by the /proc/oslec/info numbers >> > being all zero. >> > > It's obvious that the oslec_wrapper is being >> > activated, since it's >> > > only showing me the info when I have an active >> > call. But my >> > > understanding from the samples on the website is >> > that there should be >> > > some non-zero indication of processing the audio if >> > the echo >> > > cancellation itself is active. >> > >> > >> > Yes, I agree - I can't explain why the numbers are >> > zero. It's like the >> > echo can has been created, but no audio is being >> > passed to it. >> > >> > What processor and oslec version are you using? Use >> > SVN if you can. >> > There was a bug with certain CPUs with earlier >> > versions of Oslec that >> > muted audio. >> > >> > - David >> > >> > >> > -- >> > Free Telephony Project >> > open embedded IP-PBX hardware and software >> > http://www.rowetel.com/ucasterisk >> > >> > >> > >> > >> > >> > >> > >> > -- >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > Scott Griepentrog >> > www.StG.Net >> > 317-644-2228 >> > sc...@st... >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > "Computers make it easier to do a lot of things, but most of >> > the things they make it easier to do don't need to be done." >> > - Andy Rooney >> > >> > >> > >> > >> > -- >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > Scott Griepentrog >> > www.StG.Net >> > 317-644-2228 >> > sc...@st... >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > "Computers make it easier to do a lot of things, but most of the >> > things they make it easier to do don't need to be done." >> > - Andy Rooney >> -- >> Free Telephony Project >> open embedded IP-PBX hardware and software >> http://www.rowetel.com/ucasterisk >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save $100. >> Use priority code J8TL2D2. >> >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> freetel-oslec mailing list >> fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freetel-oslec >> > > > > -- > "I know what hell is. It´s not lakes of burning oil, or brimstone and > devils poking you in the ass with pitchforks. Hell is not knowing." > > Ted McKeever. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Scott Griepentrog www.StG.Net 317-644-2228 sc...@st... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done." - Andy Rooney |