Course13:IT Advanced 2 - 07 Public access to PBX resources (practice)

From innovaphone wiki
Jump to navigation Jump to search

How to setup your system for access from/through the internet

Providing access

When PBX resources shall be accessible externally (that is, from outside your local network), incoming and outgoing traffic must be able to flow between all participants.

Let's see which building blocks we have.

Port forwarding

When a device which is part of the PBX system is located outside the private network of the PBX (for example, a screenshot.png mobile phone with mobile internet access), it can not connect to the devices within the private network (e.g. the PBX) directly.

This is because the devices in the private network are hidden behind the internet router (and/or possibly a firewall). However, the external device can connect to the router itself (as the router has an external interface with an accessible public IP address). The router in turn can use a technique called port forwarding to forward connections to a specific TCP or UDP port. With port forwarding, incoming data on a specific port is forwarded to a device within the private network (hence the name). The router can do this, cause it has also an internal interface with a locally accessible private IP address.

Port forwarding must be screenshot.png configured in the router.

Reverse proxy

There are some issues with port forwarding though.

Selective forwarding


First of all, port forwarding will forward all traffic that matches the port specification. For example, if HTTP is forwarded to the PBX, every HTTP request that comes from the internet is sent to the PBX. This of course also includes malicious attackers. You don't want that. So you need a technique to limit the forwarded data to legitimate requests.

But there is another issue. Let's assume we do have an screenshot.png application platform in addition to the PBX. Clients need to establish HTTP(S) connections to both the PBX and to the AP. Both are using ports 80/443. So port forwarding would send all traffic to either the PBX or the AP but there is no way to differentiate.

One solution would be to configure all clients so that they would screenshot.png use non-standard ports (e.g. port 443 towards the PBX and 444 to the AP). But this clearly results in a messy and hard to maintain setup.

A technique is needed that is able to forward connections based on the content. In our example, this technique would look into requests and forward those directed to hq.dvl-ckl2.net to the PBX and those directed to apps.dvl-ckl2.net to the AP.

Reverse proxy
Both issues are fixed using a network entity known as reverse proxy. It is part of the innovaphone operating system and therefore available on all gateway platforms. The reverse proxy screenshot.png receives connections from the internet router via port forwarding and is able to filter legitimate requests and forward them to the appropriate target.

The reverse proxy
  • listens on the ports used by the protocols it handles (HTTP/S, H323 TCP/TLS, SIP/S, LDAP/S)
  • incoming connections are immediately accepted (that is, the TCP connection is terminated locally on the reverse proxy)
  • incoming data is buffered and looked at until a routing decision can be taken (deep packet inspection)
  • if there is a defined target for the incoming connection, a new connection is established to the target service (e.g. the PBX)
  • if this connection is accepted and not disconnected immediately, the original connection is kept and all traffic is passed back and forth between the two ends
  • otherwise, the original connection is closed
  • if a requester sends too many rejected connection establishments in a period of time, the requester is put on a black-list for a while
  • requests from requesters on the black-list are rejected no matter what
The reverse proxy's configuration defines
  • a screenshot.png port to listen to for each protocol
  • a set of screenshot.png conditions the incoming request must match. The exact nature of the condition(s) depends on the protocol (we'll see that later)
  • a target (IP address and port) for each local connection depending on the fulfilled condition

Outgoing connections

While we have seen that both port forwarding and a reverse proxy are required for incoming requests, outgoing requests usually do "right away".

Just like your browser is able to reach out for class.innovaphone.com, your SIP trunk (using its SBC function) is able to connect to your SIP provider. Note that your SIP trunk always connects to your SIP provider, not the other way round (except for the rare case where the provider works in a non-registered mode).

It is good to understand that outgoing connections screenshot.png do not pass through the reverse proxy and also do not require any port forwarding on the internet router.

Media data

Unfortunately, screenshot.png media data behaves a bit different and therefore other solutions are required (if you feel like digging more in to the details, see Public Access to PBX Resources (theory) - optional for a more in-depth discussion).

The media data protocol (RTP) uses UDP and is essentially connectionless. No reverse proxy solution can be applied therefore.

When one peer has a public IP address (such as a SIP provider or the mobile phone in our example), then the solution is rather simple: the peer within the private network (e.g. the IP phone) sends data to the mobile phone (which is possible just like you are able to send data to class.innovaphone.com). The internet router sends the packets to the public IP address of the mobile phone and employs a technique called NAT, which replaces the source IP address (the private IP address of the IP phone) with its own public IP address and the source port with some random (but unique) port. When the mobile phone sends back data, the internet router forwards it back to the IP address and port where the original data packet came from. Every internet router has this function.

STUN

Unfortunately, this doesn't work when screenshot.png peers within two different private networks need to communicate. Neither of the phones have a public IP address the data could be sent to.

The solution is to find out the public IP addresses of the respective internet routers and to send the data there instead. To find out these addresses, a service called STUN is used. A STUN server resides in the internet (that is, it has a public IP address). Both phones would first screenshot.png send a request to the STUN server that allows them to find out the public IP address of their respective routers. These addresses are then exchanged (using the SIP or H.323 signalling, not RTP) and both phones now know where to send their data to.

(Further Hints) A STUN server is required and it must have a public IP address. Different peers can use the same STUN server or use different STUN servers.

Usually, your SIP provider will run a STUN server that you can use.

(Further Hints) It is not a good idea to use innovaphone's STUN server. Although this server would yield the same results, there is no guarantee of availability. Your ISP or SIP provider's STUN should do better

TURN
Again, unfortunately, the STUN approach may work or it may not, depending on the type of internet routers used on both ends. For a 100% reliable solution, an additional technique called TURN is used.

A TURN server is an accessible server (also available as part of the innovaphone operating system) where both peers send their media data to. The TURN server then would shovel the data back and forth between the two peers.

The TURN server is usually run by yourself (as opposed to the STUN server). It would be screenshot.png located in one of the customers locations (usually the headquarters).

(Further Hints) In this scenario it is essential that all peers use the same TURN server.

While TURN theoretically can forward RTP data between TURN servers, they would suffer from the original RTP problem they are employed to fix. However, in larger scenarios it is possible to use multiple TURN servers screenshot.png provided that all of them have a public IP address (that is, reside in the internet). This requirement is usually hard to fulfil for customers.

More precisely, the two TURN servers would need to be able to talk RTP together. This could be possible even if they are not both located in the internet with public IP address (for example, it would work if both are located in the same private network segment).

Checking the candidates in myApps
myApps has a nice tool to help see which STUN/TURN will be used. For this, you need to configure and start the softphone App. You can then video2.png see the result of an ICE negotiation in the settings and verify that it matches your expectations (especially the SRFLX (STUN) and RELAY (TURN) candidates cause those depend on your correct configuration).

Summary
(Further Hints) In order for the system to work properly, you must use proper STUN and TURN server!

The full picture

To provide external access, we end up with the screenshot.png complete picture of components required.

Looks more difficult as it is, because

(Further Hints) you can run the PBX, TURN server, reverse proxy and SBC on the same innovaphone box!

That simplifies screenshot.png the picture quite a bit smile

Consolidation of services on one box is of course not a yes/no question. All variations are possible from "all-in-one-box" to "each-service-its-own-box".

(Further Hints) One common setup is to screenshot.png have the PBX in the private network and one additional box that runs SBC, reverse proxy and TURN server in a DMZ.


Port conflicts

But hey, wait a moment.

As we said before, the reverse proxy listens for HTTP(S), SIP(S), LDAP(S) and H323-TCP/TLS requests. In the "all-in-one-box" solution, the PBX would run along with the reverse proxy and it also uses H.323-TCP/TLS, SIP(s), LDAP(S) and HTTP(S). So don't we have a conflict when we run it on the same box?

Yes indeed!

(Further Hints) This is why the RP must be configured to listen on non-standard ports for all services when it runs on a box where a PBX runs.

To make it simpler, you just configure it to use non-standard ports always (although it is not strictly required when it runs stand alone).

This is relevant for the screenshot.png port forwarding you need to configure on your internet router:
  • clients will send their requests to standard ports (so that you don't have to fiddle around with non-standard protocol ports on all devices)
  • therefore, your internet router needs port forwardings for standard ports
  • however, it forwards them to the RP on non-standard ports
  • the RP listens on those non-standard ports
  • and forwards requests to the PBX (and other boxes) on the standard ports again
  • the standard TURN port is forwarded on a standard port directly to the PBX

More details on RP conditions

The exact nature of the conditions an incoming request must match so that is being forwarded depends on the protocol.

Generally, there must be a matching Hosts entry with a valid definition where to forward the request to for both encrypted (HTTPS, LDAPS; SIPS, H.323 TLS) and unencrypted (HTTP, LDAP; SIP, H.323 TCP) traffic.

HTTP

HTTP requests are forwarded based on the Host: and GET header found in the request. For example, when you send an HTTP GET request to the RP that is destined for http://hq.dvl-ckl2.net/somepath then it would contain headers such as
GET /somepath
Host: hq.dvl-ckl2.net
For this request to be forwarded, there must be a screenshot.png rule for Host hq.dvl-ckl2.net with an http://<host> entry that matches /somepath.

The defined URLs are evaluated against a requested URL as follows:
  • one of the defined URLs must match the initial part of the requested URL (head match)
  • if the matching defined URL ends with a slash (/), the remainder of the requested URL (the unmatched part) must not contain a slash
In our example, entries like "/somepath", "/some", "/" or "" would be good. Note that an entry with an empty path matches any path (due to the head match). If you want to specify a rule that only matches if an empty path is present in the request, you need to screenshot.png tick the Default check-mark.

H.323
H.323 requests are forwarded based on the gatekeeper id found in the incoming request. This is a variation of the System Name (a.k.a. domain) found in the PBX/Config/General tab of the advanced UI as follows:
  • the gatekeeper id has the format [physical-location@]domain[/registration-location]
    (both physical-location and registration-location are optional)

  • the physical-location is ignored by the RP for routing decisions

  • the registration-location is ignored by the PBX during registration
For example, in our scenario a registration sent to the master pbx (hq) for a user who is on the slave pbx (branch-b) will be redirected towards the slave PBX with a gatekeeper id of
hq@dvl-ckl2.net/branch-b
The RP would ignore the physical location so its routing decision is done based on the name
dvl-ckl2.net/branch-b
The registration location (/branch-b) is ignored by the PBX so it uses only the optional physical location and the domain (hq@dvl-ckl2.net) when registering the endpoint.

This way, a request with gatekeeper id dvl-ckl2.net/branch-b can be routed differently from a request with gatekeeper id dvl-ckl2.net although both are treated the same by the PBX.

In our scenario (both the master PBX and the slave PBX are located in the same private network and hence serviced by the same RP), you would specify screenshot.png two separate Hosts entries:
  • the first for dvl-ckl2.net, forwarding to the master PBX (172.31.31.2)
  • the second for dvl-ckl2.net/branch-b, forwarding to the slave PBX (172.31.31.3)
For orthogonality, you may even want to create
  • a third entry for dvl-ckl2.net/hq, which is a duplicate of the dvl-ckl2.net entry (as far as H.323 is concerned). This entry would be used for example when the slave PBX redirects a registration for a user who is on the master PBX

SIP
SIP requests are forwarded based on the domain part of the URI in the From: header found in REGISTER and INVITE messages.

LDAP
LDAP requests are routed based on the domain part of the user found in the BIND request.

The user must be either in the form domain\user. (e.g. innovaphone.com\ckl) or in the CN=user, DC=domain, DC=top-level-domain form (e.g. CN=ckl, DC=innovaphone, DC=com). In the latter form, all DC= components are concatenated to form the target domain name (innovaphone.com in this example).

DNS

We need to touch one last issue: how to set up DNS correctly.

For practical reasons you want all devices to be configured the same way. For example, devices that shall register with the master PBX shall use hq.dvl-ckl2.net as Gatekeeper ID (System Name), no matter where they are. However, as we have seen in the previous chapters, we want devices within the local network to connect to the PBX directly and others to connect remotely through the reverse proxy instead.

Let us look at a screenshot.png simple scenario where two IP phones A (local to the PBX) and B (remote) need to register with the master PBX. The master PBX has the domain name hq.dvl-ckl2.net. So this is configured as Primary Gatekeeper on all devices.

IP Phone A should connect to the PBX directly, so the DNS name hq.dvl-ckl2.net should resolve to the master PBX's private network IP address.

IP Phone B however must connect to the PBX through the reverse proxy. As the RP is not directly reachable for IP Phone B, the registration must be sent to the public IP address of Internet Router A. So for IP Phone B, the DNS name hq.dvl-ckl2.net must resolve to the master PBX's private network IP address. How that?

The miracle here is to screenshot.png deploy additional internal DNS servers for each location with local resources. They are configured such that locally available devices resolve with their local IP address. All other name requests are forwarded to the official DNS and resolve to the respective public IP address.

Where to run the internal DNS

Popular choices are the DNS in your active directory or just any innovaphone gateway platform.

(Further Hints) Note however that this DNS must be used not only by all telephony devices but also by all PCs running myApps

How to make sure devices are using the "right" DNS?

DNS settings most likely come along as a DHCP option. That is, within your private network, you need to make sure DHCP delivers a DNS Server 1 option that points to your local internal DNS.
Devices in the wilderness of the public internet will get their DNS server setting from their internet provider. This will be a public DNS server that will use the definitions of your official DNS, which is exactly what you want in this case.

What if I can't run an internal DNS?

In this case, you can try to run the system with the official DNS only. Local devices would then resolve the names to the official (that is, external) IP addresses so that all local traffic would flow through the local internet router.

There are two drawbacks:
  • it might just not work sad
    For this to work, your internet router must support hair-pinning. Not all do
  • it imposes extra (and useless) load on your internet router
    In a smaller scenario this is usually not an issue. However, for larger sites, this may create issues


Reverse proxy and certificates

Server certificate validation

As we have discussed before, the reverse proxy would terminate TLS connections itself (and entertain separate own connections towards the target service). For this reason, the "server certificate" seen by the clients is always the certificate of the reverse proxy (not the certificate of the target service).

Clients usually will validate the CN found in the certificate against the service name they used to connect. For example, a browser which connects to https://hq.dvl-ckl2.net/PBX0/APPCLIENT/appclient.htm will expect to see hq.dvl-ckl2.net in the certificate. The reverse proxy's certificate therefore would need to contain all DNS names used by the services it relays for.

(Further Hints) Practically, the reverse proxy needs a so-called wildcard certificate (e.g. with *.dvl-ckl2.net as subject).

Client certificate validation

The same is true on the other end of the reverse proxy connection (between the reverse proxy and e.g. the PBX). The PBX can validate clients based on the CN found in their certificate (this is actually recommended and the default).

However, the incoming connections for remote clients always originate from the reverse proxy. Therefore, the PBX will always see reverse proxy's certificate as client certificate. The certificate validation therefore must be done by the reverse proxy!

For this to work, some preconditions must be fulfilled
  • the reverse proxy must trust the incoming client certificates (that is, their root certificate must be included in the RPs trust list)
  • the RP rules for H.323 and SIP must always have both the plain and secure target ports defined (for details on this see the Reverse Proxy and PBX Interaction chapter in Public Access to PBX Resources (theory) - optional)
  • the PBX must have the screenshot.png IP address and certificate CN of its RP set in PBX/Config/General/Reverse Proxy Addresses and the Assume TLS check-mark ticked

The complete reference

For this exercise, we will modify the setup we have build up in the previous topic (in Master/Slave Operation) a little bit. Instead of assuming that branch-b is in a remote location, it is now in the same private network as the head-quarters.

While this may seem a bit unrealistic to you (which is true), there are two more or less good reasons to do so
  • we do not have enough gateway platforms to implement 2 PBXS, 2 RPs and 2 internet routers smile
  • it is a good exercise to look at what happens when HTTP or H.323 redirection from master to slave PBX happens across a PBX

     
Coming back to our screenshot.png previous example scenario, assuming that
  • master PBX, RP, TURN server and SBC run on the IP411LEFT (172.31.31.2)
  • the AP runs on the IP411LEFT (172.31.31.12)
  • a slave PBX is running on the IP811
  • your internet router is the IP411RIGHT (172.31.31.2 with a fictitious public IP address 78.54.23.241 which you need to replace by your own)
  • both master and slave PBX are located in the same private network (hence behind the same internet router)
  • we simulate an official DNS on the IP411RIGHT
  • we simulate an internal DNS on the IP811
we end up with this screenshot.png modified setup.

The remainder of this chapter is the complete reference.

We'll walk through all required configuration in the following chapters.

Port forwardings on your internet router

Service
Protocol
Port
Destination address Address
Destination port Int. Port (optional)
TURN
UDP
3478 TURN server (172.31.31.2)
3478 =
TURN
TCP
3478
TURN server (172.31.31.2) 3478 =
HTTP
TCP
80
RP (172.31.31.2) 90 *
HTTPS
TCP
443
RP (172.31.31.2) 453 *
LDAP
TCP
389
RP (172.31.31.2) 399 *
LDAPS
TCP
636
RP (172.31.31.2) 646 *
SIP
TCP
5060
RP (172.31.31.2) 5070 *
SIPS
TCP
5061
RP (172.31.31.2) 5071 *
H.323 TCP
TCP
1720
RP (172.31.31.2) 1730 *
H.323 TLS
TCP
1300
RP (172.31.31.2) 1310 *
= standard port
* non-standard port used by RP

(Further Hints) If you intend to use a separate box for reverse proxy/SBC and TURN (e.g. one located in the DMZ), then you would forward UDP/TCP port 3478 to this box on your headquarters' internet router.

STUN/Turn settings

Setting
Recommended Value
Remark
Created OK by Install?
STUN server
STUN server provided by your SIP provider
(Further Hints) You should avoid using stun.innovaphone.com as there is no service level agreement in place if you do so
TURN server
hq.dvl-ckl2.net
The Install has set up a TURN server on your master PBX
TURN username
your-choice
(Further Hints) Your TURN server should not be used by 3rd parties easily


TURN password
your-choice

(Further Hints) using hq.dvl-ckl2.net as DNS name for the TURN server implies that the TURN server runs on the master PBX. Local clients would resolve that to the local IP address of the master PBX, remote clients would resolve it to the external address of the headquarters internet router (from where it would be port-forwarded to the master PBX).
If you intend to use a separate box for reverse proxy/SBC and TURN (e.g. one located in the DMZ), then you should introduce a new DNS name turn.dvl-ckl2.net.

DNS settings

DNS names in the official DNS

Remark Type of entry Name Value
router
A
router-hq.dvl-ckl2.net 78.54.23.241
master PBX
CNAME hq.dvl-ckl2.net
router-hq.dvl-ckl2.net
AP
CNAME apps.dvl-ckl2.net router-hq.dvl-ckl2.net
slave PBX
CNAME branch-b.dvl-ckl2.net router-hq.dvl-ckl2.net

The A entry for router-hq.dvl-ckl2.net is not strictly required (you could simply change the CNAME entries to A entries pointing directly to 78.54.23.241):

Remark Type of entry Name Value
master PBX
A hq.dvl-ckl2.net
78.54.23.241
AP
A apps.dvl-ckl2.net 78.54.23.241
slave PBX
A branch-b.dvl-ckl2.net 78.54.23.241

But we feel that this type of configuration is clearer and also better manageable once you change IP addresses.

Unfortunately, in this topic when we use the IP411RIGHT as DNS server, we need to use the second version as the innovaphone server does not support CNAME entries at all (however, our DNS client does!).

If you don't have a fixed IP address


When you need to use DynDNS, the table is only slightly different.

Remark Type of entry Name Value
router
CNAME
router-hq.dvl-ckl2.net yourhost.yourdyndns.tld
master PBX
CNAME hq.dvl-ckl2.net
router-hq.dvl-ckl2.net
AP
CNAME apps.dvl-ckl2.net router-hq.dvl-ckl2.net
slave PBX
CNAME branch-b.dvl-ckl2.net router-hq.dvl-ckl2.net

Your DynDNS provider then would have the following setting in its own DNS:

Remark Type of entry Name Value
router A
yourhost.yourdyndns.tld 78.54.23.241

(Further Hints) We're not going to use DynDNS in this course though.

DNS names in the internal DNS

Remark Type of entry Name Value
master PBX
A hq.dvl-ckl2.net
172.31.31.2
AP
A apps.dvl-ckl2.net 172.31.31.12
slave PBX
A branch-b.dvl-ckl2.net 172.31.31.3

If you run a separate TURN server

(Further Hints) If you intend to use a separate box for reverse proxy/SBC and TURN (e.g. one located in the DMZ), then you need another DNS name turn.dvl-ckl2.net.

You would define it in the official DNS to point to your headquarters' internet router:

Remark Type of entry Name Value
TURN
CNAME turn.dvl-ckl2.net
router-hq.dvl-ckl2.net

In addition to that, you would add an entry in the headquarters' internal DNS that points to your extra box:

Remark Type of entry Name Value
local SBC
A
sbc-hq.dvl-ckl2.net private IP address of SBC
local TURN
CNAME turn.dvl-ckl2.net
sbc-hq.dvl-ckl2.net


Firewall settings

Firewall settings can get complex and depend on your actual network setup. We are not going to discuss this in any detail in this course, but you may refer to fish-help.png V13 Firewall Settings for details.

Reverse Proxy settings

Service Ports

The RP runs on the PBX and therefore must listen on non-standard ports (so as to not conflict with the PBX services) and forward to standard ports.

In theory, you could use just any non-standard port but we recommend to use those that are also suggested by the Reverse Proxies PbxManager plugin when screenshot.png Set standard ports (public IP) is not ticked.

Service
TCP Port
TLS Port
Remark
H.323 1730 1310 All services accepted on standard port + 10
SIP 5070 5071
LDAP 399 646
HTTP 90 453

Further global settings are as follows:

Setting
Recommended Value
Remark
Created by
PBXManager?
No IPv4 off
This flag disables IPv4 for the reverse proxy
No IPv6 off
This flag disables IPv6 for the reverse proxy
Log Forwarded Requests off
No log flag should be turned on unless you are debugging an issue
Log Rejected Requests on
To see issues in the Logging App
Blacklist Expiration (min) 5
To avoid manual intervention if a client ends up in the blacklist for whatever reason
Suspicious Requests/min 20

Public NAT router address 78.54.23.241 must be set for incoming SIP requests to the public address of your NAT router.(remember that 78.54.23.241 must be replaced by your internet routers IP address). You can leave this field empty if the RP also performs the NAT router function. If your NAT router offers different SIP ports ( default 5060 and 5061), then you have to specify the port to be used. Since only one port can be specified, only either SIP/TCP or SIP/TLS will work.(Further Hints) only if SIP is required (e.g. 3rd party devices).
SIP trunks do not require this!

Hosts

The following forwarding rules must be created

apps.dvl-ckl2.net

This is your application platform and it serves LDAP and HTTP. No other service types should be forwarded.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323




not forwarded

SIP




not forwarded
LDAP

172.31.31.12
389
636
to access Contacts, e.g. with a bind user apps.dvl-ckl2.net\contacts
HTTP

172.31.31.12 80 443 wildcard, e.g. https://apps.dvl-ckl2.net


branch-b.dvl-ckl2.net

This is your slave PBX. The Name branch-b.dvl-ckl2.net is used for LDAP and HTTP. No other service types should be forwarded.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323




not forwarded

SIP




not forwarded
LDAP

172.31.31.3
389
636
to access the slave PBX LDAP, e.g. with a bind user branch-b.dvl-ckl2.net\ldap-guest
HTTP
/PBX0/APPCLIENT/appclient.htm 172.31.31.3 80 443 myApps client, e.g. https://branch-b.dvl-ckl2.net/PBX0/APPCLIENT/appclient.htm
HTTP
/PBX0/APPS 172.31.31.3 80 443 PBX apps
HTTP /PBX0/session 172.31.31.3 80 443 myApps two-factor authentication
HTTP /PBX0/user.soap 172.31.31.3 80 443 (Further Hints)only if TAPI or SOAP API is used
HTTP /PBX0/ADMIN 172.31.31.3 80
443 (Further Hints)only if the Operator application is used
HTTP /OAUTH2/oauth2_login 172.31.31.3 80
443 (Further Hints)only if OAuth2 authentication is used

The Reverse Proxies PbxManager plugin will create some more entries for use with the legacy myPBX application (e.g. PBX0/MY) . There is no need to keep those unless you do intend to use myPBX. These are

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
HTTP
/PBX0/MY 172.31.31.3 80 443 only required if using myPBX
HTTP
/PBX0/DEVICES 172.31.31.3 80 443 only required if using myPBX
HTTP /PBX0/WEBSOCKET 172.31.31.3 80 443 only required if using myPBX

hq.dvl-ckl2.net

This is your master PBX. The Name hq.dvl-ckl2.net is used for LDAP and HTTP. No other service types should be forwarded. The settings are essentially the same for all master and slave PBXs, except for the target server IP address.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323




not forwarded

SIP




not forwarded
LDAP

172.31.31.2
389
636
to access the master PBX LDAP, e.g. with a bind user hq.dvl-ckl2.net\ldap-guest
HTTP
/PBX0/APPCLIENT/appclient.htm 172.31.31.2 80 443 myApps client, e.g. https://hq.dvl-ckl2.net/PBX0/APPCLIENT/appclient.htm
HTTP
/PBX0/APPS 172.31.31.2 80 443 PBX apps
HTTP /PBX0/session 172.31.31.2 80 443 myApps two-factor authentication
HTTP /PBX0/user.soap 172.31.31.2 80 443 (Further Hints)only if TAPI or SOAP API is used
HTTP /PBX0/ADMIN 172.31.31.2 80
443 (Further Hints)only if the Operator application is used
HTTP /OAUTH2/oauth2_login 172.31.31.3 80
443 (Further Hints)only if OAuth2 authentication is used

Again, the Reverse Proxies PbxManager plugin will create some more entries for use with the legacy myPBX application (e.g. PBX0/MY) . There is no need to keep those unless you do intend to use myPBX. These are

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
HTTP
/PBX0/MY 172.31.31.2 80 443 only required if using myPBX
HTTP
/PBX0/DEVICES 172.31.31.2 80 443 only required if using myPBX
HTTP /PBX0/WEBSOCKET 172.31.31.2 80 443 only required if using myPBX


dvl-ckl2.net

This is your master PBX. The Name dvl-ckl2.net is used for H.323, SIP and LDAP. No other service types should be forwarded.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323

172.31.31.2 1720
1300
Check Certificate must be ticked
e.g. to register at the master PBX with a gatekeeper id location@dvl-ckl2.net or dvl-ckl2.net
SIP

172.31.31.2 5060
5061
(Further Hints) only if SIP registration is required (e.g. 3rd party devices). SIP trunks do not require this!
Check Certificate must be ticked
e.g. to register at the master PBX with a From: address user@dvl-ckl2.net
LDAP

172.31.31.2
389
636
to access the master PBX LDAP, e.g. with a bind user dvl-ckl2.net\ldap-guest
HTTP




not forwarded


(Further Hints) Note that the LDAP entry here is redundant to the LDAP entry for hq.dvl-ckl2.net. It is a convenient short-hand for addressing the LDAP server on the master PBX.



dvl-ckl2.net/branch-b

This is your slave PBX. The name dvl-ckl2.net/branch-b is used for H.323 and SIP. No other service types should be forwarded.

Note that this Host is not created by the PBXManager plugin at all.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323

172.31.31.3 1720
1300
Check Certificate must be ticked
e.g. to register at the slave PBX with a gatekeeper id location@dvl-ckl2.net/branch-b or dvl-ckl2.net/branch-b
SIP

172.31.31.3 5060
5061
(Further Hints) only if SIP registration is required (e.g. 3rd party devices). SIP trunks do not require this!
Check Certificate must be ticked
e.g. to register at the slave PBX with a From: address user@dvl-ckl2.net/branch-b
LDAP




not forwarded

HTTP




not forwarded


dvl-ckl2.net/hq
For orthogonality, you might want to add a similar Host entry for dvl-ckl2.net/hq. As this is a synonym for the master PBX this forwards to 172.31.31.2 instead.

(Further Hints) However, this Host is not strictly required as you can also use the pure domain name (dvl-ckl2.net) to address the master PBX (see above).
Note that this Host is not created by the PBXManager plugin at all.

Service
Path
Target (Out)
TCP Port
TLS Port
Remark
Created by PBXManager?
H.323

172.31.31.2 1720
1300
Check Certificate must be ticked
e.g. to register at the master PBX with a gatekeeper id location@dvl-ckl2.net/hq or dvl-ckl2.net/hq
SIP

172.31.31.2 5060
5061
(Further Hints) only if SIP registration is required (e.g. 3rd party devices). SIP trunks do not require this!
Check Certificate must be ticked
e.g. to register at the slave PBX with a From: address user@dvl-ckl2.net/hq
LDAP




not forwarded

HTTP




not forwarded




Let's do it!

Ok, enough theory. Let's do it!

At first we are going to load a new configuration and config checker by click this link: ReverseProxy

If you have not already done so, please set the mode of your IP811 back to Slave. We will use the IP811 as slave PBX in this book.

To simulate our screenshot.png public access scenario, we will do all the settings required to make public access to our master and slave PBX working.

To simulate the mobile phone being in the internet, we screenshot.png add a WLAN access point to our setup, so that it connects to the same network segment our IP411RIGHT is connected to.

When this is successfully done,
you should be able to determine the mobile phone's IP address (something like 192.168...) and ping to it:
  • on an iPhone, go to Settings / Wi-Fi
  • then tap on the little i next to your WLAN name
  • take note of the IPV4 ADDRESS / IP Address
  • on an Android, go to Settings / Network & connection
  • then tap on Wi-Fi
  • then tap on the network you're connected with
  • scroll down and take note of the IP address

Port forwardings

Port forwardings need to be set on your (simulated) internet route.

So
  • open IP4 / NAT / General
  • to add Port specific forwardings, use the Add new map area and add maps for all relevant protocols which forward to the master PBX (which we intend to use as TURN server and reverse proxy later on), according to the following table
    cannot default bookname when not in book context: in [[:bookref :Port forwardings on your internet router | portmaps ]]
screenshot.png This is a hard work after which you deserve a coffee.

(Further Hints) Keep in mind that in real-life, this has to be done on your real internet router!

STUN/TURN

The STUN and TURN settings are set globally (that is, for all devices) using the screenshot.png Media Global device configuration in the Devices App.

The TURN server has been configured to run in the master PBX by the Install, which is a valid configuration in most cases.

Some settings created by the Install should be changed however according to the table you already have seen:
cannot default bookname when not in book context: in [[:bookref :STUN/TURN settings | stunturn]]

The reason why you don't want to use stun.innovaphone.com as your STUN server is that it is not meant for that. We certainly try our best to keep it available, but there is no guarantee. Your SIP provider will most likely offer its own STUN server, so it's better to use this most likely.

In this course however, innovaphone is your SIP provider, so you can keep stun.innovaphone.com smile

The reason why you don't want others to use your TURN server is that it would impose network and CPU load on our master PBX. The configuration created by the Install (user turn, password turn.dvl-ckl2.net) is easily guessed!

To fix this
  • choose a TURN username (in this course, use turn342823)
  • choose a TURN password (in this course, use ip411 as always)
  • change the TURN credentials in the Media Global device configuration in the Devices App. This will make all your STUN client devices use the new credentials
  • change the TURN User and Password in the STUN/TURN server settings in IP4 / NAT / General (be sure to remove the turn user which the Install has created for you)

Reverse proxy

Now that we have forwarded HTTP, LDAP, SIP and H.323 to the reverse proxy, it's time to configure our reverse proxy on the IP411LEFT (our PBX) so it selectively forwards these requests to the target service.

What the Reverse Proxies PBXManager can do

This is a lot of typing and you better don't do a mistake. Fortunately, the PbxManager's Reverse Proxies plugin is here to the rescue. It can do most of the work for us.

  • open the Reverse Proxies PBX Manager plugin. It should not show any reverse proxy so far
    Note that in this case, it does not matter on which PBX the user you are logged-in with is registered
  • click on Add a Reverse Proxy to add an RP
  • A list of options (the IP411LEFT/master-PBX and the IP811/slave-PBX). As we want to run the reverse proxy on our master PBX, we screenshot.png select the IP411LEFT (PBX - hq.dvl-ckl2.net)
  • in the Settings area, we screenshot.png enable all protocols (with Set standard ports (public IP) not ticked, as we want to use non-standard ports for the RP)
  • click on Add a host
  • screenshot.png add both offered hosts
  • click OK
A screenshot.png fair amount of configuration has been done by the PBXManager plugin (you can see that at Services / Reverse-Proxy). There are entries for dvl-ckl2.net, apps.dvl-ckl2.net and either hq.dvl-ckl2.net or branch-b.dvl-ckl2.net.

Of course, we need entries for both hq.dvl-ckl2.net and branch-b.dvl-ckl2.net! Which one was created depends on the registration PBX of the user you logged-in to myApps with. If it was john.doe, branch-b.dvl-ckl2.net was created (as this is John's registration PBX). If it was ckl, hq.dvl-ckl2.net was created (as this is your registration PBX).

  • you can log out from myApps by deleting the current session (remember how that works?). Or - for the advanced user - you can use another browser (or a private tab in your current browser) and log-in again as the other user
  • you then open the PBXManager Reverse Proxies plugin again
  • you select the correct reverse proxy
  • you add a host
    and now the remaining host is offered to you
  • add this host and
  • finish the configuration with OK
This "trick" works because the plugin offers the PBX you are logged-in to as a host.


What needs to be fixed manually

If you compare the screenshot.png settings created so far with our complete reference for the reverse proxy

you will see that you need to
  • tick the Log Rejected Requests for all service types
  • set Blacklist Expiration (min) to 5
  • set Public NAT router address to the (pseudo) external IP address of your internet router (the IP411RIGHT in this case), e.g. 78.54.23.241
  • at the end your Reverse Proxy settings should screenshot.png look like this

  • remove the /PBX0/MY, /PBX0/DEVICES and /PBX0/WEBSOCKET HTTP paths in the branch-b.dvl-ckl2.net settings as we are not going to use myPBX in the course (or in any vanilla v13 installation)

  • remove the /PBX0/MY, /PBX0/DEVICES and /PBX0/WEBSOCKET HTTP paths in the hq.dvl-ckl2.net settings as we are not going to use myPBX in the course (or in any vanilla v13 installation)

  • add a new host dvl-ckl2.net/branch-b and forward both H.323 (ports 1720 and 1300) and SIP (ports 5060 and 5061) to the slave PBX (172.31.31.3). Make sure that Check Certificate is ticked for both rules

  • (Further Hints) make sure all entries of dvl-ckl2.net point to the master (172.31.31.2). By configuring the Reverse Proxy Plugin with a user of the slave PBX the already existing configuration of dvl-ckl2.net will be overwritten so that it points to the slave PBX (which is wrong of course)

     

Internal DNS

In real life, your internal DNS (if you have one) will most likely be run on a domain controller or any other system maintained by the IT department. So consult your network administrator how to arrange for the necessary changes.

In the course however, we are our own network administrator and we decide to set up the internal DNS on the IP811 (the slave PBX) ourself smile

Now let us create the necessary internal DNS entries:
  • open Services / DNS / Hosts
  • in the New Resource Record area, add A records according to this table
    cannot default bookname when not in book context: in [[:bookref :DNS settings | internaldns]]
  • screenshot.png tick Enable DNS Server to turn on the DNS server
  • Reboot your IP811 afterwards

Change DNS settings

That was the easy part.

Now we must make sure that all our devices (including your PC) use this DNS instead of what they are using currently.

How the DNS setting works

There are two ways how the DNS can be set on an innovaphone device:
  • the device uses DHCP and the DHCP offer includes a DNS Server 1 option.
    This is the case in our training setup. All devices except the IP411RIGHT use DHCP, the IP411RIGHT works as DHCP server and screenshot.png includes itself as Default Gateway, DNS Server 1 and Time Server 1 in the offer

  • or the devices does not use DHCP (or there is no DNS Server 1 option in the offer) and the DNS server is configured statically in IP4/ETH0/IP
We have configured the IP811 as (internal) DNS server now. But we need to solve these issues:
  • this DNS server must be used by all of the internal devices

    This can be achieved by changing the DHCP options offered by the DHCP server (the IP411RIGHT in our case) to send a new value for the DNS server, the IP811

  • our new DNS must be able to also resolve all other DNS requests, not only the names we just entered

    For this, we need to define kind of a default DNS server. That is, each query for a name that is unknown to the server needs to be forwarded to another, "better knowledgeable" server (usually the DNS server of your internet provider). This is often referred to as DNS forwarding.

    For the DNS server in innovaphone devices (which we intend to use as our internal DNS), the configured DNS server setting (see choices above) is used for this. To make sure our (internal) DNS running on the IP811 forwards DNS requests to the IP411RIGHT (which in turn knows and forwards to the DNS server used in your corporate network), its DNS server therefore needs to be set to the IP411RIGHT. Although this currently is the case, it won't be any longer when we have implemented the previous solution (to offer the IP811 as the DNS server used by DHCP clients).

    The fix for this is to screenshot.png turn off DHCP client mode on the IP811 and set IP address, network mask, DNS server and time server manually.
Fair enough?
Then let's configure it:
  • open the IP settings of the IP811 at IP4 / ETH0 / IP
  • set IP Address to 172.31.31.3
  • set Network Mask to 255.255.255.0
  • set Default Gateway to 172.31.31.1
  • set DNS Server to 172.31.31.1
    You may notice that these are exactly the screenshot.png same values currently received from DHCP - double check that all fields are set correctly (otherwise you may loose access to your IP811 later)!
  • change the Mode of the IP811 at IP4 / ETH0 / DHCP from client to disabled
  • double check the IP settings again, then reset the IP811
    You should be able to access the IP811 again after the reset
Your IP811 should now be able to resolve both hq.dvl-ckl2.net (172.31.31.2) and www.google.com (something like 172.217.23.132) in Services / DNS / Query.

If so, we can now configure all other internal devices to use the internal DNS on the IP811 as their primary DNS.

To do so:
  • open the DHCP server settings on the IP411RIGHT at IP4 / ETH1 / Server
  • set DNS Server 1 to 172.31.31.3 (the IP811)
  • click on OK and Renew
    The latter pushes the change to all DHCP clients
The innovaphone devices will take on the new value immediately. You can verify this e.g. on the IP112 at IP4 / ETH0 / IP and IP4 / ETH0 / DHCP.

However, your Windows PC unfortunately disregards the DHCP Renew command we sent earlier from the IP411RIGHT.
To refresh the IP lease on your PC, you have three options
  • unplug the Ethernet cable from your PC and plug it in again
  • or disable/enable your network adapter using windows control panel
  • or issue an ipconfig /renew command in a Windows cmd box (you may need to do Run as administrator for this to succeed)
In any case, in a Windows cmd box the ipconfig /all command should now report the new DNS server (DNS-Server . . . . . . . . . . . : 172.31.31.3) for your adapter.

You can test it by trying nslookup www.google.com in your cmd window. It should output
C:\Users\ckl>nslookup www.google.com
Server: branch-b.dvl-ckl2.net
Address: 172.31.31.3
....
Name: www.google.com
Addresses: <some public IP addresses, google has plenty of them>


Official DNS

In real life, your official DNS will most likely be run by your internet provider. So consult your network administrator how to arrange for the necessary changes.

In the course however, we are our own network administrator and we decide to set up the official DNS on the IP411RIGHT (the router) ourself smile

As you might remember from the DNS chapter above, we need to know the public IP address of our internet router and replace the fictitious address 78.54.23.241 by it.

(Further Hints) Keep in mind, that - as seen from our training network - the public IP address of the IP411RIGHT (which is our simulated internet router) is the IP address it receives from your corporate network. So it will likely be something like 192.168.x.y, 172.16.x.y or 10.x.y.z.

To determine your IP411RIGHT's external address
In our "simulated internet" scenario, this IP address is the (pseudo) public IP address of our internet router.

Now let us create the necessary official DNS entries:
  • open Services / DNS / Hosts
    Note that moodle has already inserted a number of A records, including all of the names we need
  • change the DNS records found in the following table and replace the IP address (which is currently something like 172.31.31.x) to your (pseudo) public IP address determined before (instead of 78.54.23.241 )cannot default bookname when not in book context: in [[:bookref :DNS settings | externaldns ]]

Port conflict

We nearly made it smile

But wait a moment, don't we have a port conflict now? The HTTP server on the IP411RIGHT (which we need to see the advanced UI) runs on ports 80/443. At the same time, we have defined port forwards for 80/443 to the reverse proxy.

Fortunately, the box's firmware is smart enough to detect the conflict and ignores the port forwarding if there is a local listener for the port. Otherwise, you wouldn't be able to administer IP411RIGHT any more.

So to make the port forwarding functional,
  • open the LDAP settings on Services / LDAP / Server
  • turn the LDAP server off by ticking the Off check-mark (we don't need LDAP on our router)

  • open the PBX settings on PBX / Config / General
  • check that the PBX Mode is set to OFF (we don't need a PBX on our router)

  • open the Gateway settings on Gateway / SIP and Gateway / GK
  • check that neither SIPx nor GWx interfaces are defined (we don't need a such interfaces on our router)

  • open the HTTP settings on Services / HTTP / Server
  • change the Port and HTTPS-Port to 81 and 444, respectively

(Further Hints) Note that from this moment on, the IP411RIGHT's advanced UI is not reachable any more, neither using http://172.31.31.1 nor http://00903340007e. You must use http://172.31.31.1:81 from now on!

(Further Hints) In a real-life installation where you don't use an innovaphone box as router, this step may or may not be necessary. Consult your internet router's documentation.

Registrations originating from the RP

Registrations originating from the reverse proxy (seen from the telephone system) are special in two ways.

How the PBX checks the client certificate for TLS registrations

The reverse proxy technically terminates the TLS connection from the client (that is, it accepts and connects the incoming connection). It then creates a new connection towards the PBX.

This implies that
(Further Hints) the PBX always sees the certificate of the reverse proxy rather than the certificate of the registering client for remote registrations!

So how can the PBX verify the client using its certificate which it doesn't see?

The answer is: it doesn't, the reverse proxy does it. This is what the screenshot.png Check Certificate check-mark in the forwarding rules for SIP and H.323 is good for. If it is set, the reverse proxy will
  • check if the client certificate is trusted
  • check if the name in the certificate matches the name found in the registration request
If both is true, then the request will be forwarded using TLS, otherwise it will be sent using TCP.

On the PBX, we have the corresponding Assume TLS check-mark. If
  • the screenshot.png Assume TLS check-mark is set
  • and a registration requests comes in using TLS
  • and it origins from one of the reverse proxies listed in Reverse Proxy Addresses
then the PBX will treat this like a successful certificate based registration (because it assumes that the reverse proxy has done the validation correctly).

(Further Hints) Never touch the Assume TLS nor Check certificate check-mark, unless you really know what you are doing. Improper settings may result in false positive checking of certificate based registrations

SBC registration


Another case is a registration that origins from the box that the reverse proxy runs on but is not forwarded by it. This happens for example when an SBC runs on the same box as the reverse proxy does.

In this case, the incoming registration from the SBC matches the IP address of the reverse proxy (as defined in Reverse Proxy Addresses). The PBX would then only allow a registration only if the Reverse Proxy check-mark is set in the object's Device entry.

You can see that in your setup right now: the two trunks are not registered, neither on the master nor on the slave PBX. In the syslog, you will see entries like

20201102-114804 EP 0 REGISTRATION-DN(172.31.31.2:1300),GK-ID=branch-b%40dvl-ckl2.net,H323=009033410004-SIP1,Reason=Registration Rejected
To fix that, we need to tick the screenshot.png Reverse Proxy check-mark in the trunk object

Why not setting the check-mark also in the trunk-branch-b object?

Well, in normal operation the slave's trunk registers with the slave PBX, the reverse proxy is not involved. In a fail-over situation it depends on how exactly we are set up. In our configuration here in the course, the slave's trunk runs on the same box as the slave PBX. So when the slave PBX is down, the trunk is too. However, if the slave's trunk (more precisely, it's SBC) would run on a separate device, then when the slave PBX fails this separate device would still be functional and the slave's trunk would try to register to the master PBX (as this is the backup PBX then). In this case, the Reverse Proxy check-mark would be required in the object trunk-branch-b too.

Testing

Now that we have set up the internet router, STUN server and reverse proxy correctly, we can do some testing.

To prepare for this, take another look at the screenshot.png test scenario again.

The mobile phone (which is in fact connected to your corporate WLAN) simulates a device in the internet. As such, it should use your official DNS. However, in our scenario, we simulate the official DNS on our IP411RIGHT. So we need to convince the mobile phone to use the IP411RIGHT as DNS server.

Refer to Using a custom DNS on your mobile phone to learn how this is to be done


The last step to prepare is to install the myApps app. You must install it from the App Store (iPhone) or the Play Store (Android). Search for innovaphone myApps.

Let us see if we can run myApps from our master PBX
  • start the myApps app on your mobile phone
  • should you be logged in (which can happen if you have used myApps before on your mobile), make sure that you log out and select the right server
    • tap on the burger menu to open the myApps settings
    • tap on Account security
    • Logout from the Current session
    • in the login form, tap on Switch server
  • type hq.dvl-ckl2.net in to the Server field
  • tap on Config
You will now see the user login form.



Debugging the reverse proxy

For our tests, we'd like to see what is going on of course. One important tool for this is the reverse proxy logging.

To enable:
  • tick all the Log Forwarded Requests and Log Rejected Requests for debugging at Services / Reverse-Proxy on the IP411LEFT (the reverse proxy and PBX),
  • click on syslog on Maintenance / Diagnostics / Logging (and keep this page open, it will show all routing decisions done by the reverse proxy in real-time)




myApps on the master PBX

Let us see what happens when we log-in to the master PBX (that is, when we log-in as a user who is registered with the master PBX).

To do so
  • type ckl as Username
  • type ip411 as Password
  • tap on Sign in
You should be logged-in now.

On the reverse proxy console log, you see something like

20201028-191626 REVERSE-PROXY 13 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443(new)
20201028-191626 REVERSE-PROXY 12 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443(new)
20201028-191627 REVERSE-PROXY 12 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443
20201028-191627 REVERSE-PROXY 13 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/usersapp/picture?sip=ckl&user=ckl&dom=@dvl-ckl2.net -> 172.31.31.12:443(new)
20201028-191627 REVERSE-PROXY 2 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443(new)

The reverse proxy is forwarding HTTP requests to the PBX and the App platform.

Using Apps

So far, we only have started myApps. But what if we need to access Apps on the PBX or on the AP?

To see if PBX Apps work
  • start the PBX Manager App
    This is an App provided by the PBX, not by the AP
You should see all the familiar PBX Manager plugins (including the "coloured" ones).

In the syslog console, we see something like

20201028-195239 REVERSE-PROXY 19 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/app_manager/137758/websocket HTTP/1.1 -> 172.31.31.2:443(new)
20201028-195240 REVERSE-PROXY 5 192.168.178.59 https://apps.dvl-ckl2.net GET /manager/137758/manager-api HTTP/1.1 -> 172.31.31.12:443(new)
20201028-195240 REVERSE-PROXY 3 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/calendar/innovaphone.ManagerCalendarTexts.js H -> 172.31.31.12:443(new)
...
The App is loaded from the PBX (app_manager) and the manager plugins are loaded from the AP (manager-api and ManagerXXX.js etc.).

To see how an App (in this case, the plugin) talks some Apps,
  • Start the Reverse Proxy plugin
In the syslog console, you see something like

20201028-195401 REVERSE-PROXY 4 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/app_manager/137758/websocket HTTP/1.1 -> 172.31.31.2:443(new)
20201028-195402 REVERSE-PROXY 10 192.168.178.59 https://apps.dvl-ckl2.net GET /manager/137758/manager-api HTTP/1.1 -> 172.31.31.12:443(new)
20201028-195402 REVERSE-PROXY 7 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/websocket HTTP/1.1 -> 172.31.31.2:443(new)
20201028-195406 REVERSE-PROXY 16 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/app_manager/137758/innovaphone.ManagerRPs.js HTTP -> 172.31.31.2:443(new)
20201028-195406 REVERSE-PROXY 16 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/app_manager/137758/ManagerRPs.css HTTP/1.1 -> 172.31.31.2:443
20201028-195406 REVERSE-PROXY 16 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/app_manager/137758/ManagerRPsTexts.js HTTP/1.1 -> 172.31.31.2:443
20201028-195424 REVERSE-PROXY 15 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/devices/137758/websocket HTTP/1.1 -> 172.31.31.12:443(new)
20201028-195424 REVERSE-PROXY 1 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/devices/passthrough/0090334000b3/b8cb3c3d-d72a -> 172.31.31.12:443(new)
We see that
  • the plugin is loaded from the PBX (/PBX0/APPS/app_manager/132523/innovaphone.ManagerRPs.js)
  • a websocket connection is established to the Devices App on the AP (/dvl-ckl2.net/devices/137758/websocket)
  • requests are sent to the IP411LEFT to read the RP configuration (/dvl-ckl2.net/devices/passthrough/0090334000b3/b8cb3c3d-d72a) throuh the SYSCLIENT connection
Looks good smile

Using media data

Do you remember what we said about media data earlier in this book?

To ensure media transmission in all situations, STUN and TURN must be used.

To check if
  • the local addresses are enumerated correctly
  • the internet routers IP address is determined correctly (STUN)
  • the TURN server is reached
we can use a nice tool in the softphone App:
  • link_intern.png create a softphone as shown in link_intern.png video tutorials
  • in myApps, start the ckl's softphone App

    At this point, you see the softphone App create a websocket connection to the PBX,

    20201028-202135 REVERSE-PROXY 10 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPS/softphone/137758/websocket HTTP/1.1 -> 172.31.31.2:443(new)

    connect to the Reporting App on the AP (for the call history)

    20201028-202136 REVERSE-PROXY 4 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/reporting/137758 HTTP/1.1 -> 172.31.31.12:443(new)

    get your avatar from the Users App on the AP

    20201028-202136 REVERSE-PROXY 1 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/usersapp/picture?sip=ckl&salt=SWAkSEsM55K -> 172.31.31.12:443(new)

  • tap on the burger menu
  • scroll down to NETWORK

    Here you can verify the settings for the TURN and STUN server

  • tap on the right arrow next to the server settings

    the softphone now will establish STUN / TURN connections and enumerate the local interface IP addresses. The results are
    • one or more HOST addresses (must include the local IP addresses assigned to your mobile by DHCP)
    • a RELAY address (must be the local IP address of your TURN server, in our case the IP411LEFT's address (172.31.31.2))
    • a SRFLX address (must be the public address of your (real) internet router, as assigned by your ISP and reported by the STUN server)

While we are in the softphone's burger menu, you should verify the audio settings.
Therefore,
  • check that Handset is selected in the AUDIO DEVICES section
As we have checked all this, why not try a real call?
To call an internal user
  • leave the burger menu
  • type 14 in to the Search contact field
  • tap on the handset button to place the call
    John Doe's IP111 should ring now
  • accept the call and verify bi-directional audio
If you like, you could also check video (although video data uses the same mechanisms audio does). For this, you would need to start the native myApps client on your PC, log-n as john.doe and redo the above call. When you accept the call with myApps on your PC, you can then start video.

myApps on the slave PBX

Let us see what happens when we log-in to the slave PBX (that is, when we log-in as a user who is registered with the slave PBX).

To do so
  • log-off from myApps
  • in the login form, type john.doe as Username (John's registration PBX is the slave, as you might recall)
  • type ip411 as Password
  • tap on Sign in
You should be logged-in now.

On the reverse proxy console log, you see something like

20201028-214456 REVERSE-PROXY 14 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443(new)
20201028-214456 REVERSE-PROXY 16 192.168.178.59 https://hq.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.2:443(new)
20201028-214456 REVERSE-PROXY 10 192.168.178.59 https://branch-b.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/websocket HTTP/1.1 -> 172.31.31.3:443(new)
20201028-214456 REVERSE-PROXY 16 192.168.178.59 https://branch-b.dvl-ckl2.net GET /PBX0/APPCLIENT/137758/appclient_favicon.png HTTP/1.1 -> 172.31.31.3:443(new)
20201028-214458 REVERSE-PROXY 14 192.168.178.59 https://apps.dvl-ckl2.net GET /dvl-ckl2.net/usersapp/picture?sip=john.doe&user=john.doe&dom -> 172.31.31.12:80(new)

The interesting point is here that the login is initiated towards the master PBX. This why we first see requests for hq. The PBX determines that the user belongs to another PBX and redirects the myApps client there. This is why we then see requests for branch-b. Therefore, myApps is ultimately connected to branch-b.

Updated setup-data Excel

To help you prepare all the data you need to know before you start a multi-site or reverse proxy installation, we provide an updated https://class.innovaphone.com/moodle2/pix/f/xlsx.gif Setup-Data-Multisite.xlsx.

Custom certifcates

For the whole thing to work properly, you need to install custom properties to your system. Read Custom certificates for more details.