I'm in the midst of what would be a comedy of errors if it weren't so
annoying. I bought a new Grandstream HT701 VoIP terminal adapter from
a guy on eBay who is apparently an official Grandstream reseller. It
doesn't work. The guy I bought it from (whose support ends at "nobody
else has that problem") pointed fingers at Grandstream, whose support
has been, well, impressive and not in a good way.
I've done packet traces on the LAN with the box, I know what the
problem is: there's something wrong with the box so it doesn't respond
to the Proxy-Authenticate: challenge from my SIP provider. I know the
challenge is OK, I have an old VoIP phone of theirs which works fine,
on the same LAN with the same provider and the same configuration.
Unfortunately, Grandstream's support staff is apparently unfamilar
with packet traces and networks, and after a variety of obviously
wrong diagoses (no, it's not a NAT problem, you can see the responses
coming back from the remote system, etc.) seems unable to understand
that a packet trace is, you know, a trace of the actual packets that
have passed by the device's NIC. There's more, but you get the idea.
Does anyone else here use their equipment? Is there any way to find
support for this stuff who can actually provide support?
My experience: we called them the princess phones. They were useful for
people who wanted really big buttons, and didn't care if the phones worked
half the time.
I wouldn't use them unless you have a specific reason to.
Strangely enough, "Cisco" SPA-112. Formerly known as Sipura, then
Linksys. I do not know if they move to Belkin as part of the Linksys
sale.
Just got a Sipura SPA-1001. It also has registration problems. Hmmn.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
We used AudioCodes at my last gig - the MP202B, specifically. They were decent, from what I remember. It's been several years since I've worked on them, so don't take this as an endorsement. I'm just adding another possible vendor name/product to the pool.
Have you played around with the T.38 support on the SPA-1XX line? Historically, it has been difficult to find a reasonably-priced, bare-bones (1 FXS, no built-in router) ATA that also happens to do T.38 well. PAP2T had no T.38 support at all.
SPA-112 price looks good, so I'm wondering what the catch is.
As another reference point, I really liked the sipura atas, they were my
personal favorite as far as the gear we used. I don't know how well that
translates to after the linksys takeover though, as I haven't done voice
gear in a few years.
Have you played around with the T.38 support on the SPA-1XX line?
Historically, it has been difficult to find a reasonably-priced,
bare-bones (1 FXS, no built-in router) ATA that also happens to do
T.38 well. PAP2T had no T.38 support at all.
T.38 support was the primary reason for choosing that model. Before the
SPA-112, we used SPA-2102 which had the major disadvantage of being a
router. It meant we had to log in to the box to enable provisioning on
the WAN interface (and just hope that no one plugged a cable into the
LAN).
The SPA-112 is a much better solution.
SPA-112 price looks good, so I'm wondering what the catch is.
So far only one bug found: Sudden 90% fax call failure rate in one
specific setup with 4 ATAs, whereas all the ATAs used by other customers
continued to work fine. Problem solved with firmware 1.3.1.
As another reference point, I really liked the sipura atas, they were my
personal favorite as far as the gear we used. I don't know how well that
translates to after the linksys takeover though, as I haven't done voice
gear in a few years.
Got a Sipura SPA-1001, can't get it to work, similar issues.
I found that my router had SIP ALG turned on, turned it off,
now the Grandstream mostly works. Sigh. Didn't help the
Sipura, though.
As another reference point, I really liked the sipura atas, they were my
personal favorite as far as the gear we used. I don't know how well that
translates to after the linksys takeover though, as I haven't done voice
gear in a few years.
Got a Sipura SPA-1001, can't get it to work, similar issues.
I found that my router had SIP ALG turned on, turned it off,
now the Grandstream mostly works. Sigh. Didn't help the
Sipura, though.
If behind NAT: On the sipura/linksys ATA, admin login, switch to
advanced view, SIP tab. Ensure the following "NAT Support Parameters"
are enabled.
Handle VIA received, Handle VIA report, Insert VIA received, Insert VIA
rport, Substitute VIA Addr, Send Resp To Src Port. I never use a STUN
server, I've found it causes too much delay in answering a call.
It might be in a slightly different place than described above on the
newer SPA-1001/112, but the options are the same.
Man is this strange: when I set my DHCP server to assign the Sipura box a fixed IP address, the VoIP box didn't work. When I let it assign an address out of the pool, it did work. Same device, same LAN, same /24 subnet, same ISC DHCP server. The Sipura has a web server, so I could confirm that in both cases the IP, subnet mask, DNS, and gateway were what the DHCP server assigned.
I also have a more modern Linksys 2102 configured by a VoIP provider, same DHCP strangeness. Beats me.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
So what happens if you now configure the DHCP server so that the (working) IP is removed from the pool, and have the DHCP server explicitly assign it to the device instead? Does it still work? What if you turn the DHCP client off in the ATA, and try to manually assign the ATA both the fixed IP that didn't work, and the IP that does?
There has to be a difference somewhere, whether it is in the DHCP payload, the way a router or NAT engine upstream is treating that IP, or *something*.
Man is this strange: when I set my DHCP server to assign the Sipura box a
fixed IP address, the VoIP box didn't work. When I let it assign an
address out of the pool, it did work.
So what happens if you now configure the DHCP server so that the (working) IP is removed from the pool, and have the DHCP server explicitly assign it to the device instead? Does it still work? What if you turn the DHCP client off in the ATA, and try to manually assign the ATA both the fixed IP that didn't work, and the IP that does?
Seems to work for the moment.
There has to be a difference somewhere, whether it is in the DHCP payload, the way a router or NAT engine upstream is treating that IP, or *something*.
Most likely the DHCP payload, the NAT engine in the router isn't likely to treat one IP differently from another.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly