Please take a look here http://www.winenous.co.uk/wp/archives/2942
It describes my experiences from being a total newbie to getting an ATA
and a couple of VoIP lines set up the way I want them, in the hope that
it might be help to others. If anyone has any comments, or corrections
on technical points, I'll be happy to take them either on my blog or here.
Thanks again to everyone here who has helped me - there's an
acknowledgment on the blog post too.
On 26/02/2012 17:40, Steve Slatcher wrote:
> Please take a look here
> http://www.winenous.co.uk/wp/archives/2942
> It describes my experiences from being a total newbie to getting an ATA
> and a couple of VoIP lines set up the way I want them, in the hope that
> it might be help to others. If anyone has any comments, or corrections
> on technical points, I'll be happy to take them either on my blog or here.
>
> Thanks again to everyone here who has helped me - there's an
> acknowledgment on the blog post too.
Nice one Steve.
If the oneway audio becomes a regular problem you might want to look
into port forwarding or a quick fix might be to set the device up as the
DMZ possibly but I've not played with DMZ machines I don't like the idea
of a totally exposed wanside device...
Others will be able to comment with far more autority than myself on
that stuff though but I've had to forward certain ports to clear up
intermittent 1-way audio over the years.
On 26/02/2012 19:13, www.GymRatZ.co.uk wrote:
> On 26/02/2012 17:40, Steve Slatcher wrote:
>> Please take a look here
>> http://www.winenous.co.uk/wp/archives/2942
>> It describes my experiences from being a total newbie to getting an ATA
>> and a couple of VoIP lines set up the way I want them, in the hope that
>> it might be help to others. If anyone has any comments, or corrections
>> on technical points, I'll be happy to take them either on my blog or here.
>>
>> Thanks again to everyone here who has helped me - there's an
>> acknowledgment on the blog post too.
>
> Nice one Steve.
> If the oneway audio becomes a regular problem you might want to look
> into port forwarding or a quick fix might be to set the device up as the
> DMZ possibly but I've not played with DMZ machines I don't like the idea
> of a totally exposed wanside device...
>
> Others will be able to comment with far more autority than myself on
> that stuff though but I've had to forward certain ports to clear up
> intermittent 1-way audio over the years.
Thanks for that suggestion, but wouldn't port forwarding fix the problem
of me not being able to hear the person at the other end? In my case it
was the other way round. Only happened once so far, but it is early days.
In article <9qvm8aFlrU1@mid.individual.net>,
Steve Slatcher <steve.slatcher@pobox.com> wrote:
>On 26/02/2012 19:13, www.GymRatZ.co.uk wrote:
>> On 26/02/2012 17:40, Steve Slatcher wrote:
>>> Please take a look here
>>> http://www.winenous.co.uk/wp/archives/2942
>>> It describes my experiences from being a total newbie to getting an ATA
>>> and a couple of VoIP lines set up the way I want them, in the hope that
>>> it might be help to others. If anyone has any comments, or corrections
>>> on technical points, I'll be happy to take them either on my blog or here.
>>>
>>> Thanks again to everyone here who has helped me - there's an
>>> acknowledgment on the blog post too.
>>
>> Nice one Steve.
>> If the oneway audio becomes a regular problem you might want to look
>> into port forwarding or a quick fix might be to set the device up as the
>> DMZ possibly but I've not played with DMZ machines I don't like the idea
>> of a totally exposed wanside device...
>>
>> Others will be able to comment with far more autority than myself on
>> that stuff though but I've had to forward certain ports to clear up
>> intermittent 1-way audio over the years.
>
>Thanks for that suggestion, but wouldn't port forwarding fix the problem
>of me not being able to hear the person at the other end? In my case it
>was the other way round. Only happened once so far, but it is early days.
I seem to have missed a bit about one way audio, but please do not
ever port-forward 5060 externally to an internal device unless you
are 100% sure that you know what you are doing. Similarly don't use the
DMZ facilities and don't put an ATA in-line with your router and
cable modem.
There are people out there actively looking for SIP endpoints and will
deliberatly run scripts against then to try to hack into them and steal
not only your credentials but all your call credit and more, if possible.
I know of people who have been faced with phone bills in excess of
£10K because someone hacked into their SIP device(s) then used them to
steal calls. Fortunately by using a pre-pay service (sipgate) then
there is some sort of damage limitation built-in, but even so, it's
not nice to be taken for a ride.
Even if you can control it, then one some hackers find a SIP endpoint
they will try relentlessly - I had a client last week who had all their
ADSL allowance used up inside 3 days by hackers probing their lines and
most ISPs will just ignore your requests while asking you to pay more
to have your line topped-up...
Google for sipvicious to find one of the tools they're using...
One way audio is almost always caused by NAT issues - look to disable the
SIP ALG in your router, or replace it with something that doesn't have
the issue or try using a STUN server in your ATA.
On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
<gordon+usenet@drogon.net> wrote:
<snip>
> I seem to have missed a bit about one way audio, but please do not
> ever port-forward 5060 externally to an internal device unless you
> are 100% sure that you know what you are doing. Similarly don't use the
> DMZ facilities and don't put an ATA in-line with your router and
> cable modem.
In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
Dave Saville <dave@invalid.invalid> wrote:
>On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>
><snip>
>> I seem to have missed a bit about one way audio, but please do not
>> ever port-forward 5060 externally to an internal device unless you
>> are 100% sure that you know what you are doing. Similarly don't use the
>> DMZ facilities and don't put an ATA in-line with your router and
>> cable modem.
>
>Would you care to enlarge on that paragraph?
I thought I had, but you
><snip>
ed it.
Briefly, criminals will hack into it and steal your VoIP minutes if
it's exposed to the Internet and you don't take adequate precautions.
On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
<gordon+usenet@drogon.net> wrote:
> In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
> Dave Saville <dave@invalid.invalid> wrote:
> >On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
> ><gordon+usenet@drogon.net> wrote:
> >
> ><snip>
> >> I seem to have missed a bit about one way audio, but please do not
> >> ever port-forward 5060 externally to an internal device unless you
> >> are 100% sure that you know what you are doing. Similarly don't use the
> >> DMZ facilities and don't put an ATA in-line with your router and
> >> cable modem.
> >
> >Would you care to enlarge on that paragraph?
>
> I thought I had, but you
>
> ><snip>
>
> ed it.
>
> Briefly, criminals will hack into it and steal your VoIP minutes if
> it's exposed to the Internet and you don't take adequate precautions.
Gordon - I got that bit. What I don't understand is the quoted
paragraph. If you don't forward 5060 how is *anything* going to get
through to the ATA? And what do you mean about "in-line" with router?
In article <fV45K0OBJxbE-pn2-KDvZKoRJuV2l@localhost>,
Dave Saville <dave@invalid.invalid> wrote:
>On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>
>> In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
>> Dave Saville <dave@invalid.invalid> wrote:
>> >On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
>> ><gordon+usenet@drogon.net> wrote:
>> >
>> ><snip>
>> >> I seem to have missed a bit about one way audio, but please do not
>> >> ever port-forward 5060 externally to an internal device unless you
>> >> are 100% sure that you know what you are doing. Similarly don't use the
>> >> DMZ facilities and don't put an ATA in-line with your router and
>> >> cable modem.
>> >
>> >Would you care to enlarge on that paragraph?
>>
>> I thought I had, but you
>>
>> ><snip>
>>
>> ed it.
>>
>> Briefly, criminals will hack into it and steal your VoIP minutes if
>> it's exposed to the Internet and you don't take adequate precautions.
>
>Gordon - I got that bit. What I don't understand is the quoted
>paragraph. If you don't forward 5060 how is *anything* going to get
>through to the ATA? And what do you mean about "in-line" with router?
OK... If you have a device in the "inside" of your NAT router, then
it can talk to devices on the outside - that's fairly OK, however
if it hasn't established an existing connection to a device on the outside
then nothing on the outside should be able to talk back into the device.
That in-general is good, but it does mean that before an external VoIP
co. can send a call to you, you need to talk to them first. This is OK
too as there is a "registration" phase where the device tells the remote
server "I'm here".
So ATAs can talk to a device on the outside and then that device can talk
back to them as long as the session stays "open".
This is generally good too. It means that the remote service can call
the ATA and make the phones ring.
What's not good is allowing any device in the internet to talk into
your ATA - that would be achieved by port forwarding, or using the DMZ
facilities OR by placing it in-line between the cable modem and router
(the ATA is then actually acting as a router and some even provide DHCP,
DNS, etc.) In those cases, the device is "exposed" to the outside world
so that without some firewalling anyone will be able to talk to the device
on port 5060 and start to probe it for vulnerabilities, weak passwords
and so on. The DMZ case might even be worse as then remote attackers can
see it's web interface and try to hack into it... (I've see this happen)
So it's all about damage limitation. There are people who will try
to hack all VoIP connections all the time - I see it daily and I've
seen sites effectively DOS'd by people running sipvicious and so on.
The only time you need to port-forward port 5060 to a device if if
you have an external SIP phone that needs to regsiter with the device
(in this case it will be an office PBX for example) but then, unless you
know the IP address of the remote phones, you WILL (with 100% certianty)
be the victim of a sipvicious attack at some point in the future.
Every single site I've installed a VoIP PBX at has been attacked by
someone running sipvicious. Some of these sites have subsequently been
cut-off by their ISPs because their monthly quota has been used up. My
own hosted servers which by their nature are exposed to the Internet
get attacked all the time.
On Mon, 27 Feb 2012 11:38:46 UTC, Gordon Henderson
<gordon+usenet@drogon.net> wrote:
<snip>
> OK... If you have a device in the "inside" of your NAT router, then
> it can talk to devices on the outside - that's fairly OK, however
> if it hasn't established an existing connection to a device on the outside
> then nothing on the outside should be able to talk back into the device.
>
> That in-general is good, but it does mean that before an external VoIP
> co. can send a call to you, you need to talk to them first. This is OK
> too as there is a "registration" phase where the device tells the remote
> server "I'm here".
>
> So ATAs can talk to a device on the outside and then that device can talk
> back to them as long as the session stays "open".
>
> This is generally good too. It means that the remote service can call
> the ATA and make the phones ring.
Well I never! Never knew that. Not helped by most refeneces to set up
an ATA or similar talk about holes in firewalls. Just disabled my rule
and you are right, incoming still works.
Of course things are different if the ATA has a "real" IP address.
There again I suppose we will have to expose once ATAs start appearing
with IVP6 - no NAT.
In article <fV45K0OBJxbE-pn2-CcJ4sCLeOzyT@localhost>,
Dave Saville <dave@invalid.invalid> wrote:
>On Mon, 27 Feb 2012 11:38:46 UTC, Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>
><snip>
>
>> OK... If you have a device in the "inside" of your NAT router, then
>> it can talk to devices on the outside - that's fairly OK, however
>> if it hasn't established an existing connection to a device on the outside
>> then nothing on the outside should be able to talk back into the device.
>>
>> That in-general is good, but it does mean that before an external VoIP
>> co. can send a call to you, you need to talk to them first. This is OK
>> too as there is a "registration" phase where the device tells the remote
>> server "I'm here".
>>
>> So ATAs can talk to a device on the outside and then that device can talk
>> back to them as long as the session stays "open".
>>
>> This is generally good too. It means that the remote service can call
>> the ATA and make the phones ring.
>
>Well I never! Never knew that. Not helped by most refeneces to set up
>an ATA or similar talk about holes in firewalls. Just disabled my rule
>and you are right, incoming still works.
NAT is the biggest PITA in the VoIP world. SIP was developed at about the
same time NAT was, and nether group seemed to acknowledge the existance
of the other...
Some aspects of SIP simply were not developed with NAT in-mind -
e.g. passing the media stream from point A to point C, bypassing the PBX,
at C in the middle - in a NAT situation this is somewhat "intersting"...
The issues faced by routers, etc. is that SIP needs more than one
channel communicate - the audio data is separate from the command
data and that causes issues. This is when port-forwarding to the SIP
endpoint often magically makes it work... But that'll only work of you
have one SIP device - you can only port-forward 5060 once! An office
with 50 SIP phones needs something else...
>Of course things are different if the ATA has a "real" IP address.
>There again I suppose we will have to expose once ATAs start appearing
>with IVP6 - no NAT.
That's going to take a long time (sadly). Very few ISPs in the UK support
native IPv6 right now and the number of routers (at the domestic level)
that support it is about .. 2 right now. (well, maybe one or 2 more,
however it's very, very low)
> Of course things are different if the ATA has a "real" IP address.
> There again I suppose we will have to expose once ATAs start appearing
> with IVP6 - no NAT.
Out of interest. I have a few spare static IP addresses @ home
Would that not in effect put the ATA once more into the firing line of
the open world or would the router still block incoming probes to the
ATA IP address ?
> Out of interest. I have a few spare static IP addresses @ home
> Would that not in effect put the ATA once more into the firing line of
> the open world
Yes, it could well do. Another potential upside of IPv6 is that the sheer
size of the address space makes scanning the entire internet for vulnerable
hosts one subnet at a time all the more difficult - security by obscurity as
it were.
> or would the router still block incoming probes to the ATA IP address ?
There's no reason why you can't do connection tracking on IPv6 without NAT
[as you would do on IPv4 with NAT] in order to determine what's allowed back
in and what's not.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
20:17:44 up 46 days, 23:47, 5 users, load average: 0.04, 0.15, 0.16
Qua illic est reprehendit, illic est a vindicatum
> One way audio is almost always caused by NAT issues - look to disable the
> SIP ALG in your router, or replace it with something that doesn't have
> the issue or try using a STUN server in your ATA.
Eh? Do general purpose routers have setting specifically for SIP?
Cannot see such a thing in my Lynksys WRT54GS.
If there are NAT issues, doesn't that simply mean my router is not
working correctly? It does NAT all the time for my computer. Why is
SIP to my ATA any different?
On Mon, 27 Feb 2012 20:40:55 +0000, Steve Slatcher
<steve.slatcher@pobox.com> wrote:
>On 26/02/2012 22:02, Gordon Henderson wrote:
>
>> One way audio is almost always caused by NAT issues - look to disable the
>> SIP ALG in your router, or replace it with something that doesn't have
>> the issue or try using a STUN server in your ATA.
>
>Eh? Do general purpose routers have setting specifically for SIP?
>Cannot see such a thing in my Lynksys WRT54GS.
>
>If there are NAT issues, doesn't that simply mean my router is not
>working correctly? It does NAT all the time for my computer. Why is
>SIP to my ATA any different?
Netgear routers do, but note Gordon is suggesting *disable* it.
I think the whatever it is supposed to do is regarded as "broken" in
software terms.
On 27/02/2012 21:12, Graham. wrote:
> On Mon, 27 Feb 2012 20:40:55 +0000, Steve Slatcher
> <steve.slatcher@pobox.com> wrote:
>
>> On 26/02/2012 22:02, Gordon Henderson wrote:
>>
>>> One way audio is almost always caused by NAT issues - look to disable the
>>> SIP ALG in your router, or replace it with something that doesn't have
>>> the issue or try using a STUN server in your ATA.
>>
>> Eh? Do general purpose routers have setting specifically for SIP?
>> Cannot see such a thing in my Lynksys WRT54GS.
>>
>> If there are NAT issues, doesn't that simply mean my router is not
>> working correctly? It does NAT all the time for my computer. Why is
>> SIP to my ATA any different?
>
> Netgear routers do, but note Gordon is suggesting *disable* it.
>
> I think the whatever it is supposed to do is regarded as "broken" in
> software terms.
In article <9r282oFnt4U1@mid.individual.net>,
Steve Slatcher <steve.slatcher@pobox.com> wrote:
>On 26/02/2012 22:02, Gordon Henderson wrote:
>
>> One way audio is almost always caused by NAT issues - look to disable the
>> SIP ALG in your router, or replace it with something that doesn't have
>> the issue or try using a STUN server in your ATA.
>
>Eh? Do general purpose routers have setting specifically for SIP?
>Cannot see such a thing in my Lynksys WRT54GS.
Some routers need a lower level interface to disable these features...
>If there are NAT issues, doesn't that simply mean my router is not
>working correctly? It does NAT all the time for my computer. Why is
>SIP to my ATA any different?
It's complex... And this is a somewhat simple explanation... VoIP via
SIP is 2 things - one part is a command channel and the other part is the
media channel. (audio) A bit like FTP. Or it might be if SIP didn't
encode the IP address of the unit *inside* it's commands to the other
end... So a SIP device on 192.168.3.4 will send that IP address to the
far-end... Which then tries to send a reply back to that IP address and
worse, tries to send the audio stream back to it. Which will fail unless
there is a VPN setup between the 2 endpoints...
Some routers have a SIP ALG - (Application Level Gateway) which tries
to do "deep packet inspection" on the SIP commands as they pass through
and substituting the proper external IP address in the packets as they
pass through, and un-doing it for the return. Unfortunately almost all
implementations I've seen are broken and just don't work.
SIP/VoIP works most of the time because the far-end can see the real
IP address and do it's own substitution of the internal IP addresses
and/or the user device (e.g. ATA, phone) is using a STUN server which
will tell the device it's external IP address so the device can put in
the real external IP address instead of it's private IP address.
There are devices and softwares that can run as part of the VoIP providers
network to assist in this packet mangling. (And there are alternatives
to STUN too)
The other hassle is working out the ports to use for the audio streams
and hoping that the device on the inside will start talking first so the
devices on the outside then have a path back to them after the router has
opened up the channel (and remembered it as part of its NAT processing)
One way audio is often caused by the far-end not having your correct
external IP address to send data back to, or the router simply blocking
it as it's coming in from a different IP address or port from the
outgoing stream.
If only the SIP people had thought about NAT, however...
But as we all know for the most-part it does work, but there are some
routers I've had issues with - BT homehubs, some netgears, Junipers...
Draytek 'v' series. And some routers just have issues with a device
keeping a NAT session open for a very long time - e.g. Drayteks.
On 27/02/2012 22:06, Gordon Henderson wrote:
> In article<9r282oFnt4U1@mid.individual.net>,
> Steve Slatcher<steve.slatcher@pobox.com> wrote:
>> On 26/02/2012 22:02, Gordon Henderson wrote:
>>
>>> One way audio is almost always caused by NAT issues - look to disable the
>>> SIP ALG in your router, or replace it with something that doesn't have
>>> the issue or try using a STUN server in your ATA.
>>
>> Eh? Do general purpose routers have setting specifically for SIP?
>> Cannot see such a thing in my Lynksys WRT54GS.
>
> Some routers need a lower level interface to disable these features...
>
>> If there are NAT issues, doesn't that simply mean my router is not
>> working correctly? It does NAT all the time for my computer. Why is
>> SIP to my ATA any different?
>
>
> It's complex... And this is a somewhat simple explanation... VoIP via
> SIP is 2 things - one part is a command channel and the other part is the
> media channel. (audio) A bit like FTP. Or it might be if SIP didn't
> encode the IP address of the unit *inside* it's commands to the other
> end... So a SIP device on 192.168.3.4 will send that IP address to the
> far-end... Which then tries to send a reply back to that IP address and
> worse, tries to send the audio stream back to it. Which will fail unless
> there is a VPN setup between the 2 endpoints...
>
> Some routers have a SIP ALG - (Application Level Gateway) which tries
> to do "deep packet inspection" on the SIP commands as they pass through
> and substituting the proper external IP address in the packets as they
> pass through, and un-doing it for the return. Unfortunately almost all
> implementations I've seen are broken and just don't work.
>
> SIP/VoIP works most of the time because the far-end can see the real
> IP address and do it's own substitution of the internal IP addresses
> and/or the user device (e.g. ATA, phone) is using a STUN server which
> will tell the device it's external IP address so the device can put in
> the real external IP address instead of it's private IP address.
>
> There are devices and softwares that can run as part of the VoIP providers
> network to assist in this packet mangling. (And there are alternatives
> to STUN too)
>
> The other hassle is working out the ports to use for the audio streams
> and hoping that the device on the inside will start talking first so the
> devices on the outside then have a path back to them after the router has
> opened up the channel (and remembered it as part of its NAT processing)
>
> One way audio is often caused by the far-end not having your correct
> external IP address to send data back to, or the router simply blocking
> it as it's coming in from a different IP address or port from the
> outgoing stream.
>
> If only the SIP people had thought about NAT, however...
>
> But as we all know for the most-part it does work, but there are some
> routers I've had issues with - BT homehubs, some netgears, Junipers...
> Draytek 'v' series. And some routers just have issues with a device
> keeping a NAT session open for a very long time - e.g. Drayteks.
>
> Gordon
Thank you for that clear explanation. Should the one-way audio get to
be a big problem (it isn't yet) I now know where to start looking.
After, a bit of googling, I think my first step would be to upgrade my
router firmware and hope those nice Cisco people have fixed any
responsible bugs!
On Mon, 27 Feb 2012 22:06:04 +0000, Gordon Henderson wrote:
> In article <9r282oFnt4U1@mid.individual.net>, Steve Slatcher
> <steve.slatcher@pobox.com> wrote:
>>On 26/02/2012 22:02, Gordon Henderson wrote:
>>
>>> One way audio is almost always caused by NAT issues - look to disable
>>> the SIP ALG in your router, or replace it with something that doesn't
>>> have the issue or try using a STUN server in your ATA.
>>
>>Eh? Do general purpose routers have setting specifically for SIP?
>>Cannot see such a thing in my Lynksys WRT54GS.
>
> Some routers need a lower level interface to disable these features...
>
>>If there are NAT issues, doesn't that simply mean my router is not
>>working correctly? It does NAT all the time for my computer. Why is
>>SIP to my ATA any different?
>
>
> It's complex... And this is a somewhat simple explanation... VoIP via
> SIP is 2 things - one part is a command channel and the other part is
> the media channel. (audio) A bit like FTP. Or it might be if SIP didn't
> encode the IP address of the unit *inside* it's commands to the other
> end... So a SIP device on 192.168.3.4 will send that IP address to the
> far-end... Which then tries to send a reply back to that IP address and
> worse, tries to send the audio stream back to it. Which will fail unless
> there is a VPN setup between the 2 endpoints...
>
> Some routers have a SIP ALG - (Application Level Gateway) which tries to
> do "deep packet inspection" on the SIP commands as they pass through and
> substituting the proper external IP address in the packets as they pass
> through, and un-doing it for the return. Unfortunately almost all
> implementations I've seen are broken and just don't work.
>
> SIP/VoIP works most of the time because the far-end can see the real IP
> address and do it's own substitution of the internal IP addresses and/or
> the user device (e.g. ATA, phone) is using a STUN server which will tell
> the device it's external IP address so the device can put in the real
> external IP address instead of it's private IP address.
Or the SIP phone has a config option where you can enter the external IP
address manually (only useful if you have a static IP). My Grandstream
BT200 has this, so it doesn't need to talk to a STUN server to discover
its external address.
> There are devices and softwares that can run as part of the VoIP
> providers network to assist in this packet mangling. (And there are
> alternatives to STUN too)
>
> The other hassle is working out the ports to use for the audio streams
> and hoping that the device on the inside will start talking first so the
> devices on the outside then have a path back to them after the router
> has opened up the channel (and remembered it as part of its NAT
> processing)
>
> One way audio is often caused by the far-end not having your correct
> external IP address to send data back to, or the router simply blocking
> it as it's coming in from a different IP address or port from the
> outgoing stream.
>
> If only the SIP people had thought about NAT, however...
Then a lot of network engineers would be short of work :-)
> But as we all know for the most-part it does work, but there are some
> routers I've had issues with - BT homehubs, some netgears, Junipers...
> Draytek 'v' series. And some routers just have issues with a device
> keeping a NAT session open for a very long time - e.g. Drayteks.
>
> Gordon
Gordon Henderson wrote:
> In article <fV45K0OBJxbE-pn2-KDvZKoRJuV2l@localhost>,
> Dave Saville <dave@invalid.invalid> wrote:
>> On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
>> <gordon+usenet@drogon.net> wrote:
>>
>>> In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
>>> Dave Saville <dave@invalid.invalid> wrote:
>>>> On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
>>>> <gordon+usenet@drogon.net> wrote:
>>>>
>>>> <snip>
>>>>> I seem to have missed a bit about one way audio, but please do not
>>>>> ever port-forward 5060 externally to an internal device unless you
>>>>> are 100% sure that you know what you are doing. Similarly don't use the
>>>>> DMZ facilities and don't put an ATA in-line with your router and
>>>>> cable modem.
>>>> Would you care to enlarge on that paragraph?
>>> I thought I had, but you
>>>
>>>> <snip>
>>> ed it.
>>>
>>> Briefly, criminals will hack into it and steal your VoIP minutes if
>>> it's exposed to the Internet and you don't take adequate precautions.
>> Gordon - I got that bit. What I don't understand is the quoted
>> paragraph. If you don't forward 5060 how is *anything* going to get
>> through to the ATA? And what do you mean about "in-line" with router?
>
> OK... If you have a device in the "inside" of your NAT router, then
> it can talk to devices on the outside - that's fairly OK, however
> if it hasn't established an existing connection to a device on the outside
> then nothing on the outside should be able to talk back into the device.
SIP, in standard form, is connectionless, and at the level at which you
would have to do this (a continuous sequence of successful re-REGISTERs)
is connectionless below the application layer. I don't believe there is
any real name for the sort of connection that exists with a chain of
re-REGISTERs. If you have static addresses, even that concept of a
connection doesn't exist.
>
> What's not good is allowing any device in the internet to talk into
> your ATA - that would be achieved by port forwarding, or using the DMZ
SIP was, of course, designed for a fully decentralized system, even
though nearly everyone operates it centralised and always uses the PSTN
as an intermediary. (Then again, so was SMTP.)
On Mon, 27 Feb 2012 09:38:01 +0000 (UTC), "Dave Saville"
<dave@invalid.invalid> wrote:
>On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>
><snip>
>> I seem to have missed a bit about one way audio, but please do not
>> ever port-forward 5060 externally to an internal device unless you
>> are 100% sure that you know what you are doing. Similarly don't use the
>> DMZ facilities and don't put an ATA in-line with your router and
>> cable modem.
>
Is there less of a problem if you use a different port(s), say 49494 ?
In article <2lprk71kfj5sbp6qv7elh23rps7vasgji4@4ax.com>,
Bob L <bl@thisaddressisnowhere.com> wrote:
>On Mon, 27 Feb 2012 09:38:01 +0000 (UTC), "Dave Saville"
><dave@invalid.invalid> wrote:
>
>>On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
>><gordon+usenet@drogon.net> wrote:
>>
>><snip>
>>> I seem to have missed a bit about one way audio, but please do not
>>> ever port-forward 5060 externally to an internal device unless you
>>> are 100% sure that you know what you are doing. Similarly don't use the
>>> DMZ facilities and don't put an ATA in-line with your router and
>>> cable modem.
>
>Is there less of a problem if you use a different port(s), say 49494 ?
Sure - but unless the person trying to contct you knows what port you're
using then they won't be able to contact you...
You may also find that commercial suppliers simply won't entertain it.
Replacing a BT landline by VoIP 
Linear Mode
