Posts in Category "Seminars"

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 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:


Connect Meetings Opened from within the Chrome Browser Remain in the Browser

Issue: Connect Meetings opened from the Chrome browser remain in the browser instead of invoking the Connect Meeting Add-in:


This issue is often caused by privacy settings within Chrome; to fix this issue, follow these steps:


Open Chrome Settings, scroll to the bottom and choose Show Advanced Settings…


Scroll to Privacy, and click on Content Settings…


Scroll to Unsandboxed plug-in access (and enjoy a chuckle at the recently coined adjective with its dubious etymology) and click on Manage exceptions…


Add the appropriate Connect Meeting domain name to the allowed list. In this case I have just added [*.] to make the Connect Meeting add-in work on all Adobe Connect Hosted accounts:


Now when I launch the same meeting we started with in Chrome, it invokes the Connect Meeting Add-in:


Meeting Room Access Improvements in Connect 9.1

Issue: In Adobe Connect 9.1, we’ve made a number of changes to the way you enter an Adobe Connect Meeting room. This article will explain what changed with reference to meeting room accessibility in Connect 9.1 over against 9.0 and how the 9.1 changes are an improvement.

We solved two key entry issues:

1. The first issue addressed was the ambiguous message received by a participant who clicks a meeting room URL before the host opens a meeting room.  The ambiguous default message in Connect 9.0 reads, The Host has ended this meeting. Thank you for attending. This can be confusing as it refers to a previous meeting rather than the one about to start. Many confused participants, upon seeing that message, thought they missed the meeting; certainly, for someone new to Connect, this stark message often left the eager, early, overachieving (probably a bit anal-retentive) participant in the confused position of hitting a wall with no apparent gate through which to enter the upcoming meeting.


We fixed this ambiguity in Connect 9.1; now when a participant clicks the meeting room URL before the host reopens the new message reads, The meeting has not yet started. You will be able to access the meeting once the host arrives. Please wait.


Note: This message is clearer; participants now know to wait until the meeting is opened by the host. You can overlook that it uses the noun access as though it were a verb.

2. The second issue addressed with reference to meeting room accessibility in Connect 9.1 is that of eliminating some confusion around closing the meeting. There are two common ways that hosts close meetings, the first is to simply close the browser or addin and the second is to use the meeting room menu option to end the meeting.


In Connect 9.1, both of these options (End Meeting… or close browser) place the concluded meeting into the same state based on which of the three options the host chose under the meeting properties when creating the meeting room; Connect offers three access settings for meetings:

  • Only registered users may enter the room (guest access is blocked)
  • Only registered users and accepted guests may enter the room
  • Anyone who has the URL for the meeting can enter the room

These option are found under the Edit Information tab; a quick way to get to the Edit Information tab from any open meeting is by clicking Manage Meeting Information under the Meeting menu item:


Note: The option Only registered users and accepted guests may enter the room, is the default choice.

If you choose to set either the first or second option listed, then in Connect 9.1 it does not matter how you close or end a meeting room. If the meeting room is closed, then the meeting users will need to request entry before joining.

If your meeting is set to the third option, Anyone who has the URL for the meeting can enter the room, then there is a change that may confuse those hosts who are used to Connect 9.0 and prior versions of Connect and Breeze. Participants will now be able to enter a meeting room whether the the host closed the browser or whether the host used the meeting menu option to end the meeting. The setting under the meeting properties adjudicates; a meeting room deliberately set up to be open, will now remain an open room: With Connect 9.1 participants will be able to enter rooms set up with open permissions. It is prudent to carefully consider when to choose the option, Anyone who has the URL for the meeting can enter the room. And if you do choose this option, it is prudent to consider what is left in the meeting room to see, whether old chat messages or something in the share pod keeping in mind that a participant cannot navigate within the room, but may only see what is on stage.

3. There is another way to block entry to a meeting.  Connect has a feature to block meeting access and make sure users request entry.

In the menu bar, select Meeting > Manage Access and Entry > Block Incoming Attendees:


To allow incoming attendees to request entry to the meeting, select the option, Incoming attendees can request entry:

Note that in the text box, you have the option to edit and save a message for incoming attendees.

Conclusion: While initially, the new meeting room access improvements in Connect 9.1 may cause confusion, the changes with reference to meeting room accessibility in Connect 9.1 over against 9.0, offer a more intuitive and consistent workflow. And while old habits dies hard, I think you will agree that the 9.1 changes are warranted to allow hosts to better manage Connect 9.1 meeting access.

Connect Meeting Bandwidth Utilization using Multiple Interactive Collaborating Video Feeds

Usage question: How many Video feeds can I have running in my meeting room at once?

Answer: Let’s consider a working example around the bandwidth utilization of six Video cameras in a single meeting room consisting of one host and five participants. This working example may be that a of an interactive management meeting or of a college classroom where multiple students interact in a small group session using their webcams. From an examination of this example, you will be able to calculate video camera utilization parameters for other meetings whether they be larger or smaller ones.

To help illustrate what I mean, see this picture from our Connect 9.1 Release Notes


Each of our six webcam-wielding clients is connected to the server and will receive five video streams from the server (N-1).

Lets calculate first the number of streams outbound: 6 x 5 = 30

Lets also consider the 6 publishing streams from each client to the Connect server for a total of 36  total streams to support the Connect Video pods.

Now lets calculate the amount of bandwidth used by each stream; here you have power to decide how much bandwidth is to be used by each stream as there are many variables that Adobe Connect puts in your control:

In your meeting room, as a host, click Meeting > Preferences:


Under Meeting > Preferences, there are two important options that you are going to adjust – Bandwidth and Video:




The size of the video streams commensurate with each webcam instance will depend on how you configure these settings.


Following our example, if you go with the settings that I have depicted in the screen captures above to support the 6 Video feeds in a single meeting: DSL Bandwith and Standard Video quality = 213 kbps per stream:

36 streams x 213 = 7668 kbps or 8 Mbps for the 6 separate cameras.

There are other variables to consider as well. Building on our example, let’s say you also want to use VoIP:


DSL VoIP = 22 kbs x 36 = 792 kbs or 1Mbps (rounded up) additional bandwidth needed.

There are other ways to optimize: the video streams are always larger when clients use the Flashplayer in a browser rather than using the Connect Meeting addin. The Connect addin uses the ON2 codec and is far more economical when it comes to bandwidth utilization. For each client running without the Connect addin it is prudent to plan for an additional 50% for each of their Video streams. To avoid this additional bandwidth consumption, send out a link with the Adobe Connect Addin prior to your meeting and encourage clients to install it. It is a small modified version of the Flashplayer:

Another variable to consider that when the Video instance sizes are smaller, Connect adjusts to a lower publishing resolution to save some bandwidth. Unless you are sure the clients have the addin, the final planning number for our 12 webcam meeting is:

300 kbps for each stream (assuming that the addin will not be ubiquitous) x 36 stream = 11 Mbps + 1 Mbps for VoIP = 12Mbps.

Presenting a PowerPoint or a PDF that is uploaded to the Meeting room does not add to the overhead. Chat, Notes and Whiteboards are also insignificant with reference to bandwidth impact.

To drill home the point and procedure, let’s try the same exercise with 12 concurrent interactive collaborating Video feeds:

  • Each of our 12 clients is connected to the server and will receive 11 video streams from the server (N-1).
  • Lets calculate first the number of streams outbound: 12 x 11 = 132
  • Lets also consider the 12 publishing streams from each client to the Connect server for a total of 144  total streams to support the Connect Video feeds.
  • Following this larger example, if you go with the settings that I depicted previously in the screen captures above  to support the 12 Video feeds in a single meeting: DSL Bandwith and Standard Video quality = 213 kbps per stream:
  • 144 streams x 213 = 30672 kbps or 31 Mbps (rounded up) for the 12 separate cameras.
  • DSL VoIP = 22 kbps x 144 = 3168 kbs or 3Mbps additional bandwidth needed.
  • 300 kbps for each stream (assuming that the addin will not be ubiquitous) x 144 stream = 43Mbps + 3 Mbps for VoIP = 46Mbps.

Hopefully these exercises help with your planning for large successful meetings. There are other variables to consider such as Screen-Sharing and we will touch on those in a subsequent blog article. Consider, for example that when you are pushing the limits of your network, audio is usually given QoS priority over video.

Note: These examples assume that each client has a separate connection with the server and the Connect Edge servers are not remote to consolidate streams; they are not geographically distributed; they are collocated with the origin servers as is commonly the case so that each of the 12 attendees are receiving 11 subscribed streams from the data center (N-1).

How many Meeting Room Participants May I Delegate to Breakout Rooms?

Issue: Hosts and Presenters must manage Breakout Rooms (BoRs).

Two-hundred participants can be distributed into up to twenty breakout rooms, but BoR use does not add to your meeting concurrency. Check your license: Seminar rooms have more capacity than meeting rooms. Most (named organizer) Meeting rooms allow up to 100 participants by license in a single meeting:

In CPS: Go to the Administration Tab – It will default to the Account Summary where you will see your Meeting capacity per Meeting room:



The account summary above shows that, for this account, a single Meeting will max out at 100 participants. Since the Connect BoR technical capacity is to handle 200/20, most meeting room BoR usage will work no matter how you subdivide. For larger Meetings and Seminars, however, you will need to plan and be sure to stick to the limits prescribed.


Event vs. Session Expected Number of Participants for Seminars

When you create a Seminar SESSION, depending on your Seminar License quota for the number of concurrent users, it will give you the Expected Number of Participants drop down (to select over or under 600 users).

The values are:

  • Large Seminar Session (> 600 participants)
  • Regular Seminar Session (Up to 600 Participants)

If your Seminar License allows for over 600 concurrent seats, you get this option when you create a Seminar Session for a Seminar Room that exists under that License. If the quota on the License is under 600 for a maximum concurrency, you do not see this option when creating a session and it defaults to a ‘Regular’ session.



However when creating an EVENT in the Event Management area and point it to a Seminar Room, you do not get presented with an option to select a Large Seminar Session (> 600 participants) or Regular Seminar Session (Up to 600 Participants).  It will just assume the maximum for the License.  So if you select a Room to point an Event to, which resides in a Seminar License folder, which has a quota of over 600, the default for the Event ‘Session’ will be ‘Large Seminar Session (> 600 participants)’ (although you won’t see this referenced in the information for the Event).



Seminar Room Information Access for Seminar Hosts

In Adobe Connect 9.1, there seems to a misconception sometimes among Seminar Hosts that a user in the Seminar Host group can view and modify any Seminar Room (and their recordings, etc.) on the system. This is actually not the case.  Here is a summary of the permissions and scenarios in which a user who is in ONLY the Seminar Hosts group can view and modify Seminar Room information and related content/recordings.

When the permission of a Seminar Room itself is changed to:

a) Only registered users may enter the room (guest access is blocked) 


b) Anyone who has the URL for the meeting can enter the room

Then we explicitly set “denied” or ”view-hidden” permission for All Users in the database for this Seminar. In that case, a Seminar Host or user performing the operation no longer has any more permissions (as he is also part of All Users) unless that user is explicitly part of the Participant list either as host or presenter OR has Administrator or Limited Administrator permissions.

What this means is that if you select any of the two above access levels for the Seminar Room when you create it (so NOT ‘Registered Users AND Accepted Guests’), then ONLY admins, limited admins, and users who have been added to the meeting as a Host or Presenter can actually edit that meeting (and change recording access levels, etc.).

The bottom line is the person who is modifying Seminar Room access should be either part of Seminar Participants or should have Administrator / Limited Administrator permissions.

So in a nutshell, these are the scenarios where Seminar Host Group members can change recording access for a seminar:

  • Creators of the Seminar Room (who are obviously the host) – no matter what the access level of the room is set to.  If they created it, they can edit/change things in that Seminar Room.
  • A Seminar Host Group member who has been added to a room (that they didn’t create) ‘s Participant List as a Host or Presenter of the room – no matter what the access level of the room is set to.
  • A Seminar Host Group member who doesn’t have any Host permissions for the room but if the room is set to ‘Only registered users and accepted guests may enter the room’.
  • A Seminar Host Group member who is also a Limited Administrator.
  • A Seminar Host Group member who is also an Administrator.

Here are the scenarios where a Seminar Host Group member can NOT edit a room or change recording access, etc.:

  • A Seminar Host Group member who is NOT also in Limited Admins Group or Admins Group and who is not a Participant (Host) in the room and the room is set to “Only registered users may enter the room (guest access is blocked) “
  • A Seminar Host Group member who is NOT also in Limited Admins Group or Admins Group and who is not a Participant (Host) in the room and the room is set to “Anyone who has the URL for the meeting can enter the room”

Providing Diagnostic Data to Expedite Solutions for Connect Meeting Issues

Issue: Anything that may happen during a meeting which has a pejorative effect on end-user experience.

Solution: In Connect 9.1 we have a great diagnostic option in the meeting room. You can immediately pull logs from any meeting to diagnose:

If you click Help>About Adobe Connect, while holding down the Ctrl key, the debug logs will appear int he meeting room and you will have the option to copy them to your clipboard.




Sending me these, along with the RTMP string  Help> About Adobe Connect, while holding down the Shift key – this will be most helpful from the client experiencing the extreme latency.


Now if you want to take it even one step further and provide a client-side view of the meeting:

The instructions for enabling client-side logging are here:

Providing all this data along with the date and time (including timezone) and Meeting URL of any issue, will greatly expedite analysis and solution.

Which remote clicker/mouse will work to advance slides in a Connect Meeting room?

Issue: When stand up training in front of a live audience is done in tandem with a remote audience in a Connect Meeting room, it is effective and fun to advance the slides in the Meeting room while dancing around your live audience instead of being tethered to a podium.

Problem: Some pointers will not advance slides in a Connect Meeting room!

Solution(s): Some advice from a celebrity panel of  Connect Presenters:

  • You must make certain the Meeting room is highlighted and in focus.
  • This cheap one is a favorite and works fine as long as the meeting is in focus. There is no need to have a mouse hover over the advance button or anything more than having the meeting room in focus
  • One of the Senior SEs suggested that once you click on the forward or backward arrows in the pod, (and then don’t click anywhere else!) the clicker should work.  He  always used the remote  McAlly Mouse.
  • Another team member suggests that the clickers only work when the PPT has focus. He will typically move the first slide ahead with the built-in track pad to move the cursor over the right arrow, then use the clicker for the rest of the deck
  • Another said that the Share pod needs to be “in focus” when using a clicker for presentations which have been uploaded.  When sharing the desktop it should work as you’d expect for a standard presentation.

My preferred option is the first. It is tiny and fits in my travel bag. It comes with a small zippered case and I keep the lithium battery out of it when not in use.