Posts in Category "Administration"

Public MP4 is redirecting to login page on Android and iOS devices

Currently as of Adobe Connect (hosted) 9.1.2, there is an issue with accessing public MP4 recordings on Android and iOS devices.  By design, the public content should not present a login screen to the user.  However, users are getting the login page on those devices when they try to access these public MP4 recordings.  The fix for this has been identified and it is slated to be rolled out in the 9.2 upgrade of the Adobe Connect hosted system.  Until then, the following workaround below should be followed.

The ‘workability’ of it depends on how you provide your users with the link to the MP4s.  iOS users in particular, are most likely not getting these links from the web app (Connect Central) but are instead getting them from an email or other portal that is provided to them.  If that is the case (for either iOS or Android), then you would just need to update the URLs (as indicated below) until we release 9.2 and provide a resolution.  Here is the workaround:

  1. Locate the MP4 in the Content Library.
  2. Click to view the ‘Edit Information’ page for the recording.
  3. Click the ‘Download Content’ link.
  4. Under ‘Download output file(s)’ there is a link to download the file. Copy this URL
  5. Paste the URL to a notepad or document.
  6. You will have a URL that looks something like this example: https://myCompany.adobeconnect.com/localmp4/output/Local-z1.mp4?download=Local-z1.mp4
  7. Remove everything after the ‘?’ and your URL will be something like this example: https://myCompany.adobeconnect.com/localmp4/output/Local-z1.mp4
  8. You can provide the modified URL to your users, and the recording will stream without stopping them to ask for permissions, though it will honor any permissions settings you have on content that is not public.

 Again, this issue is resolved in the upcoming 9.2 Adobe Connect release.

Using the XML API with Enhanced Security

With the release of Adobe Connect 9.0.4 and beyond (view KB here), we have introduced the Enhanced Security feature (documentation) and it is ON by default on our hosted system.  If you are an Adobe Connect Hosted customer, you can toggle the Enhanced Security feature on or off (if you are an Administrator) by logging into your Adobe Connect Hosted account and navigating to: Administration > More Settings.  You will see the following Security Settings:

es

 

If you have ‘Enable Enhanced Security’ checked (and you save the settings), your account will now issue TWO session cookies to a user when they authenticate.  This is crucial to understand and plan for if you are using the XML API to integrate with another system.  Also, if you are a partner or developer who has built an application that integrates with Adobe Connect, you will need to rework your application to account for the possibility of this feature being ON or OFF.

From my experience, it is best to simply code the application to look for the second session cookie all the time (after initially authenticating the user) rather than try to check for the feature being on or off.

Typically in Adobe Connect Hosted accounts before this feature was implemented (and with this setting OFF), your application would first make a ‘common-info’ call as below, to obtain a session cookie before logging a user in:

https://myaccountURL/api/xml?action=common-info

<results>
<status code=”ok”/>
<common locale=”en” time-zone-id=”35″ time-zone-java-id=”US/Eastern”>
<cookie>naXbreezecookie123456789</cookie>
<date>2013-12-02T19:50:38.983-05:00</date>
<host>https://myaccountURL</host>
<local-host>connecthost01</local-host>
<admin-host>naXcps.adobeconnect.com</admin-host>
<url>/api/xml?action=common-info</url>
<version>9.1.2</version>
<tos-version>7.5</tos-version>
<product-notification>true</product-notification>
<account account-id=”12345678″/>
<user user-id=”45678901″ type=”user”>
<name>Jim Johnson</name>
<login>Jim</login>
</user>
<user-agent>
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
</user-agent>
<mobile-app-package>air.com.adobe.connectpro</mobile-app-package>
</common>
<reg-user>
<is-reg-user>false</is-reg-user>
</reg-user>
</results>

Then you would log the user in:

https://myaccountURL/api/xml?action=login&login=Jim&password=XXXXXXX&session=naXbreezecookie123456789

<results>
<status code=”ok”/>
</results>

That would normally be it.

Then, all subsequent calls, you would normally just append that same session cookie as the ‘session’ parameter and you’d be all set.  However, with Enhanced Security ON, that session cookie you obtained from the first common-info call will NOT work in calls after the login call authenticates the user.  Once the login API is called, you MUST call common-info one more time immediately after the OK response comes back from the login call.  When you run common-info again, you will notice you will get a DIFFERENT session cookie value.  That second cookie value is the session you need to include in your subsequent calls going forward.  If you do not use that second value in your API call, and instead include the value from the first common-info call result, you will get the following error response:

<results>
<status code=”no-access” subcode=”no-login“/>
</results>

So in summary:

Before Enhanced Security the workflow was:

1) common-info API to get cookie session value
2) login API using the cookie session value
3) continue on making API calls with that same session cookie throughout the user session

After Enhanced Security (post 9.0.4):

1) common-info API to get cookie session value
2) login API using the cookie session value
3) common-info API again a second time to get the final cookie session value to use going forward in all other calls
4) continue on making API calls with that NEW session cookie throughout the user session

Again, it is best to code your application to always look for a session cookie again AFTER logging a user in.  That way, even if you are still using the same session (say if the account had Enhanced Security set to OFF), your application will still work fine and in the cases where the account does have Enhanced Security turned ON, it will still continue to work as expected.

Adobe Connect Server Licensing for Disaster Recovery

This question is commonly asked: Does my license for On-Premise Adobe Connect allow me install Adobe Connect servers for disaster recovery purposes?

First let’s define the terms: Disaster Recovery Environment refers to your technical environment designed solely to allow you to respond to an interruption in service due to an event beyond your control that creates an inability on your part to provide critical business functions for a material period of time. That is to say, it refers to a secondary site that would not be utilized in production unless the primary site went offline due to a natural or human-inflicted disaster that is beyond your control. Use of Adobe Connect servers in Disaster Recovery Environments is within the scope of your license and no additional fees are due to Adobe Systems Incorporated. For example, for the architecture depicted here, you would need four Adobe Connect server licenses. 

 

Connect_DR_cluster

 

However, adding one or more Adobe Connect servers to a local cluster is outside the scope of your license, and you will need to purchase additional licenses from Adobe Systems Incorporated to accomplish this.  Additional licenses are needed when adding any Adobe Connect servers that increase scalability in the form of:

  • Availability — What percentage of time is Connect available to geographically distributed users?
  • Reliability — How often does Connect experience problems that affect availability?
  • Performance — How fast does Connect consistently and qualitatively respond to user requests?
  • Concurrency – How many users can a Connect deployment handle concurrently?

Information around cluster expansion is here: Adobe® Connect™ server pools/clusters and hardware-based load-balancing devices with SSL acceleration

If you were to geographically distribute an active Connect cluster by placing Adobe Connect servers into two separate data centers, that would also require additional licensing. Connect servers in a cluster cannot have more than 2-3ms of latency between and among Connect servers.  Generally you would not geographically distribute Adobe Connect servers into different data centers, however, there is a chapter in the aforementioned clustering article on the topic. With that said, the architecture depicted below, is an example of a distributed active Adobe Connect cluster that is is spread between two local data-centers with nominal latency between those data-centers (less than 3ms of latency). All four servers are in production and all are actively hosting meetings and serving on-demand content.  This Connect architecture example depicted in the diagram below requires a four-server Connect cluster license:

 

Cross-DC-CLUSTER

 

Adding the Passcode Feature for Connect Meetings

You may add a passcode feature as an additional security option for Connect Meeting room access in Connect versions 8 and 9. Each Meeting room can have its own passcode.  The parameter will appear under the Edit Information tab of the Connect Meeting:

pc2.fw

This is a great option. For example, it allows you to pop up a fast ad hoc meeting with full guest access while requiring guests to apply a pass-code to enter:

pc.fw

It also allows an additional layer of security for registered users as well; they also would need to enter a passcode in addition to any permissions (even host-level) granted to the room.

pc1.fw

Once applied, when a users hits the Meeting URL they will be presented with the passcode field:

pc3.fw

To add this feature, simple log onto your on-premise adobe Connect server as a Connect Administrator and enter the following into the URL line in Connect Central:

http://YOURDOMAINNAME/api/xml?action=meeting-feature-update&account-id=7&feature-id=fid-meeting-passcode-notallowed&enable=false

Where “YOURDOMAINNAME” is actually your domain name.

If this executes correctly, you will see the following output when you follow-up by entering this command into the same URL line in Connect Central:

http://YOURDOMAINNAME/api/xml?action=meeting-feature-info&account-id=7

Output: feature-id=fid-meeting-passcode-notallowed

Alternatively you could simply check and see if the feature is available under the Edit Information tab of any Meeting.

Note: Your Meeting passcode can be up to 16 letters or numbers; keep in mind that it is a convenient supplementary security mechanism rather than a primary means. You will see this warning if your passcode is not supported go over that: Your passcode must be between 1 and 16 characters long (letters or numbers, no spaces).

In adding this feature you have invoked the Web Services API in Connect. If you are not familiar with the API see the following document; it is rich with options: http://help.adobe.com/en_US/connect/9.0/webservices/connect_9_webservices.pdf

Note also that with Connect 9.2, in Connect Central under Administration > Users and Groups > Edit Login and Password Policies, there are two relevant check boxes, one to enable and the other one to force the use of the passcode:

passcode.fw

Setting Email Sender for all messages to a generic address

This is a way to workaround a mail server blocking emails where the sender and mail server domain do not match.

Before you do this, make sure you have a working backup copy of your database!
First step: make sure the admin email address is set to the generic address you want to use.

You can do this on the database by running this SQL update query:
update PPS_CONFIG set VALUE = ‘genericaddress@mailserverdomain.com’ where NAME=’config-system-email’;

Next switch on the feature to send emails from this address:
insert into PPS_ACCOUNT_FEATURES (ACCOUNT_ID, FEATURE_ID, DATE_BEGIN, DATE_END, RECORDCREATED)
values (7, 84, GETUTCDATE(), ’3000-01-01 00:00:00.000′, GETUTCDATE());

After setting this, emails should be sent in the format:

“genericaddress@mailserverdomain.com on behalf of user@othermailserver.com”

Stunnel Support with Adobe Connect 9.x

Up until Adobe Connect 9.0.0.1 (full installer) for on-premise (licensed) deployments, Adobe packaged Stunnel with the Connect application to handle the software SSL.  With the release of 9.0.0.1 of Adobe Connect, we included Stunnel 4.53 but do not unpack and install it with the installer (as we previously had done with Connect 8.x).  If you install (or are running) 9.0.0.1 and are looking for the Stunnel package, you need to navigate into the unpacked Adobe Connect 9.0.0.1 installer folder ({unpacked folder}\Adobe Connect 9.0.0.1\Adobe Connect\Merge_Modules) and look for the stunnel-4.53.zip file.  From there, you can install Stunnel 4.53 for your SSL deployment.

With the release of Adobe Connect 9.1.1, we no longer even ship the Connect installer with the Stunnel bits.  So you will need to obtain the Stunnel installer from either Stunnel’s website or from a 9.0.0.1 installer of Adobe Connect.  The last shipped version of Stunnel (with Connect 9.0.0.1) was 4.53, but again it was not ‘unpacked and installed’ as of 9.0.0.1.

The latest build of Stunnel that Adobe QE has tested with is version 4.56, which at the time of this article, is the latest production Stunnel build.

 

 

 

The Mystery of Burst Packs for Meetings

Issue: Adobe Connect hosted customers sometimes ask how to predict the burst pack size needed for insurance that their large meetings with unexpected attendance will be handled.

Solution: Burst Packs will extend the capacity of the Named Host license by up to five times the ceiling. This means that a room with a ceiling of 100 is best covered by a burst pack of up to 500 attendees, or 400 above the standard capacity of 100.  The burst pack minutes will be depleted, for each minute each user exceeds the capacity of 100.  For example, if 110 people join your meeting at the same time, and all 110 stay for 10 minutes, this will require 100 burst pack minutes to accommodate the 10 additional attendees in overage multiplied by 10 minutes.

If during a meeting, you accidentally go over the number of attendees accommodated by your burst pack, then the burst pack  balance will appear as a negative number.  If the meeting is very well attended and the burst pack exceeds 1000, it will be disabled for future meetings so no more overage will be accrued.   For the initial meeting overage, it will go over 1000 (one-time) if a current meeting is on-going, and won’t shut down until that meeting ends. Adobe does not penalize you for your successful use of Connect, but the hard limit for overage is set to 1000.

The meeting will not kick people out because of an overage;  burst pack minutes will continue to accumulate, even if the burst pack is depleted in order to ensure the meeting is not disrupted.  Adobe will then take those overage minutes out of their next burst pack purchase.

Ask your sale representative about burst packs and how to add them to insure successful large meeting in Connect.

Event Module Tutorial Collection

The below is a great collection of Event Module tutorials by both Adobe and our some of our partners.  These cover everything from administration, creation, migration, reporting, best practices, and API integration.

 

Creating an Event in Adobe Connect 9
by video2brain
In this tutorial, you’ll see how to create a new event in Adobe Connect 9 and add it to the Event Catalog

Creating and Editing Event Templates
by Alistair Lee
In this video tutorial, Alistair Lee shows you how to create, edit and manage event templates – new to Adobe Connect 9.

Event Administration in Adobe Connect 9
by Alistair Lee
In this video tutorial, Alistair Lee walks through the new features available to Event Administrators in Adobe Connect 9

Adobe Connect 9: Event Migration Guide
by Alistair Lee, Adobe Systems
This tutorial features a 23-page PDF guide on Adobe Connect 9 events. It highlights the new features introduced in version 9 of Adobe Connect and discusses the impact on events that have migrated.

Creating a Two Person Event Template with Adobe Connect
by Alistair Lee, Adobe Systems
In this tutorial, you’ll see how to quickly create a new event template that features two or more speakers.

Adobe Connect Events Overview
by Alistair Lee, Adobe Systems
In this video, Alistair Lee walks through an overview of the new Adobe Connect Events module.

Adobe Connect best practices for large events and seminars
by Rocky Mitarai, Adobe Systems
This checklist is an invaluable resource for any producers of large webinars and events on Adobe Connect.

Resetting the Default Event Templates in Adobe Connect
by Alistair Lee, Adobe Systems
This tutorial walks through the steps required to reset a default template.

Campaign Tracking in Adobe Connect 9.1
by Alistair Lee, Adobe Systems
In this video tutorial, Alistair walks through some of the new features in Adobe Connect 9.1 that make measuring campaigns and optimizing your promotional channels more intuitive.

Event Registration using Adobe Connect API’s
by Dustin Tauer, Easel Solutions
In this tutorial, Dustin covers how to use the Adobe Connect API’s to register a user for an event.

 

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:
{InstallDir}\9.1.1\comserv\win32\conf\originhost\_defaultVHost_\Application.xml

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:

bw-room

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: 

<BW_C2S_MODEM>200</BW_C2S_MODEM>
<BW_C2S_DSL>600</BW_C2S_DSL>
<BW_C2S_LAN>100000</BW_C2S_LAN>
<BW_S2C_MODEM>200</BW_S2C_MODEM>
<BW_S2C_DSL>800</BW_S2C_DSL>
<BW_S2C_LAN>100000</BW_S2C_LAN>

Camera Settings:

bw-video

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

LAN

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

DSL/Cable

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

Modem

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 –>
<CAMERA_LAN_LOW_QUALITY>70</CAMERA_LAN_LOW_QUALITY>
<CAMERA_LAN_LOW_FPS>8</CAMERA_LAN_LOW_FPS>
<CAMERA_LAN_LOW_MAX_RESOLUTION>320×240</CAMERA_LAN_LOW_MAX_RESOLUTION> <CAMERA_LAN_LOW_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_LAN_LOW_MAX_WIDESCREEN_RESOLUTION>
<CAMERA_LAN_MEDIUM_QUALITY>75</CAMERA_LAN_MEDIUM_QUALITY>
<CAMERA_LAN_MEDIUM_FPS>10</CAMERA_LAN_MEDIUM_FPS>
<CAMERA_LAN_MEDIUM_MAX_RESOLUTION>320×240</CAMERA_LAN_MEDIUM_MAX_RESOLUTION> <CAMERA_LAN_MEDIUM_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_LAN_MEDIUM_MAX_WIDESCREEN_RESOLUTION> <CAMERA_LAN_STANDARD_QUALITY>80</CAMERA_LAN_STANDARD_QUALITY>
<CAMERA_LAN_STANDARD_FPS>15</CAMERA_LAN_STANDARD_FPS>
<CAMERA_LAN_STANDARD_MAX_RESOLUTION>640×480</CAMERA_LAN_STANDARD_MAX_RESOLUTION> <CAMERA_LAN_STANDARD_MAX_WIDESCREEN_RESOLUTION>854×480</CAMERA_LAN_STANDARD_MAX_WIDESCREEN_RESOLUTION> <CAMERA_LAN_HIGH_QUALITY>90</CAMERA_LAN_HIGH_QUALITY>
<CAMERA_LAN_HIGH_FPS>20</CAMERA_LAN_HIGH_FPS>
<CAMERA_LAN_HIGH_MAX_RESOLUTION>640×480</CAMERA_LAN_HIGH_MAX_RESOLUTION> <CAMERA_LAN_HIGH_MAX_WIDESCREEN_RESOLUTION>854×480</CAMERA_LAN_HIGH_MAX_WIDESCREEN_RESOLUTION>
- <!– DSL –>
<CAMERA_DSL_LOW_QUALITY>70</CAMERA_DSL_LOW_QUALITY>
<CAMERA_DSL_LOW_FPS>4</CAMERA_DSL_LOW_FPS>
<CAMERA_DSL_LOW_MAX_RESOLUTION>320×240</CAMERA_DSL_LOW_MAX_RESOLUTION> <CAMERA_DSL_LOW_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_DSL_LOW_MAX_WIDESCREEN_RESOLUTION>
<CAMERA_DSL_MEDIUM_QUALITY>75</CAMERA_DSL_MEDIUM_QUALITY>
<CAMERA_DSL_MEDIUM_FPS>8</CAMERA_DSL_MEDIUM_FPS>
<CAMERA_DSL_MEDIUM_MAX_RESOLUTION>320×240</CAMERA_DSL_MEDIUM_MAX_RESOLUTION> <CAMERA_DSL_MEDIUM_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_DSL_MEDIUM_MAX_WIDESCREEN_RESOLUTION> <CAMERA_DSL_STANDARD_QUALITY>80</CAMERA_DSL_STANDARD_QUALITY>
<CAMERA_DSL_STANDARD_FPS>10</CAMERA_DSL_STANDARD_FPS>
<CAMERA_DSL_STANDARD_MAX_RESOLUTION>320×240</CAMERA_DSL_STANDARD_MAX_RESOLUTION>
<CAMERA_DSL_STANDARD_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_DSL_STANDARD_MAX_WIDESCREEN_RESOLUTION> <CAMERA_DSL_HIGH_QUALITY>85</CAMERA_DSL_HIGH_QUALITY>
<CAMERA_DSL_HIGH_FPS>15</CAMERA_DSL_HIGH_FPS>
<CAMERA_DSL_HIGH_MAX_RESOLUTION>640×480</CAMERA_DSL_HIGH_MAX_RESOLUTION>
<CAMERA_DSL_HIGH_MAX_WIDESCREEN_RESOLUTION>854×480</CAMERA_DSL_HIGH_MAX_WIDESCREEN_RESOLUTION>
- <!– MODEM –>
<CAMERA_MODEM_LOW_QUALITY>70</CAMERA_MODEM_LOW_QUALITY>
<CAMERA_MODEM_LOW_FPS>4</CAMERA_MODEM_LOW_FPS>
<CAMERA_MODEM_LOW_MAX_RESOLUTION>160×120</CAMERA_MODEM_LOW_MAX_RESOLUTION>
<CAMERA_MODEM_LOW_MAX_WIDESCREEN_RESOLUTION>214×120</CAMERA_MODEM_LOW_MAX_WIDESCREEN_RESOLUTION> <CAMERA_MODEM_MEDIUM_QUALITY>70</CAMERA_MODEM_MEDIUM_QUALITY>
<CAMERA_MODEM_MEDIUM_FPS>8</CAMERA_MODEM_MEDIUM_FPS>
<CAMERA_MODEM_MEDIUM_MAX_RESOLUTION>320×240</CAMERA_MODEM_MEDIUM_MAX_RESOLUTION>
<CAMERA_MODEM_MEDIUM_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_MODEM_MEDIUM_MAX_WIDESCREEN_RESOLUTION> <CAMERA_MODEM_STANDARD_QUALITY>75</CAMERA_MODEM_STANDARD_QUALITY>
<CAMERA_MODEM_STANDARD_FPS>10</CAMERA_MODEM_STANDARD_FPS>
<CAMERA_MODEM_STANDARD_MAX_RESOLUTION>320×240</CAMERA_MODEM_STANDARD_MAX_RESOLUTION>
<CAMERA_MODEM_STANDARD_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_MODEM_STANDARD_MAX_WIDESCREEN_RESOLUTION> <CAMERA_MODEM_HIGH_QUALITY>80</CAMERA_MODEM_HIGH_QUALITY>
<CAMERA_MODEM_HIGH_FPS>15</CAMERA_MODEM_HIGH_FPS>
<CAMERA_MODEM_HIGH_MAX_RESOLUTION>320×240</CAMERA_MODEM_HIGH_MAX_RESOLUTION>
<CAMERA_MODEM_HIGH_MAX_WIDESCREEN_RESOLUTION>427×240</CAMERA_MODEM_HIGH_MAX_WIDESCREEN_RESOLUTION>

 

Screen Share Settings:

bw-ss

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

Notes: 
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–>
<SS_ON2_BW_LIMIT_LOW>500</SS_ON2_BW_LIMIT_LOW>
<SS_ON2_BW_LIMIT_MEDIUM>800</SS_ON2_BW_LIMIT_MEDIUM>
<SS_ON2_BW_LIMIT_STANDARD>1200</SS_ON2_BW_LIMIT_STANDARD>
<SS_ON2_BW_LIMIT_HIGH>2000</SS_ON2_BW_LIMIT_HIGH>
- <!–  QUALITY –>
<SS_ON2_QUALITY_LOW>65</SS_ON2_QUALITY_LOW>
<SS_ON2_QUALITY_MEDIUM>80</SS_ON2_QUALITY_MEDIUM>
<SS_ON2_QUALITY_STANDARD>90</SS_ON2_QUALITY_STANDARD>
<SS_ON2_QUALITY_HIGH>100</SS_ON2_QUALITY_HIGH>
- <!–  FPS –>
<SS_ON2_FPS_LOW>2</SS_ON2_FPS_LOW>
<SS_ON2_FPS_MEDIUM>4</SS_ON2_FPS_MEDIUM>
<SS_ON2_FPS_STANDARD>6</SS_ON2_FPS_STANDARD>
<SS_ON2_FPS_HIGH>8</SS_ON2_FPS_HIGH>
- <!– WORST QUALITY –>
<SS_ON2_WQ_LOW>1</SS_ON2_WQ_LOW>
<SS_ON2_WQ_MEDIUM>30</SS_ON2_WQ_MEDIUM>
<SS_ON2_WQ_STANDARD>70</SS_ON2_WQ_STANDARD>
<SS_ON2_WQ_HIGH>90</SS_ON2_WQ_HIGH>
- <!– MINIMUM WORST QUALITY –>
<SS_ON2_MINWQ_LOW>1</SS_ON2_MINWQ_LOW>
<SS_ON2_MINWQ_MEDIUM>15</SS_ON2_MINWQ_MEDIUM>
<SS_ON2_MINWQ_STANDARD>30</SS_ON2_MINWQ_STANDARD>
<SS_ON2_MINWQ_HIGH>50</SS_ON2_MINWQ_HIGH>

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

<HOST_LEFT_TIMEOUT>15</HOST_LEFT_TIMEOUT>

<SESSION_TIMEOUT>12</SESSION_TIMEOUT>

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:

Untitled-1.fw