Well, the most important thing is that it now works.
----
Andre Courchesne - Consultant
http://www.net-forces.com
Phone: (514) 667-8448
MSN: [email protected]
Skype: VoipForces
L'information contenue dans le présent document est la propriété de
Andre Courchesne. Et est divulguée en toute confidentialité. Cette
information ne doit pas être utilisée, divulguée à d'autres personnes ou
reproduite sans le consentement écrit explicite de Andre Courchesne.
The information contained in this document is confidential and property
of Andre Courchesne. It shall not be used, disclosed to others or
reproduced without the express written consent of Andre Courchesne.
Marc Carrafiello wrote:
OK, well, a complete and total upgrade to the newest linux kernel, dahdi,
libpri, wanpipe and Asterisk cleared it all up. Still using Asterisk v1.4
(not 1.6), but at least I've jumped from zaptel to dahdi. :)
I'd like to say that I don't want to experience that upgrade again. I must
have compiled&fiddled with dahdi/wanpipe 100 times before "wanrouter
hwprobe" finally showed my card and I could actually run "wancfg_dahdi".
Andre: I did try turning off echo cancellation (with no help to the problem)
before deciding to throw caution to the wind and mangle my production
system.
-Marc
-----Original Message-----
From: Marc Carrafiello [mailto:[email protected]]
Sent: Wednesday, April 22, 2009 4:45 PM
To: 'Andre Courchesne'
Cc: [email protected]
Subject: RE: [on-asterisk] DTMF "5" & "#" are bad?!?
Andre,
Thanks for the reply. Answers nested below.
-Marc
-----Original Message-----
From: Andre Courchesne [mailto:[email protected]]
Sent: Wednesday, April 22, 2009 3:51 PM
To: Marc Carrafiello
Cc: [email protected]
Subject: Re: [on-asterisk] DTMF "5" & "#" are bad?!?
Hi Marc,
Have you tried disabling the Sangoma hardward echo canceler?
No, but I'm willing to give it a shot later today.
I did try enabling the hardware DTMF option in
/etc/wanpipe/wanpipe1.conf
(TDMV_HW_DTMF = YES) Previously it was off (I believe the
default is
off). No difference.
Also make sure that your switch settings are ok
(switchtype). If you
are set to NI1 or NI2, try dms100.
I'm actually already using a dms100 setting, since it's the
Clarkson ON
switch.
Also does w1g1 gives your errors when you do ifconfig ?
No errors at all. 'ifconfig w1g1' is all clear. Same for
'wanpipemon -i
w1g1 -c so' and 'wanpipemon -i w1g1 -c sc'. Also, this was
my second Bell
techniciain visit. The first did confirm that my connection
quality was
clean and working well. The tech today said the same thing.
I was told that once the call is connected, DTMF is inband.
Which makes
sense, as when I am tracing the w1g1 interface, the packets
stop flowing
once the call connects, no matter how much I mash on the
keypad. So the
problem could easily be Asterisk itself and not my Sangoma card or the
PRI?!?!
----
Andre Courchesne - Consultant
http://www.net-forces.com
Phone: (514) 667-8448
MSN: [email protected]
Skype: VoipForces
L'information contenue dans le présent document est la propriété de
Andre Courchesne. Et est divulguée en toute confidentialité. Cette
information ne doit pas être utilisée, divulguée à d'autres
personnes ou
reproduite sans le consentement écrit explicite de Andre Courchesne.
The information contained in this document is confidential
and property
of Andre Courchesne. It shall not be used, disclosed to others or
reproduced without the express written consent of Andre Courchesne.
Marc Carrafiello wrote:
Good Afternoon Everyone.
OK, I'm stumped. I've run into the problem where my pbx
doesn't send a good
sounding 5 or # over my PRI. If I dial extension ->
extension, the tones
are perfect. As soon as I dial out from phone -> pstn
(over the PRI), the
tones are bad. By "bad", you can hear them "out of tune"
for lack of a
better description. Just 5 and #, all other tones are fine.
All searching so far has found discussions of problems with
inbound DTMF
recognition, and I have none of those problems. It's been
tough trying to
find a starting point to further diagnose my troubles, so any
help/experience the group has to offer would be greatly
appreciated.
Related to #3 below, I'll hand out the phone number to
anyone interested
(off list) to hear the bad tones for yourself.
Thanks in advance for any help,
-Marc
---
Here's what I got and what I tried:
Asterisk 1.4.18
libpri 1.4.3
zaptel 1.4.8
Sangoma Wanpipe v3.2.3
Sangoma Wanpipe v3.3.15
Gentoo Linux 2.6.23
Linksys SPA942's
Sangoma AFT-101D
Bell Canada PRI
1. Recompiled the system (I'm running from source)
2. Upgraded Sangoma wanpipe drivers to newest version
3.3.15, recompiled the
system
3. Confirmed it's not the phones by making a spare pilot
perform an Answer()
then SendDTMF(1w2w3w4w5w6w7w8w9w0w#w*). It picks up,
cycles through each
tone, with the 5's and #'s bad.
4. Bell Tech came in, plugged a tester into the rx/tx plugs
on the blue T1
box mounted to my wall and verified the tones coming out of
Asterisk are
bad.
5. Note: this just started happening 4 (or so) weeks ago.
As you can see
from the linux kernel & Asterisk versions, I haven't
touched my stable
Asterisk system since this time last year. I occasionally
update the Linux
system, and I'm currently looking at my update logs to see
what was upgraded
on March 13th (my last system update). All I can see is
alsa-utils,
alsa-lib, alsa-headers, sox, mpg123, lame, but I don't know
how they could
be causing this.
6. And all the prerequisite usual stuff is OK. No Asterisk
errors, zap
debug doesn't show any problems, wanpipe interface counters
are clear,
wanpipemon card stats are clear. By "clear", I mean all
"bad" values are 0,
currently with 474 hours of uptime.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]