Replacing a BT landline by VoIP

Discussion in 'UK VOIP' started by Steve Slatcher, Feb 26, 2012.

  1. 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.

    Cheers

    Steve
     
    Steve Slatcher, Feb 26, 2012
    #1
    1. Advertising

  2. 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.

    --
    www.winenous.co.uk
     
    Steve Slatcher, Feb 26, 2012
    #2
    1. Advertising

  3. In article <>,
    Steve Slatcher <> 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.

    Gordon
     
    Gordon Henderson, Feb 26, 2012
    #3
  4. Steve Slatcher

    Dave Saville Guest

    On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    <> 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?

    <snip>
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 27, 2012
    #4
  5. In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
    Dave Saville <> wrote:
    >On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    ><> 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
     
    Gordon Henderson, Feb 27, 2012
    #5
  6. Steve Slatcher

    Dave Saville Guest

    On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
    <> wrote:

    > In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
    > Dave Saville <> wrote:
    > >On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    > ><> 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?

    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 27, 2012
    #6
  7. In article <fV45K0OBJxbE-pn2-KDvZKoRJuV2l@localhost>,
    Dave Saville <> wrote:
    >On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
    ><> wrote:
    >
    >> In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
    >> Dave Saville <> wrote:
    >> >On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    >> ><> 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.

    Gordon
     
    Gordon Henderson, Feb 27, 2012
    #7
  8. Steve Slatcher

    Dave Saville Guest

    On Mon, 27 Feb 2012 11:38:46 UTC, Gordon Henderson
    <> 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.

    <snip>
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 27, 2012
    #8
  9. In article <fV45K0OBJxbE-pn2-CcJ4sCLeOzyT@localhost>,
    Dave Saville <> wrote:
    >On Mon, 27 Feb 2012 11:38:46 UTC, Gordon Henderson
    ><> 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)

    Gordon
     
    Gordon Henderson, Feb 27, 2012
    #9
  10. 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?
     
    Steve Slatcher, Feb 27, 2012
    #10
  11. Steve Slatcher

    Graham. Guest

    On Mon, 27 Feb 2012 20:40:55 +0000, Steve Slatcher
    <> 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.

    --
    Graham.
    %Profound_observation%
     
    Graham., Feb 27, 2012
    #11
  12. On 27/02/2012 21:12, Graham. wrote:
    > On Mon, 27 Feb 2012 20:40:55 +0000, Steve Slatcher
    > <> 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.


    I did note that. Just curious...

    --
    www.winenous.co.uk
     
    Steve Slatcher, Feb 27, 2012
    #12
  13. In article <>,
    Steve Slatcher <> 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
     
    Gordon Henderson, Feb 27, 2012
    #13
  14. On 27/02/2012 22:06, Gordon Henderson wrote:
    > In article<>,
    > Steve Slatcher<> 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!

    --
    www.winenous.co.uk
     
    Steve Slatcher, Feb 27, 2012
    #14
  15. On Mon, 27 Feb 2012 22:06:04 +0000, Gordon Henderson wrote:

    > In article <>, Steve Slatcher
    > <> 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
     
    Andrew Benham, Feb 28, 2012
    #15
  16. Gordon Henderson wrote:
    > In article <fV45K0OBJxbE-pn2-KDvZKoRJuV2l@localhost>,
    > Dave Saville <> wrote:
    >> On Mon, 27 Feb 2012 10:36:36 UTC, Gordon Henderson
    >> <> wrote:
    >>
    >>> In article <fV45K0OBJxbE-pn2-m9jj5kLeWd55@localhost>,
    >>> Dave Saville <> wrote:
    >>>> On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    >>>> <> 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.)
     
    David Woolley, Feb 28, 2012
    #16
  17. In article <>,
    Bob L <> wrote:
    >On Mon, 27 Feb 2012 09:38:01 +0000 (UTC), "Dave Saville"
    ><> wrote:
    >
    >>On Sun, 26 Feb 2012 22:02:52 UTC, Gordon Henderson
    >><> 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.

    Gordon
     
    Gordon Henderson, Feb 29, 2012
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jt
    Replies:
    6
    Views:
    4,993
    Inco Warren
    Jan 30, 2005
  2. ChrisR
    Replies:
    4
    Views:
    641
    Ivor Jones
    May 11, 2005
  3. Jason
    Replies:
    6
    Views:
    1,467
  4. yamyb100
    Replies:
    2
    Views:
    918
    yamyb100
    Sep 22, 2005
  5. Willie

    Landline to landline via web

    Willie, Sep 28, 2006, in forum: UK VOIP
    Replies:
    14
    Views:
    2,933
Loading...

Share This Page