BT IP Office question

Discussion in 'UK VOIP' started by Graham J, Dec 4, 2013.

  1. Graham J

    Graham J Guest

    New installation. Openreach engineeer has all the local phones working
    OK. One phone is intended for remote use, so:

    1) Site has internet connection with static IP (call it A.B.C.D)

    2) Phone is configured to look for public IP address of site.

    3) Internet router has TCP/UDP ports opened to the IP Office device, as
    follows:

    Port 1719
    Port 1720
    Port 5000
    Port 5060
    Port range 49152 - 53246

    4) Openreach engineer called a colleague at another location, who
    configured a test phone with the correct IP, and was able to connect to
    the IP Office at our site. So IP Office and router would seem to be
    configured correctly.

    However the phone does not connect to IP Office when installed at a
    remote site. Phone gets a local IP address by DHCP, shows some
    activity, then hangs with "Discover A.B.C.D".

    This appears to suggest it can't communicate with IP Office.

    Does the router at the remote site need any port openings?

    Is there any other configuration needed at the remote site?

    Openreach engineer seemed to be very limited on knowledge.


    --
    Graham J
    Graham J, Dec 4, 2013
    #1
    1. Advertising

  2. Graham J

    Graham J Guest

    Dave Higton wrote:
    > In message <529f706b$0$1176$>
    > Graham J <graham@invalid> wrote:
    >
    >> New installation. Openreach engineeer has all the local phones working
    >> OK. One phone is intended for remote use, so:
    >>
    >> 1) Site has internet connection with static IP (call it A.B.C.D)
    >>
    >> 2) Phone is configured to look for public IP address of site.
    >>
    >> 3) Internet router has TCP/UDP ports opened to the IP Office device, as
    >> follows:
    >>
    >> Port 1719
    >> Port 1720
    >> Port 5000
    >> Port 5060
    >> Port range 49152 - 53246
    >>
    >> 4) Openreach engineer called a colleague at another location, who
    >> configured a test phone with the correct IP, and was able to connect to
    >> the IP Office at our site. So IP Office and router would seem to be
    >> configured correctly.
    >>
    >> However the phone does not connect to IP Office when installed at a
    >> remote site. Phone gets a local IP address by DHCP, shows some
    >> activity, then hangs with "Discover A.B.C.D".
    >>
    >> This appears to suggest it can't communicate with IP Office.
    >>
    >> Does the router at the remote site need any port openings?
    >>
    >> Is there any other configuration needed at the remote site?

    >
    > There is more than one way of interpreting "installed at a remote
    > site".


    OK - how about "Connected to the LAN at the remote site"?. The remote
    sie is a typical configuration with a NAT router

    > Also it's not clear whether you want the remote phone to be
    > an extension of the IP Office switch, or simply to be able to call
    > IP Office extensions like any external phone.


    OK - I want the remote phone to function as an extension of the IP
    Office switch - just as if it were physically on the same site as the IP
    Office switch.

    > Let's assume that there is no special connection between the remote
    > site and the IP Office site (no VPN etc.)


    Correct.

    > The remote site would normally need port 5060 to be open, also a
    > range of ports for the RTP traffic - and the phone would need to
    > be configured to use only that range.
    >
    > If you don't open port 5060, the phone might not be able to register
    > with the IP Office - hence wouldn't be able to function as an
    > extension - and would in most cases be unable to receive incoming
    > calls.
    >
    > If you don't configure an RTP port range and open the same range,
    > you'd probably only have audio from remote site to IP office but
    > not in the other direction.


    OK so this contradicts what the Openreach engineer says - that there is
    no special configuration required at the remote site.

    Having said that, he did say they would only guarantee operation where
    both the office and remote sites were equipped with BT routers (2-Wire)
    and BT was the ISP.

    I have seen a similar configuration working, with non-BT PBX and IP
    phone, where the IP phone works correctly at the remote site without the
    remote site's router needing to have any special configuration.

    > The other thing you're likely to need is for the remote phone to
    > use STUN or similar so that it can be aware of the remote site's
    > external IP address, assuming that the remote site uses a NAT
    > firewall.


    The remote phone has the public IP of the IP Office site coded into it
    by the Openreach engineer - I watched him do it. This appeared to be
    the only configuration change that was necessary on the IP phone.

    Thanks.

    --
    Graham J
    Graham J, Dec 5, 2013
    #2
    1. Advertising

  3. Graham J

    Dave Saville Guest

    On Thu, 5 Dec 2013 08:34:14 UTC, Graham J <graham@invalid> wrote:

    > The remote phone has the public IP of the IP Office site coded into it
    > by the Openreach engineer - I watched him do it. This appeared to be
    > the only configuration change that was necessary on the IP phone.
    >


    It is often a *good thing* to disable any SIP-ALG code on routers.
    It's supposed to help from behind NAT but usually gets in the way due
    to bad implementation.

    As well as the remote end needing the holes in the firewall it would
    need to know to pass such traffic to the phone's *internal* IP.

    HTH
    --
    Regards
    Dave Saville
    Dave Saville, Dec 5, 2013
    #3
  4. Graham J

    ßodincus Guest

    | · : · : · : · : · : · : · Original Message · : · : ·: · : · : · : ·
    | From: Dave Saville
    | Date: 05/12/13 09:59

    > On Thu, 5 Dec 2013 08:34:14 UTC, Graham J <graham@invalid> wrote:
    >
    >> The remote phone has the public IP of the IP Office site coded into it
    >> by the Openreach engineer - I watched him do it. This appeared to be
    >> the only configuration change that was necessary on the IP phone.
    >>

    >
    > It is often a *good thing* to disable any SIP-ALG code on routers.
    > It's supposed to help from behind NAT but usually gets in the way due
    > to bad implementation.
    >
    > As well as the remote end needing the holes in the firewall it would
    > need to know to pass such traffic to the phone's *internal* IP.
    >
    > HTH
    >

    Seconded. SIP ALGs are a PITA. I'd like to know what warped mind thought
    smart to mangle and mingle SIP traffic and rewrite IP addresses in the
    packets on the fly. @*%^$@@%&*

    Also, set up the outbound proxy in the remote phone to use the same IP
    of the registrar.

    You don't need this for phones in the same net/subnet of the PBX, but
    it's a given in this case.

    You don't know what type of connection the remote BT engineer used,
    possibly he had assigned a public IP to the phone, or opened ports, or
    the router had trigger ports configured, or...

    If you have a decent router at the remote site (like a Draytek) PLEASE,
    PLEASE remember to set up proper firewall rules to drop incoming traffic
    on port 5060 from other IPs than your PBX public IP, when you open it
    and NAT it to the phone's IP.

    Similarly, as you have open ports on your main office router, *firewall,
    firewall, firewall*. Not as much the RTP ports, but 5060 UDP. An open
    UDP 5060 is just an invitation for nasty people to hammer your PBX. Open
    it to your remote office IP, and to the SIP trunk supplier's IP(s).

    If you don't (WHY?) expect a lot of attention from "friendly-scanner"
    and prepare for the risk of toll fraud.

    Oh, check that the BT PBX uses *UDP* 5060 for SIP, and not TCP. Some
    oddball systems do (Lync, anyone?) - "Embrace and extend" from Microsoft
    again!
    --
    ßodincus - The Y2K Druid
    ßodincus, Dec 5, 2013
    #4
  5. Graham J

    Dave Higton Guest

    In message <52a03a92$0$1159$>
    Graham J <graham@invalid> wrote:

    >I have seen a similar configuration working, with non-BT PBX and IP
    >phone, where the IP phone works correctly at the remote site without the
    >remote site's router needing to have any special configuration.


    I cannot see any possible way to do that. You have to either forward
    ports to the phone, or have a SIP Session Border Controller, as far
    as I know - basically the router is SIP-aware.

    >> The other thing you're likely to need is for the remote phone to
    >> use STUN or similar so that it can be aware of the remote site's
    >> external IP address, assuming that the remote site uses a NAT
    >> firewall.

    >
    >The remote phone has the public IP of the IP Office site coded into it
    >by the Openreach engineer - I watched him do it. This appeared to be
    >the only configuration change that was necessary on the IP phone.


    I'm not familiar with the particular phones in question. I hope
    yours has an IP address that is on the remote site's LAN, and
    that the BT engineer has put the external IP address in as a
    substitute for STUN etc. Otherwise it isn't going to work.

    And everything that ssodincus (I'm assuming that the symbol is
    the German double-s) says about firewalling and penetration
    protection is true; it's good advice.

    Dave
    Dave Higton, Dec 5, 2013
    #5
  6. Graham J

    Graham J Guest

    ßodincus wrote:
    > | · : · : · : · : · : · : · Original Message · : · : · : · : · : · : ·
    > | From: Dave Saville
    > | Date: 05/12/13 09:59
    >
    >> On Thu, 5 Dec 2013 08:34:14 UTC, Graham J <graham@invalid> wrote:
    >>
    >>> The remote phone has the public IP of the IP Office site coded into it
    >>> by the Openreach engineer - I watched him do it. This appeared to be
    >>> the only configuration change that was necessary on the IP phone.
    >>>

    >>
    >> It is often a *good thing* to disable any SIP-ALG code on routers.
    >> It's supposed to help from behind NAT but usually gets in the way due
    >> to bad implementation.
    >>
    >> As well as the remote end needing the holes in the firewall it would
    >> need to know to pass such traffic to the phone's *internal* IP.
    >>
    >> HTH
    >>

    > Seconded. SIP ALGs are a PITA. I'd like to know what warped mind thought
    > smart to mangle and mingle SIP traffic and rewrite IP addresses in the
    > packets on the fly. @*%^$@@%&*
    >
    > Also, set up the outbound proxy in the remote phone to use the same IP
    > of the registrar.
    >
    > You don't need this for phones in the same net/subnet of the PBX, but
    > it's a given in this case.
    >
    > You don't know what type of connection the remote BT engineer used,
    > possibly he had assigned a public IP to the phone, or opened ports, or
    > the router had trigger ports configured, or...
    >
    > If you have a decent router at the remote site (like a Draytek) PLEASE,
    > PLEASE remember to set up proper firewall rules to drop incoming traffic
    > on port 5060 from other IPs than your PBX public IP, when you open it
    > and NAT it to the phone's IP.
    >
    > Similarly, as you have open ports on your main office router, *firewall,
    > firewall, firewall*. Not as much the RTP ports, but 5060 UDP. An open
    > UDP 5060 is just an invitation for nasty people to hammer your PBX. Open
    > it to your remote office IP, and to the SIP trunk supplier's IP(s).
    >
    > If you don't (WHY?) expect a lot of attention from "friendly-scanner"
    > and prepare for the risk of toll fraud.
    >
    > Oh, check that the BT PBX uses *UDP* 5060 for SIP, and not TCP. Some
    > oddball systems do (Lync, anyone?) - "Embrace and extend" from Microsoft
    > again!


    I set up a LAN-to-LAN VPN between the two sites, and got the BT man to
    re-configure the IP phone as if it were on the same site as the PBX.
    Took it to remote site - worked OK immediately.

    Much simpler than setting up port forwarding and firewall rules at both
    sites ...

    --
    Graham J
    Graham J, Dec 6, 2013
    #6
  7. Graham J

    Graham. Guest

    On Fri, 06 Dec 2013 13:47:13 +0000, Graham J <graham@invalid> wrote:

    >ßodincus wrote:
    >> | · : · : · : · : · : · : · Original Message · : · : · : · : · : · : ·
    >> | From: Dave Saville
    >> | Date: 05/12/13 09:59
    >>
    >>> On Thu, 5 Dec 2013 08:34:14 UTC, Graham J <graham@invalid> wrote:
    >>>
    >>>> The remote phone has the public IP of the IP Office site coded into it
    >>>> by the Openreach engineer - I watched him do it. This appeared to be
    >>>> the only configuration change that was necessary on the IP phone.
    >>>>
    >>>
    >>> It is often a *good thing* to disable any SIP-ALG code on routers.
    >>> It's supposed to help from behind NAT but usually gets in the way due
    >>> to bad implementation.
    >>>
    >>> As well as the remote end needing the holes in the firewall it would
    >>> need to know to pass such traffic to the phone's *internal* IP.
    >>>
    >>> HTH
    >>>

    >> Seconded. SIP ALGs are a PITA. I'd like to know what warped mind thought
    >> smart to mangle and mingle SIP traffic and rewrite IP addresses in the
    >> packets on the fly. @*%^$@@%&*
    >>
    >> Also, set up the outbound proxy in the remote phone to use the same IP
    >> of the registrar.
    >>
    >> You don't need this for phones in the same net/subnet of the PBX, but
    >> it's a given in this case.
    >>
    >> You don't know what type of connection the remote BT engineer used,
    >> possibly he had assigned a public IP to the phone, or opened ports, or
    >> the router had trigger ports configured, or...
    >>
    >> If you have a decent router at the remote site (like a Draytek) PLEASE,
    >> PLEASE remember to set up proper firewall rules to drop incoming traffic
    >> on port 5060 from other IPs than your PBX public IP, when you open it
    >> and NAT it to the phone's IP.
    >>
    >> Similarly, as you have open ports on your main office router, *firewall,
    >> firewall, firewall*. Not as much the RTP ports, but 5060 UDP. An open
    >> UDP 5060 is just an invitation for nasty people to hammer your PBX. Open
    >> it to your remote office IP, and to the SIP trunk supplier's IP(s).
    >>
    >> If you don't (WHY?) expect a lot of attention from "friendly-scanner"
    >> and prepare for the risk of toll fraud.
    >>
    >> Oh, check that the BT PBX uses *UDP* 5060 for SIP, and not TCP. Some
    >> oddball systems do (Lync, anyone?) - "Embrace and extend" from Microsoft
    >> again!

    >
    >I set up a LAN-to-LAN VPN between the two sites, and got the BT man to
    >re-configure the IP phone as if it were on the same site as the PBX.
    >Took it to remote site - worked OK immediately.
    >
    >Much simpler than setting up port forwarding and firewall rules at both
    >sites ...


    <punch> That's the way to do it!
    </punch>

    --
    Graham.

    %Profound_observation%
    Graham., Dec 6, 2013
    #7
  8. Graham J

    ßodincus Guest

    | · : · : · : · : · : · : · Original Message · : · : ·: · : · : · : ·
    | From: Graham J
    | Date: 06/12/13 13:47

    > ßodincus wrote:
    >> | · : · : · : · : · : · : · Original Message · : · :· : · : · : · : ·
    >> | From: Dave Saville
    >> | Date: 05/12/13 09:59
    >>
    >>> On Thu, 5 Dec 2013 08:34:14 UTC, Graham J <graham@invalid> wrote:
    >>>
    >>>> The remote phone has the public IP of the IP Office site coded into it
    >>>> by the Openreach engineer - I watched him do it. This appeared to be
    >>>> the only configuration change that was necessary on the IP phone.
    >>>>
    >>>
    >>> It is often a *good thing* to disable any SIP-ALG code on routers.
    >>> It's supposed to help from behind NAT but usually gets in the way due
    >>> to bad implementation.
    >>>
    >>> As well as the remote end needing the holes in the firewall it would
    >>> need to know to pass such traffic to the phone's *internal* IP.
    >>>
    >>> HTH
    >>>

    >> Seconded. SIP ALGs are a PITA. I'd like to know what warped mind thought
    >> smart to mangle and mingle SIP traffic and rewrite IP addresses in the
    >> packets on the fly. @*%^$@@%&*
    >>
    >> Also, set up the outbound proxy in the remote phone to use the same IP
    >> of the registrar.
    >>
    >> You don't need this for phones in the same net/subnet of the PBX, but
    >> it's a given in this case.
    >>
    >> You don't know what type of connection the remote BT engineer used,
    >> possibly he had assigned a public IP to the phone, or opened ports, or
    >> the router had trigger ports configured, or...
    >>
    >> If you have a decent router at the remote site (like a Draytek) PLEASE,
    >> PLEASE remember to set up proper firewall rules to drop incoming traffic
    >> on port 5060 from other IPs than your PBX public IP, when you open it
    >> and NAT it to the phone's IP.
    >>
    >> Similarly, as you have open ports on your main office router, *firewall,
    >> firewall, firewall*. Not as much the RTP ports, but 5060 UDP. An open
    >> UDP 5060 is just an invitation for nasty people to hammer your PBX. Open
    >> it to your remote office IP, and to the SIP trunk supplier's IP(s).
    >>
    >> If you don't (WHY?) expect a lot of attention from "friendly-scanner"
    >> and prepare for the risk of toll fraud.
    >>
    >> Oh, check that the BT PBX uses *UDP* 5060 for SIP, and not TCP. Some
    >> oddball systems do (Lync, anyone?) - "Embrace and extend" from Microsoft
    >> again!

    >
    > I set up a LAN-to-LAN VPN between the two sites, and got the BT man to
    > re-configure the IP phone as if it were on the same site as the PBX.
    > Took it to remote site - worked OK immediately.
    >
    > Much simpler than setting up port forwarding and firewall rules at both
    > sites ...
    >

    You can do that with one, two, and a handful of remote extensions, then
    you run out of VPN resources on your main office router.
    It's not a replicable model and introduces a further level of
    complexity, traffic overheads and requires expensive kit.
    Horses for courses, I guess.

    --
    ßodincus - The Y2K Druid
    ßodincus, Dec 6, 2013
    #8
  9. Graham J

    Graham J Guest

    ßodincus wrote:
    [snip]
    >>
    >> I set up a LAN-to-LAN VPN between the two sites, and got the BT man to
    >> re-configure the IP phone as if it were on the same site as the PBX.
    >> Took it to remote site - worked OK immediately.
    >>
    >> Much simpler than setting up port forwarding and firewall rules at both
    >> sites ...
    >>

    > You can do that with one, two, and a handful of remote extensions, then
    > you run out of VPN resources on your main office router.
    > It's not a replicable model and introduces a further level of
    > complexity, traffic overheads and requires expensive kit.
    > Horses for courses, I guess.



    True.

    At this site I only have routers that will support a VPN because the VPN
    will be needed anyway for other purposes.

    I think from what people have said here both sites require ports open to
    the PBX and to the remote phone, and for security both sites will
    require static IP addresses so suitable firewall rules can be set up to
    block traffic from all but the desired sites.

    For a large number of remote extensions there may be a limit as to the
    number of firewall rules that can be implemented, in the same way as the
    router may limit the number of VPN tunnels.

    The BT engineer showed me documentation that said BT would only
    guaranteee operation where they had provided all the internet
    connections (PBX site and all the remote extension sites), and had
    BT-provided routers (2-wire) at all these sites.

    I've seen other equipment which only requires ports opened on the router
    at the PBX site - but it would be fair comment that the remote extension
    site should always have a static IP address so the firewall rule can be
    created.

    In this instance the main problem was that the purchaser did not ask
    independent advice before committing to a system from BT. The whole
    project has been compromised by inadequate control of suppliers (the
    builder and BT in particular)!!!!


    --
    Graham J
    Graham J, Dec 7, 2013
    #9
    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. Marc

    Office 97 to Office XP User guide upgrade

    Marc, Apr 14, 2004, in forum: Microsoft Certification
    Replies:
    0
    Views:
    589
  2. Jimmy Clay

    Microsoft Office Specialist Study Guide Office 2003 Edition

    Jimmy Clay, Sep 10, 2004, in forum: Microsoft Certification
    Replies:
    2
    Views:
    1,305
    Guest
    Sep 10, 2004
  3. =?Utf-8?B?SGFyZGlw?=

    Front Office and Back Office Upgrade

    =?Utf-8?B?SGFyZGlw?=, Apr 8, 2006, in forum: Microsoft Certification
    Replies:
    0
    Views:
    525
    =?Utf-8?B?SGFyZGlw?=
    Apr 8, 2006
  4. Replies:
    1
    Views:
    931
    Zeta Reticulae
    Aug 19, 2003
  5. Tommy

    office to office connection??

    Tommy, May 1, 2004, in forum: Computer Support
    Replies:
    0
    Views:
    534
    Tommy
    May 1, 2004
Loading...

Share This Page