When GVC3200 video conferencing devices are used with IPVideoTalk cloud service, up to 49 video feeds can be supported. However, when used with UCM6300 series, the max video feeds supported from UCM is 9. This is because UCM6300 series video conference is different from IPVideoTalk cloud service for mixing/forwarding the video feeds. The video feeds displayed on GVC3200 series also rely on GVC3200 series model's capability of SFU/MCU support.

- UCM6300 series uses SFU (Selective Forwarding Unit) to receive and forward video streams for each video participant. The video participant device receives multiple video streams from UCM for each video feed, and needs to support SFU to decode all video streams before displaying them.

- IPVideoTalk uses MCU (Multipoint Control Unit) which mixes all video feeds into one video stream so the participants only decode one video to see all parties' video.

For GVC3200/3202, it currently only supports MCU and can only display one video feed from the UCM which is the video conference moderator. Other participants' video feed currently cannot be seen. For GVC3210, SFU is supported and up to 9-way video can be displayed (conference control not fully supported on GVC3210 and compatiblity to be improved).

- For conference with 4 or less video feeds:

The required bandwidth for each participant (in Mbps) = (A*1+B*0.172)*1.2+0.1

A is the number of 1080p video feeds (A = 0 or 1);

B is the number of participants excluding A. (B= Total number of participants - A);

1.2 represents the consideration of extra video bandwidth cost such as packet headers;

0.1 represents the bandwidth for audio.

- For conference with more than 4 video feeds:

The required bandwidth for each participant (in Mbps) = X*0.172*1.2+0.1

X is the number of total participants;

1.2 represents the consideration of extra video bandwidth cost such as packet headers.

0.1 represents the bandwidth for audio.

- For conference with screen sharing on:

The required bandwidth for each participant (in Mbps) = (X*0.172+0.512)*1.2+0.1

X is the number of total participants,

1.2 represents the consideration of extra video bandwidth cost such as packet headers.

0.1 represents the bandwidth for audio.

Note:

The above calculation applies to bandwidth required for each participant. To estimate the bandwidth required for UCM6300 series, please consider the number of participants and add them together.

For 1080p video: 1Mbps/15fps.

For 720p video: 512kbps/15fps.

For 360p video, 172kbps/15fps.

For screen sharing, 512kbps/5fps.

The above configurations can be modified per user’s preferences and it may impact the overall max number of allowed conference attendees depending on the trade-offs between video quality and max number of attendees.

Navigate to PBX Settings->General Settings and configure the "Conference Voice Quality" option. If set to “Full Band HD Voice”, 48KHz sampling rate will be used for Opus codec and the audio quality using Opus will be notably better.

Note:

When "Full Band HD Voice" is selected, "Max Number of Video Feeds" in the Call Features->Video Conference->Conference Settings page is currently limited to 4. Pending enhancements in future firmware releases may possibly lift this performance limit.

UCM6300 series use rsync and port 873 for LDAP syncing. There is currently no way to modify this port number. Regardless of this, UCM6300 series can still retrieve LDAP phonebooks from the UCM6200 series/UCM6510 without needing to modify the LDAP sync port on the UCM6200 series/UCM6510. However, the UCM6200 series/UCM6510 are currently unable to retrieve phonebooks from UCM6300 series. This will be addressed in a later UCM6200 series/UCM6510 firmware.

- NACK:

By enabling negative-acknowledgement (NACK), the UCM6300 series will retransmit packets that have been lost in the initial transmission to repair the media stream.

- NACK+RTX:

It’s a mechanism based on NACK, which means it relies on RTCP packets to find out which packets are lost first. For NACK, it will retransmit based on the original packet. With RTX, a special payload is used to retransmit the packets that a NACK request indicated as lost. Retransmitted packets are sent in a different stream from the original media stream. The payload of the retransmission packet contains the payload header of the retransmission followed by the payload of the original packet. RTX retransmits using an extra ssrc, which will be marked in SDP during negotiation.

NACK+RTX can have more accurate statistics and it’s recommended for RemoteConnect users if there is packet loss during usage.

Enabling NetEQ on the UCM6300 series helps reduce the effects of packet loss on audio received by the UCM.

It is a dynamic jitter buffer and error concealment algorithm used for hiding the negative effects of network jitter and packet loss. It helps keep latency as low as possible while maintaining the highest voice quality.

Note:

Enabling NetEQ will help with minimizing the effects of packet loss on audio received by the UCM6300 series. If there is packet loss in the audio sent from UCM to an endpoint, then the endpoint will need to handle it with its own packet loss mitigation implementation. NetEQ is used in WebRTC for audio QoS purposes. As such, UCM6300 series’ Grandstream Wave, which uses WebRTC, comes with NetEQ support.

This is because the UCM6300 series use self-signed certificate for web server by default. To avoid this issue, you could use UCM RemoteConnect plan for the UCM6300 series, which will provide domain name for the UCM. When users access Wave Web or admin accesses UCM Web portal, the web server will trust it and allow access.

You could also purchase domain name and certificate from other parties. Then upload the certificate to UCM6300 series web UI->System Settings->HTTP Server->Certificate Settings.

The UCM6300/6200/6510 series follow the rules below when providing the end devices Config server URL based on UCM WAN/LAN address.

1. UCM network interface method: Dual

1）If the end device is in the same subnet as UCM LAN 1, Zeroconfig provisioning URL will be based on UCM LAN 1 IP.

2）If the end device is in the same subnet as UCM LAN 2, Zeroconfig provisioning URL will be based on UCM LAN 2 IP.

3）If the end device IP does not appear to be in the same subnet as UCM, for example, UCM LAN1 IP: 192.168.129.88, UCM LAN2 IP: 192.168.2.1, end device IP: 10.16.254.68, Zeroconfig provisioning URL will be based on UCM LAN 1 IP.

2. UCM network interface method: Route

1) If the end device is in the same subnet as UCM LAN, for example, UCM LAN IP is 192.168.2.1, end device IP is 192.168.2.100, UCM WAN IP is 10.16.254.68:

1a) If end device IP is in UCM Zeroconfig subnet whitelist, Zeroconfig provisioning IP will be based on UCM WAN IP.

1b) If end device IP is not in UCM Zeroconfig subnet whitelist, Zeroconfig provisioning IP will be based on UCM LAN IP.

2）If the end device is in the same subnet as UCM WAN, for example, end device IP: 192.168.129.88, UCM WAN IP: 192.168.129.66 (they have the same gateway), Zeroconfig provisioning IP will be based on UCM WAN IP.

3）If the end device IP does not appear to be in the same subnet as UCM, for example, UCM WAN IP: 192.168.129.88, UCM LAN IP: 192.168.2.1, end device IP: 10.16.254.68:

3a) If end device IP is in UCM Zeroconfig subnet whitelist, Zeroconfig provisioning URL will be based on UCM WAN IP.

3b) If end device IP is not in UCM Zeroconfig subnet whitelist, Zeroconfig provisioning URL will be based on UCM LAN IP.

3. UCM network interface method: Switch

The Zeroconfig provisioning URL will be based on the UCM network interface IP (only one).

Note:

If UCM network interface method is Dual and “Default Interface” is configured, Zeroconfig provisioning URL will not be based on the UCM default interface setting. It still follows the rule above.