With the current REST API version, the task of programmatically managing the utilization of available H.323/SIP Connector licenses is extremely complicated. This is a serious issue, given the fact that the monthly cost of a Connector is more than double the cost of a Host license. Some of the problems are:
- We can either open a Zoom Meeting to accept all incoming H.323/SIP calls (by adding the Host to a Group which has this attribute enabled), or prevent them completely. There is no way to control how many H.323/SIP endpoints will connect to a Zoom Call.
- Opening a Zoom meeting as above, will also enable any Zoom client to Dial-out to any H.323/SIP endpoint, if they connected to the meeting when the setting was enabled.
- The Webhook “Participant Joined” events for an H.323/SIP connection do not offer any identifying information. There is no IP address in the fields and the “username” field provides incosistent information (it could be an E.164 number, a SIP username, a SIP user agent name, or something else). Thus we cannot know who is actually connecting and utilizing a Connector license.
Currently we are planning to install our own Zoom H.323 Room Connector VMs, with a Load Balancer in front, and a Firewall that will dynamically open and close access to this infrastructure from specific IP addresses that users are requesting. The Firewall can also prevent any outgoing TCP packets to ports 1720 and 5060, thus preventing anyone from dialing out to an H.323/SIP endpoint without our application knowing about it.
All this would be so much easier if there was an API call to Dial-out from a Zoom Meeting to an H.323/SIP endpoint. We understand that such an API call cannot produce a result immediately, but the response could simply be something like “Call attempt queued”. In the case that the Dial Out attempt would succeed, we would anyway receive a Webhook “Participant Joined” event about it. A further enhancement would be the capability to add a Unique identifier to this Dial-out API call, which we would receive back in the Webhook event, so that we can positively identify the connection, without ambiguities.