[asterisk-users] Poor VoIP voice quality in one direction from three providers

2009-10-22 Thread Robert L Mathews
We currently use asterisk 1.4.x with two Zaptel cards connected to POTS 
lines. So we make outbound calls from their softphones (using ulaw 
format), which go over a dedicated DSL line to the asterisk server in 
our office, which then converts the calls to POTS.

This all works fine, assuming there aren't any unusual problems. It 
sounds as good as POTS on both ends.

However, we don't want to maintain the DSL line or deal with the hassles 
of analog/digital conversion any more. So we want to switch to a 
reliable VoIP provider and move the asterisk server to one of our 
colocation data centers.

We've tried getting test accounts with three VoIP providers: FlowRoute, 
CallCentric, and Vitelity. In our tests, outbound calls now go from 
softphones - asterisk - VoIP provider - outside world. We use ulaw 
all the way through.

But with all three providers, we see a curious thing: The audio quality 
in the direction from our softphones to the outside world still sounds 
as good as POTS, but the audio quality in the inbound direction (outside 
world - VoIP Provider - asterisk - softphone) is noticeably worse. It 
sounds overcompressed or slightly robotic somehow, with a decrease 
in dynamic range. It's not lagged or echoey; it just sounds like it's 
maybe using a crappier codec than ulaw, in that direction only.

I'm baffled by this. Both legs of the calls show as Format: 
  0x4 (ulaw) in sip show channel. Testing the first provider, I 
just assumed that their analog-digital conversion was inferior to what 
the Zaptel cards offer (i.e., that they were injecting inferior sound 
quality into their ulaw connection)... but we're getting exactly the 
same results with all three providers, which makes me think it's us.

Why might this happen? Is there any possible reason other than all 
three of the VoIP providers are decreasing the audio quality before 
injecting it into the ulaw stream?

-- 
Robert L Mathews

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Sip phones how to dial a # sign?

2005-02-16 Thread Robert L Mathews
C F [EMAIL PROTECTED] wrote:
Use the latest stable or CVS HEAD and modify features.conf. You can
change it there.
FYI, only CVS HEAD (not stable) supports the new features.conf options.
--
Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Is there a Caller ID issue in the latest CVSStable

2005-02-14 Thread Robert L Mathews
C F [EMAIL PROTECTED] wrote:
I your case the problem is with the grandstream, the GS will not
display callerID correctly, take out the name from the callerid string
like this:
exten = ${EXTEN},PRI,SetCallerID(${CALLERIDNUM})
Actually, Tony Mountifield pointed out that the problem is a bug in CVS 
stable:

  http://bugs.digium.com/bug_view_page.php?bug_id=0003557
(Thanks, Tony!)
With this bug fixed, the Grandstream phones work fine even with the 
caller ID name present. They don't display the name, but they do display 
the number properly. The problem I was mentioning made it not even 
display the number correctly, on any SIP phone.

--
Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Is there a Caller ID issue in the latest CVSStable

2005-02-11 Thread Robert L Mathews
Nicol?s Gudi?o [EMAIL PROTECTED] wrote:
Paul, 1.0.5 stable suffers from caller id issues as well, at least for
SIP channels. What fixed things for me was swapping in app_dial.c from
1.0.2 stable (didn't try others). You could also just diff app_dial.c
between versions to find the problem but I took the lazy way out the
first time around.

Drumkilla reverted the callerid changes on the latest stable (thanks
Russell!). You will be fine if you checkout stable from CVS now.
Hmmm; I think I'm still having problems with it, using a completely 
fresh checkout and compile:
Connected to Asterisk CVS-v1-0-02/11/05-17:34:08

I have two Zap FXS lines and two SIP phones, and:
- Zap channel to Zap channel, caller ID works (displays correctly on the 
analog phone display).
- SIP phone to Zap channel, caller ID works.
- SIP phone to ZIP phone, caller ID does NOT work (Grandstream phone 
displays Err).
- Zap channel to SIP phone, caller ID does NOT work.
- Incoming Free World Dialup calls to Zap channel extension, caller ID 
works.
- Incoming Free World Dialup calls to SIP phone extension, caller ID 
does NOT work.

So it seems that asterisk stable, as of today, does not send correct 
caller ID on calls that end up on SIP phones, unless I'm doing something 
boneheaded (although I used almost-identical config files on 1.0.2 with 
no trouble).

A tcpdump shows that asterisk is sending this in the SIP INVITE header 
to the phone:

From: asterisk sip:[EMAIL PROTECTED];
(IP address obscured; it's correct in the original.) But somehow 
asterisk appears instead of the correct caller ID. Wasn't that the bug 
other people were seeing that the stable update was supposed to fix? 
Have I missed something obvious?

--
Robert L Mathews, Tiger Technologies   http://www.tigertech.net/
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


[Asterisk-Users] TDM400P FXS works only if two lines are off hook?

2005-02-06 Thread Robert L Mathews
I have a TDM400P with one FXO module and two FXS modules in it. I also 
have a Wildcard X101P.

After trying hard to get things working on various Intel computers, but 
having echo problems that made it not really usable, I decided to try it 
on some older PowerPC (Macintosh) hardware running Yellow Dog Linux.

Things started off smoothly. Both zaptel and asterisk seemed to compile 
okay, and both cards are detected:

kernel: Found a Wildcard FXO: Wildcard X101P
kernel: PCI: Enabling device 00:0f.0 (0004 - 0007)
kernel: Freshmaker version: 63
kernel: Freshmaker passed register test
kernel: Module 0: Installed -- AUTO FXO (FCC mode)
kernel: Module 1: Installed -- AUTO FXS/DPO
kernel: Module 2: Installed -- AUTO FXS/DPO
kernel: Module 3: Not installed
I can dial out from a SIP phone through the FXO ports on the X101P or 
the TDM400P (with almost no echo), so some things are basically working.

However, the FXS lines didn't work properly: there is no audio in either 
direction. If I call these channels from a SIP phone, they do ring 
properly, and if I pick up a phone connected to them, the console 
correctly shows, for example:

  -- Starting simple switch on 'Zap/3-1'
But there is no dialtone and no voice audible in either direction when 
they are called. Outgoing calls from these FXS channels don't work; 
pressing numbers on the keypad beeps but has no other effect.

Then by accident I picked up both FXS lines at the same time, and both 
of them work perfectly! I get dialtones, I can dial and make calls with 
them, audio works in both directions -- nothing wrong at all.

So as long as they're both off the hook at the same time, everything is 
fine. But as soon as I hang up either one of the lines, the sound on the 
other line will *also* go dead again within a second.

A little more experimentation: having just one FXS module on the TDM400P 
(removing the other) doesn't work at all. The only way the FXS lines 
work is with both FXS modules installed and off hook simultaneously.

This problem occurs with the released versions (zaptel 1.0.4 with the 
wcfxs driver and asterisk 1.0.5), and with cvs head (using the wctdm 
driver).

Does anyone have any idea why this would happen, and how I could fix it?
--
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Hardware for Asterisk

2004-01-16 Thread Robert L Mathews
At 1/16/04 7:25 AM, Andrew Kohlsmith [EMAIL PROTECTED] 
wrote:

That's pure bullshit -- I use software RAID *specifically* because I value 
my data.  I don't want to buy two hardaware RAID controllers to have one 
sit on the shelf just in case the first dies... and if the second dies 
you're SOL because they've lasted long enough that they're no longer 
available.  Linux software RAID is available on any Linux system and if the 
system blows up I can put the drives in another system and *not* worry 
about it not being detected.

Yeah, I couldn't agree more.

We originally thought hardware RAID was the way to go, and we bought a 
couple of fully loaded Dell PowerEdge 2550s with SCSI hardware RAID 5 
arrays at about $4500 a pop. We also bought a PowerEdge 600SC for around 
$900 with lots of disk space to use as a network backup machine (backing 
up the 2550s) with Linux software RAID 5. I've also had a crappy old 
desktop machine running Linux software RAID 1 for a couple of years.

It turns out that the software RAID is just as reliable (more so, in fact 
-- we have had a number of lockups on the 2550s that appear to be due to 
the hardware RAID subsystem locking up, and the software RAID machines 
have never done that, even though the backup server does more disk I/O 
than the others). The software RAID on the 600SC is faster than the 
hardware RAID in bonnie tests.

In addition, the Dell PowerEdge mailing lists are full of people with 
horror stories about their hardware RAID systems -- if that dies on mine, 
I'm screwed until I can convince Dell to come out and fix it (which they 
often won't do until they've spent hours on the phone with you trying 
various things).

We should have simply bought 4 600SCs (instead of 2 2550s and a 600SC), 
using one as a hot standby, and saved ourselves around $6000. In fact, 
we're planning on moving to that and selling the 2550s on eBay to improve 
our overall reliability. If the power supply, motherboard or RAM of a 
600SC dies, we can easily move the disks to the spare machine and be back 
up within a few minutes without relying on anyone else. In the worst case 
(RAID corruption/machine catches on fire), I'm still going to be okay, 
because I can restore from backups in a couple of hours.

The key thing to me is that at no point do we have to rely on any other 
company to get things up and running again, which is far more important 
than any putative risk of data corruption from software RAID (which I 
have not seen even under very heavy disk loads, and which I think is 
pretty much a myth these days; look at the Dell PowerEdge mailing lists 
if you think hardware RAID is more reliable -- those stories of hardware 
RAID problems from real users have scared me to the point that I'll never 
consider buying any sort of proprietary disk subsystem again).

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

I am not able rightly to apprehend the kind of confusion of
 ideas that could provoke such a question.  -- Charles Babbage

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Asterisk behind LinkSys NAT Routing

2003-11-04 Thread Robert L Mathews
At 11/3/03 6:57 PM, Anthony Wood [EMAIL PROTECTED] 
wrote:

Internals can use the IP address of the NAT box as the Asterisk Server
IP and then it should work.

This doesn't work on my NAT box, unfortunately. Devices behind the NAT 
can't connect to the public IP address and talk to other devices behind 
the NAT.

Don't know why (cheapo NAT box, most likely; it's part of my DSL modem), 
but I believe this situation is fairly common.

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Asterisk behind LinkSys NAT Routing

2003-11-03 Thread Robert L Mathews
At 11/3/03 10:00 AM, Martin Pycko [EMAIL PROTECTED] wrote:

 Is externip and new parameter??

It's new. It prevents asterisk from putting the private IP in the messages
that asterisk sends with SIP.

Does it take an IP address, like externip=1.2.3.4? And does it then 
force the SIP messages for that channel to use the externip value 
instead of the server's local IP address?

If so, that's useful; it will help people who know in advance that a 
certain phone is on one side of a NAT or the other.

However, it would be nicer still if it could fix the SIP messages only 
when necessary, using a subnet mask or STUN, as has been proposed.

The reason is that hard-coding an IP address to use when communicating 
with a certain client means you can't have a phone in an office (on the 
same side of the NAT as Asterisk) during the day, then take the phone 
home at night (on the other side of the NAT) and have it work without 
changing sip.conf.

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] Asterisk behind LinkSys NAT Routing

2003-11-03 Thread Robert L Mathews
At 11/3/03 2:41 PM, Martin Pycko [EMAIL PROTECTED] wrote:

It's not for phones, it's for asterisk behind a NAT.

My apologies; I'm not making my question clear.

I realize this option is for Asterisk behind a NAT, but of course 
Asterisk uses this parameter to talk to SIP clients (which I referred to, 
perhaps too specifically, as phones), and that's what I meant.

In other words, Asterisk might be talking to SIP phones on either side of 
the NAT. A given SIP phone acting as an extension may be on the same 
private network as Asterisk, or it may be on the other side of the NAT 
(out on the public Internet, possibly even behind its own NAT on the 
other end).

Imagine I have both Asterisk and a SIP phone on my local office network 
using private IP addresses, and I also have a second SIP phone that is in 
another location, at someone's home office on the public Internet.

The externip=a.b.c.d doesn't help in this situation, because it forces 
Asterisk to use the external IP address in all cases, which breaks the 
functionality for local phones. That is, the new option presumably makes 
it possible to have *all* your SIP phones on the other side of the NAT 
from Asterisk, but you can't some phones on both sides. (Indeed, I just 
tried it, and using externip=something prevents SIP phones on the same 
private network as Asterisk from working.)

In Bug ID 104, a patch was suggested that takes the netmask into 
effect and makes the right decision for phones on either side of the NAT. 
However, the code that was added for externip in the current CVS isn't 
that patch; it's just a way of giving me a choice of having SIP phones on 
the outside of the NAT working, or having SIP phones on the inside of the 
NAT working, but not both at the same time.

I guess I'm curious why the hard-coded global option was used, because it 
doesn't really solve the problem in the general case. The whole trouble 
with NAT is that Asterisk may need to use a different IP address 
depending on the IP address of the SIP client it's communicating with, 
and that address needs to be determined on the fly. In a perfect word, 
this would all be handled by magic so it required no configuration (e.g., 
STUN), but the patch in 104 would at least allow phones on both sides 
of the NAT to work with a small amount of configuration, which isn't 
possible now with the CVS code.

Thanks again for the hard work you're putting in to Asterisk!

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] RX gain TX gain

2003-10-31 Thread Robert L Mathews
At 10/30/03 11:36 PM, Dan [EMAIL PROTECTED] wrote:

Have you tried to use values like 0.5 or 0.8?

Hmmm, good suggestion, but it didn't help, unfortunately.

However -- I did some more testing, and found that using extremely large 
negative values such as -20.0 does make it noticeably quieter (I hadn't 
tried anything below -10.0 before). So I can confirm for others having 
such trouble that negative values do work, but you might need to make 
them bigger than you think.

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [Asterisk-Users] RX gain TX gain

2003-10-30 Thread Robert L Mathews
At 10/30/03 12:21 PM, Jared Smith [EMAIL PROTECTED] wrote:

It's my understand that they are db levels.  (And, if I remember my
electrical engineering classes from college, a 3db increase effectively
doubles the volume.)

As a slight aside on the subject of gain

It seems that most people asking about RX/TX gain want to increase their 
volume. I have the opposite problem: I have a Digium TDM10B FXS card that 
generates sound far too loud (in the earpiece) with the RX gain set at 
0.0, or commented out.

That is, routing an analog line = X101P = Asterisk = TDM10B = analog 
phone is MUCH louder than if I just plug the same phone into the same 
analog line directly.

Some people have suggested that using a negative gain will make it 
quieter, but I haven't had any luck with this. I *can* make it even 
louder by increasing the gain -- if I use rxgain = 10 on the TDM10B, 
for example, it's so loud it sounds like the phone is going to explode -- 
but using things like rxgain = -3.0 or rxgain = -10.0 doesn't make it 
any quieter. I can't get it below the rxgain = 0 value.

I've been meaning to dig around the source and see what's up, but since 
it's being discussed... anyone know how to use rxgain to lower the 
earpiece volume?

-- 
Robert L Mathews, Tiger Technologies  http://www.tigertech.net/

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users