Posts in Category "Application"

Vantage Point is not just about Bandwidth

Vantage Point from Refined Data works with Connect and provides remote control of Cameras, Microphones, Telephones, Volumes, Tech Support, Motion Detection, Mouse Detection, Continuous attendance tracking and reporting and much more so it’s not just about bandwidth reduction.

On the bandwidth front, Vantage Point publishes streams to Refined Data servers at 100Kbps for each participant in the room; this is less than Connect in most cases, but the Host only consumes as many streams as they can view at one time. The host can see as few as 5 or 6 students at one time or as many as 50 or more depending on their screen resolution, window size, Vantage Point settings, connectivity and bandwidth availability.

This means that even with 100 Participants in a Connect room and one Host the bandwidth consumption looks like this:

  • Participant Load: 100kbps Up (to publish their own camera to Vantage Point), 100kbps down (to view the Host in Connect). This is a small signature on the network.
  • Host Load: 100kbps Up (to publish their own camera in Connect), 2.5mbps down (assuming they view 25 participant cameras in Vantage Point at one time). The Host is the only one who needs a really good connection.
  • Total Load on Adobe Connect: 1 publish stream + 99 subscribers

The host can always reduce their own load simply by viewing fewer simultaneous Video pods in Vantage Point. The bandwidth load for students or participants is not affected at all by class size. Bandwidth load for Hosts rises linearly with class size but can be limited by the host at any time based on the maximum number of cameras they view at one time.

In Connect, the bandwidth load rises with the number of cameras being shared:

  • 4 Cameras: 16 Connections on the Server, each user publishes 100kbps and consumes 300kbps
  • 10 Cameras: 100 Connections on the Server, each user publishes 100kbps and consumes 900kbps
  • 20 Cameras: 400 Connections on the Server, each user publishes 100kbps and consumes 1.9mbps

Even if Connect could technically support 50 or 100 simultaneous web cams in a single meeting (2,500 streams risks significant latency), consider the requirement that participants would need 5-10mbps of bandwidth to support the load, before accounting for VoIP, screen-sharing and basic overhead. Anything above 10 simultaneous web cameras may be difficult for a host to manage and apart from any other considerations, there may not be enough real-estate for content if you are showing 10 or more web cams in the meeting room.

Vantage Point only publishes at 100kbps, most of the time; DSL and Standard quality is already more than twice this load in Connect and can easily rise higher if the room is set to use the Highest video quality at 16:9. With Vantage Point, Adobe Connect saves the server load, participants are not affected by class size, Hosts can see all of their students, all of the time and enjoy unparalleled control of the classroom environment.

Check it out at Refined Data:

Troubleshooting Caption Colorado Domain Names in Meeting Pod

Issue: Sometimes the Closed Captioning pod fails to connect to Caption Colorado.

Symptom looks like this:


Always make certain you have the correct pod version:

There are two names available at Caption Colorado, one is a legacy name for Breeze and the other is for Connect. Both point to the same TCPIP address:

Address:  xx.xx.xx.xx
Non-authoritative answer:
Address:  xx.xx.xx.xx
Non-authoritative answer:

Workaround: When either of these domain names (Breeze or Connect) fails to connect, use the other. This is a known issue at Caption Colorado and they are working to resolve it. Simply juxtaposing for or visa versa in the pod configuration will solve the connection issue and facilitate closed-captioning.

Meeting Add-in | Mac OS X Mavericks 10.9, 10.8, 10.7 with Safari 6.1 or 7

In case you have not seen, we have published a brief article on the issues with using the Adobe Connect Meeting Add-in with Mac OSX Mavericks and newer versions of  the Safari browser.

Details and instructions (in an additional linked article) on how to suppress the restrictions put in place by the newer browsers can be found here:

Connect on VMWare – some deployment tips

Issue: VMWare is ubiquitous in the enterprise and while it opens up huge potential for management of the Connect infrastructure, it must be planned and executed with an eye toward robustness.

This advice is gleaned from conversations with senior persons on our operations team as well as from support cases generated by various customers with on-premise VMWare deployments of Connect.

One of the most important and often overlooked variables about virtualization is to make certain that  VMware is compatible with all the underlying components of the server and network architecture. The infrastructure supporting VMWare must be verified by VMware under their Hardware Certification Program or Partner Verified and Supported Products (PSVP) program; be sure to use certified hardware.

Here is the link to the compatibility reference:

With Connect you must consider both Tomcat and  FMS; the former can run on most anything, while the latter is a bit more demanding; RTMP can be acutely;y affected by latency and packet transmissions. If you notice unpredicted latency or a surprise crash of FMS with Connect 9.1, a good test would be to check the network components; sniff for packet transmission issues – have the vNIC of the guest VMs configured to use VMXNET3; this is a good place to start.

With reference to recommendations and best practices, it really depends on the VMware infrastructure adopted. The following references serve as a guide for an enhanced environment:

Enterprise Java Applications on VMware – Best Practices Guide:

Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs:

Performance Best Practices for VMware vSphere 5.1:

The key with Network Storage is speed. If you lose connectivity to the shared storage then only what is cached on the origins will be available.

Shared storage requirements

  • Disk specs: 10,000–15,000 RPM — Fibre Channel preferred
  • Network link: TCP/IP — 1GB I/O throughput or better
  • Controller: Dual controllers with Active/Active multipatch capability
  • Protocol: CIFS or equivalent

Avoid, virtualizing the Connect database if possible.

I have seen that in some customer-based VMWare environments that are overtaxed, that latency among the servers on 8507 (and 8506), can cause problems. Intra-cluster latency (server to server communication) should never exceed 2-3ms. When it does we see intermittent crashes. I had one customer who had a particularly weak infrastructure and for whom I could predict his crashes; he was doing back-ups and running other tasks at a certain time weekly that would tax and hamper network connectivity for about an hour; these tasks were so all-consuming on the network, they turned every cluster resource into an individual asset on its own island. The log traces bore this out and we knew with precision what was going on. He knew he needed to upgrade his infrastructure and in the meantime we worked out a reaction plan to deal with the issue; it included:

  1. Place a higher than normal percentage of cache on each server to limit invoking shared storage
  2. Set the JDBC driver reconnection string for Database connectivity
  3. Plan Connect usage around these maintenance activities and when possible, do Connect maintenance activities at the same time as well – not very difficult as these were after hours, but being a  global operation, still not a given.

Presentation Edited in more than one Version of Presenter Hangs on Playback when Published

Issue: Presentation edited using more than one version of Presenter hangs on playback when published.

There is more than one possible cause for this symptom, however when passing around a Presentation for editing by various contributors, you may run into backward-compatibility issues with text highlighting. Text highlighting was introduced in Presenter 9.0 and is not backward-compatible to Presenter 8.1, or earlier versions of Presenter.

Workaround: Rather than rework the content in a single version of Presenter, when text highlighting causes the hanging problem, you may delete the cctexthighlighting entry from the vconfig.xml file in the published output:

  • Publish the problematic content locally into a zip and extract the zip file.
  • Go to “<published output>/data/vconfig.xml”


  • Open the vconfig.xml file using any XML editor (I used Dreamweaver)
  • Delete the following variable in the vconfig.xml file: <uishow name=”cctexthighlighting” value=”true”/>


  • RE-zip the locally published Presentation
  • Publish the edited and zipped Presentation to Connect:



Play the published Presentation either as standalone content or shared in a Connect Meeting Share Pod.

Tunneling with RTMP encapsulated in HTTP (RTMPT) should be avoided as it causes latency

Tunneling with RTMP encapsulated in HTTP or RTMPT should be avoided as it causes latency that can have a negative impact on user experience in a Connect meeting. In rare circumstances,the latency commensurate with tunneling RTMP encapsulated in HTTP, can become so acute that it renders Connect unusable for affected clients. The performance hit commensurate with tunneling is one of the primary reasons we continue to deploy Connect Edge servers as they often can replace third-party proxy servers that are often the cause of tunneling latency..

While the amount of acceptable latency depends on what one is doing in the room; RTMPT tunneling affects most activities. Some activities, such as screen-sharing are more bandwidth intensive than other activities such as presenting an uploaded PowerPoint from within a meeting room; The high latency commensurate with RTMPT tunneling would affect the former more than the latter. VoIP is often the first thing to make the effects of high latency felt. Here is some feedback from a test I did while on site with a client dealing with tunneling because of their refusal to pipe RTMP around a third-party proxy:.

External user tunneling during test:
Spike at 3.10/3.02 sec
Latency 403/405 ms up to 3.53/3.52 sec up .064 down 118
When latency peaks to 2.6/2.4 sec I get a mild interruption to the audio V
Video pauses momentarily when the latency spikes

Internal user with direct connection:
2 msec / 1 msec Up 0.08 kbits down 127 kbits
No pauses, delays or spikes

Tunneling should only be considered as a fallback mechanism or safety net to allow connections when RTMP is blocked due to something unplanned or for a few remote clients who must negotiate specific network obstacles. When RTMPT is the default by network design, you will need to limit your activities within Connect to those feature that use the least bandwidth.

The picture below shows a direct connection over RTMPS on 443 is being blocked somewhere on the client’s network and the fallback mechanism built into Connect of tunneling RTMP encapsulated in HTTPS is the fallback path. This is usually caused by either proxy servers or firewalls or both – any application-aware appliance on one’s network that sees the RTMPS traffic on 443 and recognizes that it is not HTTPS is a potential obstacle; RTMPS traffic is on port 443 and while it is disguised as HTTPS, it still may be blocked. The result is tunneling, indicated by the “T” in the output:


Compare with a connection without tunneling:


The recommended steps for anyone experiencing persistent tunneling, is for their network engineers to trust the source IP addresses of the Adobe hosted, ACMS, managed ISP or on-premise Connect/FMS server VIPs in order to prevent the blocking of RTMPS traffic. RTMPS is not supported by any third-party proxy server. Static bypass works well to solve this issue. The problem stems from network policies that require all traffic to go through a proxy. The result is tunneling with commensurate high latency and drops. RTMPS must be allowed to stream around a proxy to avoid the overhead and latency of tunneling encapsulated within HTTPS. Attempts to cache the stream add no value.

Other options will depend on the capabilities of the third-party proxy servers in the affected client infrastructure. Blue Coat ProxySG is one of the popular proxy server options in our niche. In cases of latency invoked by tunneling RTMP encapsulated in HTTP on a network that employs Blue Coat ProxySG servers, sniff tests done by support representatives have indicated that when an affected client attempts to connect to an Adobe Connect meeting, those clients would establish both explicit HTTP connections based on PAC file settings in the system registry to the Blue Coat ProxySG pool through a hardware-based load balancing device (HLD) and transparent HTTP and SSL connections through Blue Coat ProxySG via WCCP GRE redirect to several Adobe Connect servers. The problem manifests with RTMPS when the clients attempt to establish an SSL connection directly to the destination host without going through PAC file proxy settings. Since a Blue Coat ProxySG is commonly configured to perform an SSL intercept on both explicit and transparent HTTPS traffic, upon examining the content after decrypting the SSL payload from the clients, the Blue Coat ProxySG will return an exception and close the connection because the request doesn’t contain an HTTP component and cannot be parsed for policy evaluation. As a workaround, other than using static bypass, it is possible to create a proxy service with the destination set to the Adobe Connect server IP range on port 443 and to set the proxy setting to TCP-Tunnel with Early Intercept enabled. This will allows Blue Coat ProxySG to intercept and tunnel the traffic without considering whether it is RTMPS or HTTPS.

Watch for a more comprehensive article on this topic forthcoming.

Connect Default Bandwidth Adjustments for On Premise Deployments

In addition to other parameters (like chat pod character limits, connection light thresholds,  etc.) you can adjust the default bandwidth and performance settings for your Adobe Connect meeting room experience via the configuration file reference below. This is applicable for On-Premise installations of Adobe Connect only, and is not for Hosted Adobe Connect accounts.

The location of the internal configuration file on Adobe Connect 9.1.1:

You can throttle these up or down to suit the needs and requirements of your network or infrastructure.
Note: You must cycle the Connect services after making any changes to this file on every node in your cluster (if more than one origin server).

Room Bandwidth Settings:


The first setting you can modify relates to the Optimize Room Bandwidth setting inside of the Meeting > Preferences > Room Bandwidth area of the Meeting UI.  This option gives you the three  Room bandwidth options of ‘LAN’, ‘DSL/Cable’, and ‘Modem’.  These settings throttle production based on the room settings and their associated values below.

These contain the bandwidth settings for ‘Client to Server’ as ‘C2S’ and ‘Server to Client’ as ‘S2C’.

  • ‘Up’ values are the C2S values (‘Client to Server’).  This is most important for screen sharing.
  • ‘Down’ values are the S2C values (‘Server to Client’).

All clients in the room will utilize this single setting.

In Connect 9.1.1 these options correlate to the following values (default):

Room Bandwidth Client to Server Server to Client
LAN 100000 KB/Sec 100000 KB/Sec
DSL/Cable 600 KB/Sec 800 KB/Sec
Modem 200 KB/Sec 200 KB/Sec

Room Bandwidth Settings in Application.xml: 


Camera Settings:


The next values you can modify, correlate to the video settings at Meeting > Video > Video Settings > Video Quality, in the Meeting UI. This option gives you the ability to adjust the slider from the ‘Low’ to ‘High’ values.  The in-between values are actually ‘Medium’ and ‘Standard’.  All of these 4 options actually determine values for Quality, Frames Per Second (FPS), Max Resolution, and Max Widescreen Resolution.  As the menu in the UI indicates, the 4 quality settings are actually also affected by the previous Room Bandwidth setting as shown below:

9.1.1 Adobe Connect Camera Pod Settings (Default):


Camera Setting = Quality FPS Max Resolution Max WideScreen Resolution
Low = 70 8 320×240 427×240
Medium = 75 10 320×240 427×240
Standard = 80 15 640×480 854×480
High = 90 20 640×480 854×480


Camera Setting = Quality FPS Max Resolution Max WideScreen Resolution
Low = 70 4 320×240 427×240
Medium = 75 8 320×240 427×240
Standard = 80 10 320×240 427×240
High = 85 15 640×480 854×480


Camera Setting = Quality FPS Max Resolution Max WideScreen Resolution
Low = 70 4 160×120 214×120
Medium = 70 8 320×240 427×240
Standard = 75 10 320×240 427×240
High = 80 15 320×240 427×240


Camera Pod Settings in Application.xml: 

- <!– LAN –>
- <!– DSL –>
- <!– MODEM –>


Screen Share Settings:


The last applicable setting is for Optimizations with Screen sharing.  In the UI, you can set it to ‘Low’, ‘Medium’, ‘Standard’, and ‘High’.  The below chart indicates what each of the values for these settings (for the ON2 SS Codec) actually are.

SS_ON2 Setting BW Limit Quality FPS Worst Quality Minimum Worst Quality
Low 500 65 2 1 1
Medium 800 80 4 30 15
Standard 1200 90 6 70 30
High 2000 100 8 90 50

SS_ON2_BW_LIMIT is in kb/sec.
SS_ON2_QUALITY defines the compression level (size vs quality).
SS_ON2_FPS defines the target number of frames per second to generate.


Screen Sharing Settings in Application.xml: 

<!– BANDWIDTH_LIMIT in kbps–>
- <!–  QUALITY –>
- <!–  FPS –>

Connect Meeting Session Management

Behavior: There are two variables with reference to Meeting room session management that a good Connect Administrator will want to consider:

  • When you close a Meeting room, it remains active (on Adobe’s hosted accounts) for 15 minutes before completely shutting down.
  • You cannot keep a continuous active Meeting open beyond 12 hours; the Meeting will timeout after 12 hours.

These two variables are important: The first one is good to know because you may not see some changes propagate to a Meeting room until it has been closed for 15 minutes and then reopened. Tonight, for example I was in a meeting and switched the account settings from RTMP to RTMPS to secure all traffic rather than just the log-in via HTTPS; the padlock icon in the meeting bandwidth indicator (green light in upper right corner) that indicates RTMPS did not appear in the Meeting upon making the change and will not until 15 minutes after the meeting room is closed and then reopened. The variable is called <HOST_LEFT_TIMEOUT> and it also sets the number of minutes participants can stay in a Meeting room after the last host leaves the room. After 15 minutes, participants will be  disconnected from the room.

The second timeout variable is called <SESSION_TIMEOUT> It is very important if you use a Connect meeting room for any support activities and keep it open for longer than 12 hours. The workaround is to set up two rooms and rotate every eleven hour between two rooms to support any sustained activity that will last more than 12 hours.

For on-premise customers these variables are adjustable, though the default settings are highly recommended. These settings can be manipulated in the in application.xml file in \ConnectRoot\comserv\win32\conf\originhost\_defaultVHost_\:



Note that changing these setting is not recommended unless there is a pressing need. And with that said, never increase the <SESSION_TIMEOUT> beyond 12 hours, though you may lower it if needed.

Note also the Administration option in Connect Central:


XML API Tips: Modification of Help / Support Links

In Adobe Connect (both On Prem and Hosted accounts), there are methods to modify existing support and help links using the XML API.  This was implemented to provide the capability to replace the in product support / help links and details with partner or organization-specific links / contact information.

Use Case

Say a partner or organization wants to be able to replace the help / support links embedded in the Connect meeting client or Connect web app with links to their own version of the help documentation / support information or support portal. They need to provide a combined cohesive help / support channel to their customers or their users.

The following undocumented APIs are provided to modify the support or help link customization on a per-account basis. Here is how it works:

Link 1 – Contact Support (In Meeting)

First, the ‘Contact Support’ link in the Meeting interface itself (as seen below):

To modify this, use the XML API call: account-support-link-update to enable or disable the account feature and modify the support link.

The default support link is:

XML API Call Info:
account-id = the account-id of the account you are modifying the links for
enable = true or false – enables (true) or disables (false) this feature
support-link = link to partner or customer support site (must be http link)
- if enable is true, must provide support-link
- if enable is false, remove support-link for the account

To enable a custom link:



<status code=”ok”/>


To verify it is now active (aside from testing in a new meeting session), you can run the ‘feature-info’ API call which will return that feature as part of account information if the feature is enabled on the account.



<status code=”ok”/>
….snip snip….
<feature account-id=”XXXXXXXX” feature-id=”fid-non-partner-support-link“>
….snip snip….

Note: it’s deceiving, but it WILL be listed in the ‘disabled-features’ XML node if it is ENABLED.  If it is NOT enabled, it will NOT show up in the results of this call.

To disable (or set back to the original default setting):



<status code=”ok”/>

Note: For meetings that are still active and have not unloaded from memory yet, the links will not change until it fully shuts down.  For new meeting sessions, the link will immediately be updated/reflected to show the intended webpage.

Link 2 – Help Link (Login Page)

Second, the ‘Help’ link on the login page (as seen below):


The default value will take you to:

XML API Call Info:
account-id = the account-id of the account you are modifying the links for
field-id = the field-id of the help link you are trying to modify. Values are:
- account-login-help-link
- account-webapp-help-link
value = link to partner or customer support site (The help link must start with either ‘http://’ or ‘https://’.  No javascript urls are allowed as values.)


To enable a custom link (use the ‘account-login-help-link’ field-id above):



<status code=”ok”/>

Link 3 – Help Link (Connect Central Page)

Third, the ‘Help’ link on the top of the Connect Central page (as seen below):


The default value will be:

XML API Call Info:
account-id = the account-id of the account you are modifying the links for
field-id = the field-id of the help link you are trying to modify. Values are:
- account-login-help-link
- account-webapp-help-link
value = link to partner or customer support site (The help link must start with either ‘http://’ or ‘https://’.  No javascript urls are allowed as values.)


To enable a custom link (use the ‘account-webapp-help-link’ field-id above):



<status code=”ok”/>

To REMOVE any of these link customizations, simply leave the VALUE param empty:



<status code=”ok”/>




<status code=”ok”/>

To view any custom help links set on the account:

XML API Call Info:


If NO help links have been customized, you will see only an ‘ok’ result returned.

Results if no help links:

<status code=”ok”/>

 Results if help links are customized:

<status code=”ok”/>

Using the FMS API for On-Prem Adobe Connect

For monitoring purposes, you can build an application which utilizes additional API calls that hook directly into the Flash Media Administration Server services.  This is undocumented but may help you with additional monitoring or statistics on the FMS side.

A full list of FMS/FCS API entries for the 9.1 version of FMS (which is version 4) can be found here:

Previously, as an Adobe Connect administrator, you probably have always had the additional FMS service (Flash Media Administration Server) shut off.  In order to utilize the API, you need to make sure this service is running:


In order to hit the API for FMS, you need to use the FMS admin username and password.

This can be found in:

[install drive]:\Connect\9.1.1\comserv\conf

# An administrator for the server. Users.xml
# Password for this vhost administrator. Users.xml

In order to use all the calls (or a select few, depending on your desire), you need to modify one additional FMS file (see below).

Continue reading…