Re: NetTalk Duo VoIP

[Jim <alarminex@xxxxxxx>]

On Mar 27, 8:53=A0pm, tourman <robercampb...@xxxxxxxxx> wrote:
> On Mar 27, 5:16=A0pm, Jim <alarmi...@xxxxxxx> wrote:
>
>
>
>
>
> > On Mar 27, 9:45=A0am, tourman <robercampb...@xxxxxxxxx> wrote:
>
> > > On Mar 22, 10:52=A0am, Jim Rojas <jro...@xxxxxxxxxxxx> wrote:
>
> > > > Troubleshooting Tip:
>
> > > > The loss of dial tone with a cable ISP would seem to be a DNS block=
 by
> > > > your provider.
>
> > > > Changing the DNS will help the issue:
> > > > =A0>Primary: 4.2.2.2
> > > > =A0>Secondary: 4.2.2.1
>
> > > > Going to WAN setup:
> > > > =A0>Disable SIP ALG
> > > > =A0>Enable DMZ for netTALK device with netTALK's IP.
>
> > > > Port forwarding:Label netTALK
> > > > =A0> ALL ports set to UDP
> > > > =A0> 5060 - 5060
> > > > =A0> 69 - 69
> > > > =A0> 10000 - 20000
>
> > > > Make sure to restart the netTALK device by unplugging the power and
> > > > plugging it back in.
>
> > > > Thank you and sorry for any inconveniences,
>
> > > > NetTalk Tech Support
>
> > > > Jim Rojas
> > > > Technical Manuals Online!http://www.tech-man.com
> > > > 8002 Cornwall Lane
> > > > Tampa, FL 33615-4604
> > > > 813-884-6335
>
> > > > --- news://freenews.netfront.net/ - complaints: n...@xxxxxxxxxxxx -=
--
>
> > > RHC: I =A0"reserved" the Duo IP address within the DHCP pool of my
> > > router and opened the DMZ zone to that particular local IP address.
> > > Should solve any dial in problems. The Nettalk unit itself is passwor=
d
> > > protected so that's all any hacker will ever see.
>
> > > In searching the Nettalk forums, I did find one alarm dealer who
> > > claims the unit doesn't kiss off properly using Contact ID or SIA, an=
d
> > > he had to fall back to either 4/2 or 3/1 to make it work. Yet your
> > > experience seems to say otherwise. I haven't yet done the connection
> > > and testing to confirm one way or the other,so...we'll see...-
>
> > My feeling about this device is, that you may want to utilize it for
> > your own use but regardless of what you or Jim ultimately experience,
> > I don't think it would be a good idea to provide, recommend or depend
> > upon this device in the course of business. It's likely that it will
> > work some or most of the time under some conditions but ...... not
> > every time ..... without fail.
>
> RHC: "It will work some or most of the time under some conditions" is
> pretty much the definition NOW of how alarms work with all current
> VoIP services. That's exactly why reputable companies wont touch VoIP
> on alarms !!
>
> =A0If this is any better, it may offer a solution of some sort; however,
> I see your point and acknowledge the worth of it. The question really
> is "how MUCH better is this VoIP than previous ones and at what point
> is it reliable enough???
>
> Gotta say, I don't know the answer to THAT question....-

Well .... what I'm thinking about is .... we all know there is less
reliability using VoIP. However, it is being used with a communicator
that's built into a device that is meant to communicate alarm signals.
That's a common denominator, so to speak. If we connect that device
"directly" to a "known and generally accepted" means of communication,
and that's the "best" that we can do, subject to the communication
service that the client chooses to use ..... I don't think that anyone
can point a finger should a failure occur.

If one chooses to use the internet as a means of communicating alarm
signals and uses a device that is meant to provide that ability and
that is the "best" we can do, .... again .... I don't think anyone can
point a finger.

However, if you introduce a commercially available $69.00 device that
specifically says ... not for alarms .... and communication doesn't
work .... for whatEVER reason, ..... it's fodder for anyones
imagination.

And I just can't picture a disclaimer explaining this devices'
shortcommings and limitations to the satisfaction of a jury, that
someone could come up with, that any end user would sign.