Course13:IT Plus - Public Access to Conference Resources
Jump to navigation
Jump to search
This book also has a start configuration for your AP. So don't forget to click on the 
Load initial lesson configuration to your Application Platform
button once it appears. This may take a while, so bear with us and keep trying 
If you dial 6001 from one of your phones, you will be connected to a conference room and hear an announcement.
Please configure the reverse proxy on Services / Reverse-Proxy to listen to port 453 for HTTPS.
The next step of the configuration has to be made on Services / Reverse-Proxy again. We have to create Hostname entries for hq.dvl-ckl2.net and apps.dvl-ckl2.net which forward HTTPS traffic to the corresponding device ( the IP411LEFT for hq.dvl-ckl2.net and the AP on the IP411LEFT for apps.dvl-ckl2.net).
You need to configure a static IP for your smartphone or PC in the external network. Furthermore the device has to use the external IP of your IP411RIGHT as DNS Server, as we explained it 
in this book
Afterwards please
Therefore go to Services / Reverse-Proxy and add the port 1310 as the H.323/TLS listening port.
Note that the PBX will always listen on port 1300. This means that if you are running a PBX on the same box, the reverse proxy will have to listen on a different port (1310 in our case).
As a result, we have to create the following hostname entry on the reverse proxy.
Check Certificate: By enabling the Check Certificate option the reverse proxy will validate the incoming H.323/TLS registration request against the phone's device certificate. To check if the certificate is valid
Please configure 172.31.31.3 (which is the IP address of the box your reverse proxy runs on, the IP811) as Reverse Proxy Addresses in your PBX and set the Assume TLS checkbox next to it.
Check if the Reverse Proxy checkbox for the hardware Id 0090334f22f9 in John Doe's user object is active. This should be the case as it was done by the provisioning.
To find a free IP address, you can simply temporarily connect the IP111 to your corporate network and see what address it gets assigned. This is the address you can use. To continue the configuration you may want to plug it back to the trainee network for the moment then.
You need to configure the following parameters on IP4 / ETH0 / IP :
Finally, set the DHCP mode to disabled. You will find this option on IP4 / ETH0 / DHCP
You must absolutely make sure that the IP address you are using is not used by another device later on. You might use the help of your network administrator here!
When you plug the phone into your corporate LAN, the device registers with the PBX through the reverse proxy.
Configure the port 5071 as listening port for SIP/TLS requests on Services / Reverse-Proxy .
Set the Public NAT router address to the external IP address of the ETH0 interface of your IP411RIGHT.
As a consequence we have to add the rule for SIP to the existing dvl-ckl2.net entry:
Please note that the Check Certificate checkbox works the same way for SIP/TLS as it does for H.323/TLS. This means that the CN of the certificate must match the registration name and the RP must trust the device certificate or its issuer. Only if both conditions match the request is forwarded to the configured TLS port. Otherwise, the request is forwarded over TCP, if configured.
Please keep in mind that the TLS only flag on the hardware ID is mandatory for a SIP/TLS registration. Without it, the registration attempt would be rejected. To finish our configuration please access the Phone / User-2 tab on your IP111 and configure the following options on User-2:
Even though your phone is registered with the PBX, audio does not work because the start configuration has disabled ICE only for the SIPS protocol on your phone. The reason for this is that we want to simulate a 3rd party SIP device as good as possible, which usually means that ICE is not implemented. We will find a solution to this problem later in the book.
We will set up a TURN server on IP4 / NAT / General . You need to Please use a TURN password that you do not use anywhere else in your setup! Because the TURN password is not encrypted in the Advanced UI, the configuration file or as part of the call signaling, any myApps meeting attendee can view the password in the browser's developer console.
To create this media device configuration proceed as follows:
We will use this feature in our scenario so please enter the following additional values into the media device configurationyou create before:
You can have different external ports (outgoing port of your NAT router) than the TURN server listens on and change the port through a NAT map. This way you don't need to run a separate TURN server for TURN extern shown in the image above.
To start a debug session of the conference web client proceed as follows:
Now open the Conference Diagnostics app and please join the conference with both of your video capable devices (Smartphone + PC).
This book explains how you set up a conference environment and how to troubleshoot it
Overview
In this book we will build on the knowledge from our IT Connect - 08.1 Conferencing book and IT Advanced 2 - 07 Public access to PBX resources (practice) book. So if terms like Conferencing, Reverse Proxy or TURN are new to you, you may want to brush up on them, as we will need this knowledge throughout the course of the book.
We will show you how a conference environment will look like and which tools you can use to troubleshoot problems. Before we begin, please load a new configuration onto your devices:
Upload new configuration to your Devices
This book also has a start configuration for your AP. So don't forget to click on the Load initial lesson configuration to your Application Platform button once it appears. This may take a while, so bear with us and keep trying Before you proceed please make sure you have all requirements for this book as you will need a Wifi access point, a mobile phone, and an free PoE port within your corporate or home network.
After the configuration has been loaded, the conference object is preconfigured, which means we can already use it.
If you dial 6001 from one of your phones, you will be connected to a conference room and hear an announcement.To log into myApps use ckl and ip411 as password.
External access
Just talking internally is a bit boring and not what your customers generally want, therefore we want to expand our scenario to include external participants.
We will start our configuration by setting up the external DNS server, which can be found here Services / DNS / Hosts . Please change the IP addresses of the following DNS records to the external IP address of your IP411RIGHT (that is, the address of the ETH0 interface which is connected to your company LAN):
As a next step all internal devices should use the internal DNS server which is located on the IP811. Therefore please configure 172.31.31.3 instead of 172.31.31.1 as DNS Server 1 on IP4 / ETH1 / Server tab.
As we will see later on, a NAT forward of the HTTPS port (443) is required on the router, which in our case is the IP411RIGHT. To avoid a port conflict between this NAT forward and the HTTPS service of your IP411RIGHT, the HTTPS service is already set to port 444. As a result, you must use either port 80 (no HTTPS) or port 444 (HTTPS) to configure your IP411RIGHT.
You may have noticed that the destination ports of these NAT maps are non-standard ports. Although it is not mandatory to use non-standard ports when using a standalone reverse proxy, it will make your configuration and life much easier by avoiding potential port conflicts. For example, later in this book we will configure the Conference Diagnostics app. The app service of this app runs on the conference interface itself, so you need to have HTTPS access to it.
There are basically 3 ways to join a conference room. All of these methods are available both internally and externally:
- You can simply dial the conference room number from any desk phone, DECT phone, softphone or PSTN phone
- You can use the room's SIP URI, which can be entered into your phone/softphone application
- You can use an HTTP link that allows an external participant to join the conference using a browser with webRTC
The first 2 methods work from the outside both through a SIP trunk and through federation. The third method requires only a browser and Internet access on the caller's end.
Scenario outlook
This will be the goal of our configuration:
DNS
We will start our configuration by setting up the external DNS server, which can be found here - turn.dvl-ckl2.net
- hq.dvl-ckl2.net
- apps.dvl-ckl2.net
IP4 / ETH0 or on the top of your My Devices Page.
As a next step all internal devices should use the internal DNS server which is located on the IP811. Therefore please configure 172.31.31.3 instead of 172.31.31.1 as DNS Server 1 on Your PC must also use the IP811 as DNS server. Therefore, please open cmd (command prompt) on your PC and type in ipconfig /renew
As we will see later on, a NAT forward of the HTTPS port (443) is required on the router, which in our case is the IP411RIGHT. To avoid a port conflict between this NAT forward and the HTTPS service of your IP411RIGHT, the HTTPS service is already set to port 444. As a result, you must use either port 80 (no HTTPS) or port 444 (HTTPS) to configure your IP411RIGHT.NAT mapping
In addition to being the DHCP and DNS server, the IP411RIGHT is also our NAT router. Since the IP811, which is part of our internal trainee network, acts as a reverse proxy, HTTPS, H323/TLS and SIP/TLS requests from the external network need to be forwarded to the IP811.
Since the TURN server is also running on the IP811, TURN/UDP and TURN/TCP from the external network must be forwarded to the IP811 as well.
As a result, we need to create the following NAT maps on IP4 / NAT / General :
| Service | Protocol | Port | Destination address Address | Destination port Int. Port (optional) |
| TURN | UDP | 3478 | TURN server (172.31.31.3) | 3478 = |
| TURN | TCP | 3478 | TURN server (172.31.31.3) | 3478 = |
| HTTPS | TCP | 443 | RP (172.31.31.3) | 453 * |
| SIPS | TCP | 5061 | RP (172.31.31.3) | 5071 * |
| H.323 TLS | TCP | 1300 | RP (172.31.31.3) | 1310 * |
| = standard port * non-standard port used by RP | ||||
Fortunately, these port maps are already created by the start configuration, so we don't have to worry about them.
You may have noticed that the destination ports of these NAT maps are non-standard ports. Although it is not mandatory to use non-standard ports when using a standalone reverse proxy, it will make your configuration and life much easier by avoiding potential port conflicts. For example, later in this book we will configure the Conference Diagnostics app. The app service of this app runs on the conference interface itself, so you need to have HTTPS access to it.Connect myApps through the reverse proxy
The first step in your configuration will be to set up a reverse proxy on your IP811 so that you can open the myApps client from the corporate network. To do this, we need at least one video-enabled device other than the PC you are currently using, as we want to see how video transmission works. You can use either your smartphone (connected to your corporate network via Wifi) or a PC on your corporate network.
Create a listening port
Since the NAT map on your router (that is, the IP411RIGHT) forwards the HTTPS traffic to TCP port 453 on the IP811, the reverse proxy has to listen to this port.
HTTPS traffic to TCP port 453 on the IP811, the reverse proxy has to listen to this port.
on the IP811, the reverse proxy has to listen to this port. Please configure the reverse proxy on Create forwarding rules
The next step of the configuration has to be made on the IP411LEFT for hq.dvl-ckl2.net and 
hq.dvl-ckl2.net and the AP on the IP411LEFT for apps.dvl-ckl2.net).
apps.dvl-ckl2.net).hq.dvl-ckl2.net
| Service | Path: | Target(Out) | TLS: | Default |
| http://<host> | /PBX0/APPCLIENT/appclient.htm | 172.31.31.2 | 443 | Ticked(available only after hitting Apply) |
| http://<host> | /PBX0/APPS | 172.31.31.2 | 443 |
apps.dvl-ckl2.net
| Service | Path: | Target(Out) | TLS: |
| http://<host> | 172.31.31.12 | 443 |
Phone configuration
You need to configure a static IP for your smartphone or PC in the external network. Furthermore the device has to use the external IP of your IP411RIGHT as DNS Server, as we explained it in this book Afterwards please - download the native myApps client for your mobile device (android or iOS) and enter the server address: hq.dvl-ckl2.net
- use john.doe as username and ip411 as password to log in to myApps
Accessing myApps meeting through the reverse proxy
In our IT Connect book IT Connect - 08.1 Conferencing we already talked about the possibilities on how to create a myApps meeting HTTPS link.
Using the link is extremely easy as all you have to do is paste the link into any browser. Looking closely at the URL, we can already see that we don't need to do anything on the reverse proxy because the URL starts with https://hq.dvl-ckl2.net/PBX0/APPS/... and we already implemented an HTTPS rule to forward such a path to the PBX.
the URL starts with https://hq.dvl-ckl2.net/PBX0/APPS/... and we already implemented 
starts with https://hq.dvl-ckl2.net/PBX0/APPS/... and we already implemented an HTTPS rule to forward such a path to the PBX.
such a path to the PBX.The technology behind myApps meeting is WebRTC. As such myApps meeting requires ICE and DTLS to work.
Registering a phone through the reverse proxy
To complete this exercise you need to have a free PoE port on your corporate network. At the end of this chapter your IP111 will be registered to your IP411LEFT but will be placed inside your company network.
Create a listening port
To register a phone through the reverse proxy, you must tell the reverse proxy to listen on port 1310 for H.323/TLS traffic because this is the destination port of the NAT map for TCP 1300 (which is the standard port for H.323/TLS) on your IP411RIGHT.
to listen on port 1310 for H.323/TLS traffic because this is the destination port of the NAT map for TCP 1300 (which is the standard port for H.323/TLS) on your IP411RIGHT.
because this is the destination port of the NAT map for TCP 1300 (which is the standard port for H.323/TLS) on your IP411RIGHT. Therefore go to Note that the PBX will always listen on port 1300. This means that if you are running a PBX on the same box, the reverse proxy will have to listen on a different port (1310 in our case).Create a forwarding rule
As a next step we have to define a rule that forwards incoming H.323 registration attempts to the PBX. For H.323/TCP and H.323/TLS the reverse proxy will make its decision based on the the gatekeeper identifier. The phone obtains the gatekeeper identifier during the provisioning process through a device configuration of type Phone. If you check your [Phone] dvl-ckl2.net device configuration in your Devices app, you will see that the Gatekeeper ID dvl-ckl2.net is pushed to the phones.
the Gatekeeper ID dvl-ckl2.net is pushed to the phones.
dvl-ckl2.net is pushed to the phones. As a result, we have to create the following hostname entry on the reverse proxy.dvl-ckl2.net
| Service | Target(Out) | Port | TLS: | Check certificate: |
| H.323 | 172.31.31.2 | 1720 | 1300 | Ticked |
Check Certificate: By enabling the Check Certificate option the reverse proxy will validate the incoming H.323/TLS registration request against the phone's device certificate. To check if the certificate is valid
the reverse proxy will validate the incoming H.323/TLS registration request against the phone's device certificate. To check if the certificate is valid- the name (or CN) of the device certificate must match the the registration name. The CN of each innovaphone device certificate corresponds to it's serial number. Therefore, do not configure any name for this registration. If the name is left empty the serial number of the phone is used as the registration name.
- the RP has to trust the device certificate. Since an innovaphone device certificate is signed by the innovaphone Device Certification Authority (2), this root CA must be part of the RP's trust list.
corresponds to it's serial number. Therefore, do not configure any name for this registration. 
the serial number of the phone is used as the registration name.
Since an innovaphone device certificate is signed by the innovaphone Device Certification Authority (2), this root CA must be part of the RP's trust list.If the certificate is valid, the registration request is forwarded to the PBX via TLS. If the certificate is not valid, the registration attempt is forwarded over TCP.
PBX configuration
To complete the configuration the PBX has to accept the registration attempt.
- The PBX has to be aware of the IP address of the reverse proxy. As a result, you can configure up to 8 different reverse proxy addresses (separated by comma) at
PBX / Config / General - By enabling the Assume TLS checkbox, the PBX will trust a H.323/TLS registration request from the reverse proxy even if the device certificate is not valid. Obviously, this checkbox only makes sense if you have enabled the Check certificate checkbox on the reverse proxy as discussed earlier. Otherwise, you would be opening the door to insecure registrations
- When the PBX receives an incoming H.323/TCP registration request, the request must include a valid password
(separated by comma) at 
the PBX will trust a H.323/TLS registration request from the reverse proxy even if the device certificate is not valid. Obviously, this checkbox only makes sense if you have enabled the Check certificate checkbox on the reverse proxy as discussed earlier. Otherwise, you would be opening the door to insecure registrations Please configure 172.31.31.3 (which is the IP address of the box your reverse proxy runs on, the IP811) as Reverse Proxy Addresses in your PBX and set the Assume TLS checkbox next to it.By default, registrations from the reverse proxy are always rejected unless the Reverse Proxy checkbox is enabled in the user's respective device entry. This allows the administrator to control which devices can and cannot register through the RP.
unless the Reverse Proxy checkbox is enabled in the user's respective device entry. This allows the administrator to control which devices can and cannot register through the RP.
is enabled in the user's respective device entry. This allows the administrator to control which devices can and cannot register through the RP. Check if the Reverse Proxy checkbox for the hardware Id 0090334f22f9 in John Doe's user object is active. This should be the case as it was done by the provisioning.Phone configuration
Before you unplug your IP111 from your trainee network and plug it into your corporate network, you must find a free IP on your corporate network because you will need to configure a static IP on it. The static IP is needed to configure a custom DNS server for your phone, otherwise DHCP will overwrite the DNS configuration.
To find a free IP address, you can simply temporarily connect the IP111 to your corporate network and see what address it gets assigned. This is the address you can use. To continue the configuration you may want to plug it back to the trainee network for the moment then. You need to configure the following parameters on IP address: <a free IP address of your choice>Network Mask: <the netmask of your corporate network>Default Gateway: <the IP address of the default gateway of your corporate network>DNS Server: <the IP address of the ETH0 interface of your IP411RIGHT>
Finally, set the DHCP mode to disabled. You will find this option on You must absolutely make sure that the IP address you are using is not used by another device later on. You might use the help of your network administrator here! Adding third party SIP phones
The goal of this chapter is to register a SIP device through the reverse proxy. To simulate such a registration we will use the User-2 of our IP111.
Create a listening port
Since we always recommend a secure registration, please use SIP/TLS to register your device. Therefore, the reverse proxy needs to listen on port 5071 for SIP/TLS requests.
reverse proxy needs to listen on port 5071 for SIP/TLS requests.
requests. Configure the port 5071 as listening port for SIP/TLS requests on Public NAT router address
You must set Public NAT router address to the external IP address or DNS name of your NAT router because this value will be used in the route header of all SIP messages. You can leave this option empty if your reverse proxy acts as a NAT router as well, since it would simply use its own external IP in the router header. In most cases, the reverse proxy will be independent of the NAT router, so please make a habit of configuring it.
Public NAT router address to the external IP address or DNS name of your NAT router because this value will be used in the route header of all SIP messages. You can leave this option empty if your reverse proxy acts as a NAT router as well, since it would simply use its own external IP in the router header. In most cases, the reverse proxy will be independent of the NAT router, so please make a habit of configuring it.
because this value will be used in the route header of all SIP messages. You can leave this option empty if your reverse proxy acts as a NAT router as well, since it would simply use its own external IP in the router header. In most cases, the reverse proxy will be independent of the NAT router, so please make a habit of configuring it. Set the Public NAT router address to the external IP address of the ETH0 interface of your IP411RIGHT.Create a forwarding rule
The reverse proxy will base its decision on the FROM header of a SIP request. More specifically, it will look at the domain part of the FROM header to determine which rule to apply.
In order to register a SIP phone the PBX will only accept a registration if the domain part of the FROM address matches the system name.
As a consequence we have to add the rule for SIP to the existing dvl-ckl2.net entry: dvl-ckl2.net
| Service | Target(Out) | Port | TLS: | Check certificate: |
| SIP | 172.31.31.2 | 5061 | Ticked |
Please note that the Check Certificate checkbox works the same way for SIP/TLS as it does for H.323/TLS. This means that the CN of the certificate must match the registration name and the RP must trust the device certificate or its issuer. Only if both conditions match the request is forwarded to the configured TLS port. Otherwise, the request is forwarded over TCP, if configured.PBX configuration
The PBX configuration for SIP/TLS is identical to the configuration we did before for H.323/TLS. Lucky for us, we have no need to do anything.
Please keep in mind that the TLS only flag on the hardware ID is mandatory for a SIP/TLS registration. Without it, the registration attempt would be rejected.
is mandatory for a SIP/TLS registration. Without it, the registration attempt would be rejected.Phone configuration
To finish our configuration please access the following options on User-2:
Enable: Ticked
Protocol: SIP/TLS
Domain: dvl-ckl2.net
Proxy: External IP address of your IP411RIGHT
Even though your phone is registered with the PBX, audio does not work because the start configuration has disabled ICE only for the SIPS protocol on your phone. The reason for this is that we want to simulate a 3rd party SIP device as good as possible, which usually means that ICE is not implemented. We will find a solution to this problem later in the book.TURN infrastructure
In the last few chapters, we talked about the TCP protocols HTTPS, H323/TLS, and SIP/TLS, all of which are used to signal a call. Now we want to focus on the transmission of media data. Therefore, we are going to use the UDP protocol RTP, which basically does not require a connection. Voice data is split into packets and sent in sequence to the receiver of the call. Hopefully, all packets arrive at the destination in the correct order, but since UDP is used, the sender does not receive any acknowledgement, it just keeps on sending.
Since we are using IP packets to transmit voice data, we need to overcome NAT boundaries if we want to integrate external participants, which we discussed in our previous book IT Advanced 2 - 07 Public access to PBX resources (practice) . The conclusion was to use a proper STUN and TURN server.
While it is recommended that you configure STUN, as it gives you an additional way to send RTP, it does not work properly across all types of NAT. As a result, you also need to set up a TURN server that reliably solves the problem.
We will set up a TURN server on - tick the Enable checkbox in the STUN/TURN server section and
- configure TURN credentials:
- TURN / User: turn342823
- TURN / Password: ip411
Please use a TURN password that you do not use anywhere else in your setup! Because the TURN password is not encrypted in the Advanced UI, the configuration file or as part of the call signaling, any myApps meeting attendee can view the password in the browser's developer console.You can distribute your STUN and TURN server configuration to all devices, myApps clients, and myApps meeting attendees by configuring a device configuration of type Media in your Devices app.
To create this media device configuration proceed as follows:- open your Devices app in myApps
- navigate to Device configuration in your dvl-ckl2.net domain
- Create a new device configuration of type Media
- Set the following values
- Description: Global
- Apply to all devices: ticked
- Categories: empty
- STUN server: stun.innovaphone.com
- TURN server: turn.dvl-ckl2.net
- TURN username: turn342823
- TURN password: ip411
Once you create this device configuration, the STUN and TURN settings are distributed to all devices. To verify that the devices have received this configuration, go to IP4/General/STUN of any device (e.g. IP4 / General / STUN ). You will see that the configured options are already applied. It is important to distribute the STUN/TURN settings to all PBXs because the myApps client and myApps meeting webRTC clients will receive these settings from their respective PBXs. So please keep this in mind if customers are experiencing audio/video issues on their clients.
TURN extern
You may have noticed that you can also distribute a second TURN server called TURN extern in your media configuration. It is important to note that this second TURN server is only used by myApps Meeting (webRTC) clients when they join a meeting via an HTTPS link.
The idea behind this feature is to overcome firewall problems for external subscribers. Some companies block outgoing TCP traffic on all unknown ports (leaving little more than 80/HTTP and 443/HTTPS) and thus also on port 3478, which is used by TURN. As a result, they cannot connect to the TURN server. The solution to this problem is to use port 443 for TURN, since this is the most likely open port to establish a TURN connection.
Unfortunately, this creates another challenge: because the external port 443 is already being used for HTTPS by myApps clients (and therefore a NAT map for 443 towards our reverse proxy already exists on the router) we would need a second external IP address to solve this issue.
If this is not feasible for your customer, you can use the experimental feature of a TURN fallback server hosted by innovaphone. At the time of writing, this service has not been officially released, but you can use it free of charge. Please keep in mind that there is no service level agreement and that the pricing may change in the future.
Please keep in mind that there is no service level agreement and that the pricing may change in the future. We will use this feature in our scenario so please enter the following additional values into the media device configurationyou create before:
into the media device configurationyou create before:- TURN extern: turn-fallback.innovaphone.com:443?transport=tcp
- TURN extern username: innovaphone
- TURN external password: turn4free
Custom TURN ports
You can configure different custom ports for UDP and TCP on your TURN server. They don't have to be the same port. For example, you can configure UDP port 3478 and TCP port 443 (as long as you do not have a port conflict). In our scenario we do not need to do anything as we will be using the default port 3478 for UDP and TCP. These ports are the destination of the NAT maps created on IP411 RIGHT.
You can have different external ports (outgoing port of your NAT router) than the TURN server listens on and change the port through a NAT map. This way you don't need to run a separate TURN server for TURN extern shown in the image above.TURN Cluster
If you have more than one TURN server, you can combine them into a cluster. All TURN servers in this cluster must be behind the same NAT-router/firewall so that they can reach each other without NAT boundaries. Each of these TURN servers must have a separate UDP-RTP port range (IP4/General/Settings), and each TURN server must know which other TURN server is listening on which port range to avoid hair-pinning. Therefore, you need to configure the local IP address and the first and last port of each TURN server.
into a cluster. All TURN servers in this cluster must be behind the same NAT-router/firewall so that they can reach each other without NAT boundaries. Each of these TURN servers must have a separate UDP-RTP port range (IP4/General/Settings), and each TURN server must know which other TURN server is listening on which port range to avoid hair-pinning. Therefore, you need to configure the local IP address and the first and last port of each TURN server.
All TURN servers in this cluster must be behind the same NAT-router/firewall so that they can reach each other without NAT boundaries. Each of these TURN servers must have a separate UDP-RTP port range (IP4/General/Settings), and each TURN server must know which other TURN server is listening on which port range to avoid hair-pinning. Therefore, you need to configure the local IP address and the first and last port of each TURN server.In addition, your router/firewall must have a load balancing mechanism to distribute the RTP between all the TURN servers.
Integrate devices without ICE
After reading the last chapter about TURN, you may be wondering, "What about external devices that cannot speak ICE or TURN, like the SIP device we previously registered to the PBX?" As teased before, there is a solution to this problem, which we explain in this wiki article.
Video is only available to non-Media Relay endpoints. Keep this in mind if you plan to connect a door intercom using this method.
in this wiki article.A word of advice before you restrict the port range of your TURN server too much. Multi-Video, which we will explain in the next chapter, requires a large number of ports, so do not set the value too low. Without a port to allocate, the connection cannot be established.
To get an idea, we will mathematically break down port usage later in the book, once we have explained multi-video.
Video is only available to non-Media Relay endpoints. Keep this in mind if you plan to connect a door intercom using this method.Multi-video
Now let's dive into the technical mechanics of the conference interface.
The actual resolution and bandwidth of the transmitted video stream may be lower. Depending on the available bandwidth and internet quality, the video stream is scaled down. The above mentioned resolution and bandwidth is the intended target of the video client.
If you call the conference (CONF) or soft conference (SCNF) interface, an audio connection is established first. As you know from the iT Connect training, the conference interface mixes the audio streams of each participant of the conference. When a CONF interface is used, the incoming audio streams are first converted into a common PCM stream, and this PCM stream is then mixed. Each participant receives the mixed audio stream back from the conference interface in its negotiated codec. The SCNF interface, on the other hand, supports only g711a and g711u, so no conversion is performed and no DSP is required.
The video streams are a bit more complex, as each participant in the conference can send up to three different video streams that differ in resolution (low, medium and high).
Low
The low resolution video stream is 160x90 and is capped by a bandwidth of 100 kbit/s.
Medium
The medium resolution video stream is 320x180 and is capped by a bandwidth of 250 kbit/s.
High
The high resolution video stream is 1280x720 and is capped by a bandwidth of 1000 kbit/s. If the webcam cannot send the video in this resolution, the maximum resolution of the webcam will be used.
The actual resolution and bandwidth of the transmitted video stream may be lower. Depending on the available bandwidth and internet quality, the video stream is scaled down. The above mentioned resolution and bandwidth is the intended target of the video client. After the audio connection is established, the caller receives all the information about the conference, such as how many people are in the conference or what their video IDs are. As a next step the client sends an offer for 3 video streams. The conference interface connects the video call and assigns a unique video ID to each stream. At this point, video data is not yet transmitted although ports are allocated and a data path has been found using ICE. Video data is only transmitted if another participant requests to receive a video stream with a specific video ID. If no one subscribes to this video stream, the connection is established, but the bit rate of this stream is 0 kbit/s. In other words, the conference interface tells the client to save bandwidth because no one is interested in this video stream at the moment.
A participant can select a view to see the conference participants. He can either choose a gallery view that displays all participants in medium resolution, or he can have a participant in focus. When a participant is in focus, he will be displayed in high-resolution, and all other participants are displayed in low resolution.
When switching views or at the beginning of the conference, the client sends a request to the conference interface to subscribe to each video stream in its view. If the conference interface already receives a video stream with the requested video ID, it forwards the video stream to the receiver. Otherwise, it wakes up the sender to send video data over the existing connection. In both cases a new video connection from the conference interface to the recipient is established. The sender always transmits its video data to the conference interface and forwards the traffic from there to all receivers. The video data is never sent from peer to peer.
The sender always transmits its video data to the conference interface and forwards the traffic from there to all receivers. The video data is never sent from peer to peer.
to the conference interface and forwards the traffic from there to all receivers. The video data is never sent from peer to peer.It is important to know that 20 subscribers in one view is the maximum value. The client will not subscribe or display more than 20 video streams.
Application sharing
A special case of a video connection is application sharing. If one of the participants decides to share his screen, the high- and medium-resolution video stream will show the application sharing instead of the webcam stream. This (application sharing) video stream is not limited by a 1280x720 resolution, it is always transmitted in its original size. The low resolution video will still transmit the video of the webcam.
Bandwidth and CPU consideration
As mentioned before, we implemented methods to reduce the bandwidth consumption as much as possible, but be aware of the worst case scenario.
The difference between the graph and the simple math we just did is that the graph also takes into account that the local video image from your webcam is not sent to the conference interface and back. The webcam image is displayed locally.
At first glance, you might think that the worst case scenario would be for each participant to send their high-resolution video. This would be the result when each participant has someone else in focus. But once we do the math behind it, you will see that this is not true.
In all calculations of this page we will use maximum values. Therefore all numbers mentioned here will look way more scary than it will be in reality. People tend to use the same view and focus on the same speaker which will result in a lower bandwidth consumption.
First let's look at the down and upstream of the client.
Upstream: The upstream is easy to calculate. We just need to add up the low, medium, and high resolution video in case other participants subscribe to the respective stream. So we add 100kbit/s + 250 kbit/s and 1000 kbit/s and we end up with 1350 kbit/s as the maximum upstream of the client.
Downstream: The downstream depends on the view of the client.
- In the gallery view, the client can display up to 20 video streams of participants, which results in a downstream of about 5 Mbit/s (20 * 250 kbit/s = 5 Mbit/s)
- If the client has one participant in focus in Presentation View, the client will receive one high-resolution video and 20 low-resolution videos. Combined, this results in a bandwidth consumption of 3 Mbps downstream (1000kbit/s + 20 *100kbit/s = 3Mbit/s).
Now let's have a look the conference consumption of the conference interface.
Upstream: As calculated above, one client can receive 5 Mbps from the conference interface. Depending on the number of participants, we need to multiplyy the maximum number of 5 Mbit/s. For example, if there are 20 participants in the conference, the maximum upstream is 100 Mbit/s (5 Mbit/s * 20 = 100 Mbit/s).
Downstream: Since one participant can send up to 1350 kbit/s, we have to multiply this value by the number of participants. If we have a conference with 20 participants, we have a bandwidth consumption of 27 Mbit/s (1350 kbit/s * 20 = 27 Mbit/s).
Since the value depends on the number of participants, the graph illustrates how much bandwidth is needed for the number of participants.Note that the gallery and presentation graphs are two extremes where everyone uses the same view. In reality, the views will be mixed and will therefore end up in between these graphs.
The difference between the graph and the simple math we just did is that the graph also takes into account that the local video image from your webcam is not sent to the conference interface and back. The webcam image is displayed locally. CPU load
In addition to network load, multi-video also causes CPU load. We have a formula to help you calculate your expectation.
CPU% = Bandwidth (in Mbps) / x
x is a variable that varies depending on your hardware device.
- x =0.42 for a xx10 device
- x = 0.18 for IP311 and IP411 devices
- x = 0.56 for a xx11 device
- x = 3.6 for a xx13 device
This means if you have an IP811 as conference device. A conference with 10 participants will cause about 25 Mbit/s, as you can see in the graph.If you enter the values in the formula, you will get the following calculation:
25 Mbits/s / 0,56 = 44,64%
This means that you device should have at least 45% free CPU capacity to handle the conference.
Port consideration
As we already know, the number of ports opened for all connections to and from the TURN server can quickly become quite massive. In this chapter we will focus on the math behind this, so that we end up with a formula that you can use as a guide when building a customer setup.
Of course, we are again using a worst case scenario as an example. This means that we will use the gallery view for our calculation, since it usually displays a higher number of connections.
Audio: 2 ports (1 RTP and 1 RTCP) are allocated by the client and 2 ports are allocated by the conference interface. As a result, we end up consuming 4 ports per participant.
Video send connection: As mentioned before, each participant creates 3 separate video connections to the TURN server and therefore allocates 3 ports. The conference interface, on the other hand, allocates 3 RTP and 3 RTCP ports on the TURN server. This means that we need 9 ports per user for video connections sent from the client.
Video receive connection: Video receive connections are a bit more complicated because they are dynamic. It always depends on how many video streams the user is watching. If you have up to 20 users, the number of ports allocated by the client is always the number of participants other than yourself. The conference interface allocates the same number of ports, but twice the amount, because it also allocates RTCP. This means that the growth is exponential until you reach 20 participants, as this is the maximum number of video streams displayed. After this tipping point, the growth will be steady.
Fast recovery: We also implemented a mechanism to hold up to 5 video receive connections on the client for a quicker connection re-establishment. This mechanism costs 5 ports for the client and 10 ports (5RTP and 5 RTCP) from the conference interface.
Now let's do the math. We will add all port consuming mechanisms together while we use n as a variable representing the number of participants.
Due to the fact that only 20 streams are displayed as a maximum, we need to adjust our formula because the growth stops being exponential after 20 video receive connections.
Example 1
Imagine you have a conference with 10 participants. Which means n=10. This will result in the following calculation:
3*10² + 25*10 = 550 ports.
Example 2
Now let's do the math with 40 participants (n=40). For this calculation, we need to use our second formula, which would result in this mathematical term.
88*40 = 3520 ports.
Troubleshooting the client
Now that we have covered the theoretical side of conferencing and discussed the infrastructure requirements to set up the environment, let's take a look at the myApps Meeting webRTC client.
To start a debug session of the conference web client proceed as follows:- start the conference App (HQ Conf) in myApps
- click on the share button at the righter end of the top line
- click on the share button next to the This conference room is not available text
- copy the URL next to the The share link is as follows: text
- paste the URL into the address bar of a new browser tab
- add the parameter &debug=on to the URL as shown in the image
As soon as you enter the conference room, you will see a magenta information bar at the bottom of your screen. This bar shows all 3 video send connections on your device. The connection status indicates that the connection is already established. Each video connection has been assigned a video ID and the ports are already allocated. Note that no video frames have been sent yet and the bandwidth used is 0 kbps. The reason for this is that no other participant has subscribed to one of your video connections. The video image you see is the local webcam preview image.
magenta information bar at the bottom of your screen. This bar shows all 3 video send connections on your device. The connection status indicates that the connection is already established. Each video connection has been assigned a video ID and the ports are already allocated. Note that no video frames have been sent yet and the bandwidth used is 0 kbps. The reason for this is that no other participant has subscribed to one of your video connections. The video image you see is the local webcam preview image.
at the bottom of your screen. This bar shows all 3 video send connections on your device. The connection status indicates that the connection is already established. Each video connection has been assigned a video ID and the ports are already allocated. Note that no video frames have been sent yet and the bandwidth used is 0 kbps. The reason for this is that no other participant has subscribed to one of your video connections. The video image you see is the local webcam preview image.You may wonder why the graph shows an amplitude. The reason is that you are already sending and receiving audio to/from the conference interface. The magenta graph tells you the current upstream(~5 to 20 kbit/s), while the yellow graph tells you the current downstream (~2 kbit/s). 2kbit/s might seem a little odd but it's actually comfort noise.
Now join the conference via your mobile phone or external device. Since you are logged into John Doe's myApps client, simply join the conference from your softphone to have a second participant.
You can access a similar dialog in your softhone app as well. If you have the app in focus you can press CTRL+i to see this troubleshooting window.
Now join the conference via your mobile phone or external device. Since you are logged into John Doe's myApps client, simply join the conference from your softphone to have a second participant.As soon as a participant joins the conference the graph of the up and downstream will increase. Depending on the client's view, the corresponding video channel will start sending video frames.
will start sending video frames.
Participants and Connections
If you click on the 3 dot icon on the right side of the magenta info bar a further window will appear that allows you to gather more information about the conference participants. At the top, you will see a list of all participants and their available video stream, differentiated by their bitrate (low, medium, and high resolution stream) and their video ID. In the lower area you will see a list of all connections.
on the 3 dot icon on the right side of the magenta info bar 
on the right side of the magenta info bar a further window will appear that allows you to gather more information about the conference participants. At the top, you will see a list of all participants and their available video stream, differentiated by their bitrate (low, medium, and high resolution stream) and their video ID. In the lower area you will see a list of all connections.
that allows you to gather more information about the conference participants. At the top, you will see a list of all participants and their available video stream, differentiated by their bitrate (low, medium, and high resolution stream) and their video ID. In the lower area you will see a list of all connections.- The topmost connection listed is the client's audio connection. Unfortunately, it is hard to read because it is written in black font on a dark gray background.(you can highlight it by marking it with your mouse)
- Below that, you can see all 3 send video connections of the client. These are highlighted in different shades of green. The local address is always the nominated ICE candidate of the myApps meeting client, while the remote address is always a ICE candidate of the conference interface. A candidate can be either host (direct RTP connection), srflx (connection to the STUN received candidate), prflx (direct connection via NAT), or relay (ICE connection via TURN server). In addition, you can see the current bitrate you are sending and how many RTP packets were not received at the destination and therefore dropped. The FIR packets can be quite interesting, as they indicate how often the sender has to send an video frame with full information. Otherwise, only a delta of the previous frame is sent. This means that if the FIR count becomes excessively high, it may indicate that the bit rate is too high for the available bandwidth or that the receiver is overloaded and unable to process the incoming video stream.
- All blue connections are received video streams from different participants. The IP connection details are the same as explained for the send connection. Furthermore you can see who sends a video stream by comparing the video ID to the participants video IDs. You can also see the current download bitrate of this video stream.
. You can also see the current download bitrate of this video stream. You can access a similar dialog in your softhone app as well. If you have the app in focus you can press CTRL+i to see this troubleshooting window. Troubleshooting the conference interface
Since the administrator does not always have access to the clients because the users may be in the home office or dialing into the conference while on the road, there is an app to investigate a problem from the conference interface perspective. This app does not require an app service on the application platform, the app just needs to establish a websocket connection to the conference interface. The app retrieves all necessary information from the conference interface itself.
An A record DNS Entry for conf-box.dvl-ckl2.net to 172.31.31.3 is already created on the DNS Server of your IP8111.
The conference diagnostics app can be set up in a few steps. Please read this step-by-step guide to learn the required steps.
The already configured Conference interface (CONF) is running on your IP811. Please set up a conference diagnostics app in your PBX ( PBX / Objects ) as explained in the wiki article with the following parameters and assign it to the Config Admin template.
this step-by-step guide to learn the required steps. The already configured Conference interface (CONF) is running on your IP811. Please set up a conference diagnostics app in your PBX ( Long Name: Conference DiagnosticsName: conf-diagnosticsPassword: <Configure the same password on the app object as on the app service>URL: https://conf-box.dvl-ckl2.net/CONF/innovaphone-conference-diagnostics
An A record DNS Entry for conf-box.dvl-ckl2.net to 172.31.31.3 is already created on the DNS Server of your IP8111.ICE Event
If a user cannot join a conference at all, the most likely reason is that ICE cannot find an RTP path. In this case, an Error RTP event is generated in the conference interface. The explanation for this error is ICE: No network connection between endpoints and shows you the complete error message including ICE candidates and ICE checks from both sides as raw XML data. We recommend that you create a filter for ICE in your Events application so that you can easily find these error messages.
Usage of the Conference Diagnostics App
Now open the Conference Diagnostics app and please join the conference with both of your video capable devices (Smartphone + PC).
The left column shows all conference rooms currently in use. Those rooms are displayed as a randomly generated number. Below, you can see how many channels are reserved for that room, according to its configuration. If more people enter the conference room than channels are reserved, the conference will be overbooked. In such a case the conference interface will use free channels from the conference interface, but the number displayed in the app will not increase dynamically. It will only display the reserved channels as configured.
according to its configuration. If more people enter the conference room than channels are reserved, the conference will be overbooked. In such a case the conference interface will use free channels from the conference interface, but the number displayed in the app will not increase dynamically. It will only display the reserved channels as configured.
If more people enter the conference room than channels are reserved, the conference will be overbooked. In such a case the conference interface will use free channels from the conference interface, but the number displayed in the app will not increase dynamically. It will only display the reserved channels as configured.The next column lists all participants in the selected conference room. Selecting a user will show all video calls to and from that participant. Note that no audio call information is displayed in this app, but clicking the hang up button next to the audio call will disconnect the call for the selected user.
You should be aware that this app will show all video calls from the perspective of the conferencing interface. This means that video calls marked as Receiving are video streams being sent from the client of the selected user. Video streams marked as Sending are video streams displayed on the client's screen.
At this point, you may have guessed why there are 3 different receiving video connections. Of course, the difference is in the resolution. A client can send up to 3 different streams (low, medium, and high resolution). You can figure out which stream is which resolution based on the bitrate of the video call.
To see which streams the user subscribed to you can have a closer look on the sending connections. If the bitrate of all sending streams is 250 kbit/s, the user is watching the conference in gallery view, otherwise he is using the presentation or focused view. Each sending video stream also displays the name and video ID of that particular stream. This makes it easier to identify a specific problematic stream.
The app shows you the currently used bitrate, jitter and packet loss of each video stream. The round trip time is not displayed correctly at the time of writing so please be aware when using. Click the arrow icon to examine the IP connection, as this will display more information. You will see both endpoint addresses and all candidates that the conference interface has allocated for this connection.
arrow icon to examine the IP connection, as this will display more information. You will see both endpoint addresses and all candidates that the conference interface has allocated for this connection.
as this will display more information. You will see both endpoint addresses and all candidates that the conference interface has allocated for this connection.When you hover over the text video call, you can see the video ID and the connection addresses of both endpoints as a tooltip. This way you can see the video ID for video streams the client is sending.
How to use the app
If a user is reporting that a fish is displayed instead of a video image, the most likely error is that the sender has a narrow upload bandwidth. The fish is displayed by the conference interface instead of the users video stream if the conference interface does not receive sufficient video data but the stream is connected.
To determine if this assumption is correct, the best practice is to open the user reporting the problem in the Conference Diagnostics app, and then identify the problematic video stream by name and bitrate. Write down the video ID to find the video stream in the problematic user's list and verify that the video stream is correct.
Does the problem stream have high packet loss?
Is the conference interface receiving data, which means that the bitrate is not 0 kbit/s?
You should also check the firewall for the IP address and port pairing of the sender and receiver of the problematic video stream.
Are RTP packets arriving in sequence?
Is the firewall forwarding RTP packets for the destination?