Archive for October, 2013

Passing a user into an Adobe Connect Meeting without the Login Page

Periodically customers want to be able to pass in Guest users into an Adobe Connect Meeting without having those users actually have to pass in a guest name in the Meeting login page.  The scenario here may be that organizations may have an external registration system where users put in their email address, first name, last name, and other data, into a form on their registration portal and they do not want users to have to register (externally) for a Meeting and then put their name or login value in again a second time, on the Meeting login page.  Also, the organization may want to keep close tabs on how the guest name is entered, so it will match their own registration system, for reporting later.  For this, we have a quick and simple solution.

If the meeting is setup for public access (‘Anyone who has the URL for the meeting can enter the room‘) or for the default access level (‘Only registered users and accepted guests may enter the room), then you can simply append ‘?guestName=XXXXXXX‘ to the end of the meeting URL (where ‘XXXXXXX’ would be the value of their name that you want to display in the Attendee List Pod when they are in the meeting).  It would look something like this: https://{connectDomain}/{meetingURL}?guestName=Jim Johnson

The behavior will be:

For access level: ‘Only registered users and accepted guests may enter the room’: the user will be let right into the room’s lobby (without seeing the login page) and will see the message: ‘This is a private meeting. Your request to enter has been sent to the host. Please wait for a response.’  Then a host can accept them and they will be let into the meeting as whatever value was appended to the ‘?guestName=’ parameter.

For access level: ‘Anyone who has the URL for the meeting can enter the room’: the user will be let right into the room itself, as they normally would, but they never see the login page and their name value in the Attendee List Pod is whatever was passed in in the ‘?guestName=’ parameter.

 

From the integration perspective, the external registration system which mines the user data (name, email, etc.) you’d need to programmatically set this guestName value in the URL for each user.  This can be done in the application which presents the URL to the end users from the registration system and you can put the first name + last name, email address, or whatever other value you want to set in there.

 

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:

chrome-browser.fw

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…

chrome-adv-settings1.fw

Scroll to Privacy, and click on Content Settings…

chrome-adv-settings-content.fw

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

chrome-plug-in.fw

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

chrome-adv-settings-sites.fw

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

chrome-addin.fw

Recordings with Multiple Video Camera Feeds Pause during Playback

Issue : Recordings with multiple camera feeds pause intermittently during playback.

If you record an interactive Connect meeting consisting of thirty or more video feeds in the Connect Video pod using Connect 9.1, the recording playback will manifest short pauses throughout the recording.

The issue is mitigated by using fewer cameras in the meeting being recorded. It also helps to follow the best practice technique of pausing webcams in the meeting room for those users who are not speaking.

Engineering efforts to date have not yet fixed the problem and we have the issue on our hot-list for further engineering scrutiny and action – it is a high-priority issue. We are working hard at finding a solution to this problem and plan to release one as soon as physically possible.

Caveats: The source of audio in the recording is a separate FLV file (-xx_x_xx.flv). We have tried some workarounds such as using the Adobe Connect Web-services API to turn off the Smart-pause option that was first introduced in Connect 7.5 and updated in Connect 9.1 (&smartPause=false).

Workaround options: As aforementioned, the issue is mitigated by using fewer cameras in the meeting being recorded. It also helps to follow the best practice technique of pausing webcams in the meeting room for those users who are not speaking.

Adobe Partners,  New Toronto Group and Refined Data Systems has a product called Vantage Point that adds excellent management functionality over multiple Video feeds in any Connect meeting. The pictures below are not meant to be exhaustive by any means, but do serve to offer a snapshot of the functionality; the screen captures from a demonstration of Vantage Point show a meeting in which multiple video feeds are in view by the host (depicted on a second monitor in the screen captures for demonstration purposes), but not for the participants unless the host chooses to make a participant or participant’s video thread or threads viewable by all. This mitigates bandwidth utilization and makes the class more like an actual live class when using multiple video feeds. Just as all students are not on stage at once in a live classroom or auditorium, so with Vantage Point, the host or teacher or moderator is able to choose who is in the limelight even while viewing all students from the Vantage Point provided by this solution:

VP.fw

VP1.fw

VP2.fw

VP3.fw

Vantage Point also 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 or limiting the variables that produce the pauses in the recordings.

Is there a way to set a filter on the Event Catalog Page ?

Problem Description:-  User would like to know if there is a way to set a filter for end-users around the world who can access their organisation website and click on the public link which is associated with their site event catalog page.

For instance if they share their catalog page publically on a website : https://pub-server/content/connect/c1/7/en/events/catalog.html

All the end-users around the world who navigate to this link, can see the upcoming events. Therefore, client would like to know if there is a way to set a filter that they cannot see all the upcoming events and can only see which the host or the organization wants.

Solution :-

To achieve this use separate catalogs for different audiences. You can create folders in your Events area and put different events in each catalog. You can then make the folder public which will turn it into a separate catalog with a unique URL.

Event-Catalogs

 

 

 

Accurately editing Adobe Connect Recordings

More often than not people find it difficult to edit their recordings effectively, specially in cases where only one second needs to be cut out from the recording. It may take a lot of time to place the triangular cursors exactly at the position you want them to be.

Here is a small tip that will make your life a lot simpler:

1. Pause the recording from where you want to start your editing.
2. Double Click on the LEFT marker. It will take both the markers to that point on the recording timeline.
3. Play the recording and pause the recording again at the point till where you want to edit the recording.
4. Double Click on the RIGHT marker. It will take the right marker to the end point of your to-be-recording.
5. Cut and Save.

 

PS: Please note that this tip is for Adobe Connect 9.1 and may/may not work with other versions of Connect.

 

API Change in 9.1 for Report-Meeting-Attendance-Details

Stemming from a previous known issue which was corrected in 9.1, we have made a change to one specific API call for reporting meeting session information.

Previously in Adobe Connect 9.0.4, the two APIs “report-meeting-sessions” and “report-meeting-attendance-details” used completely different queries, and returned different results in many legitimate use cases.

The goal was to reconcile them by making sure that the “num_participants” value returned by the former matches the number of entries returned by the latter.

The change consisted of using the main query used by report-meeting-sessions as the inside/main query for report-meeting-attendance-details as well. Previously, this was not the case, and the two queries were completely different.

However, in the course of making this change, one change was required in the report-meeting-sessions query itself in order to ensure that the numbers are in alignment.

The changes are detailed below.

report-meeting-sessions: the query has been modified slightly to return unique transcript IDs; in the vast majority of cases, this will not make a difference – however, if the same user gets a different transcript ID (e.g., if there are multiple user instances) then these will be counted as two separate user instances.

report-meeting-attendance-details: the main query in use here is now identical to the one used for report-meeting-sessions. Consequently, the number of entries returned here will be identical to the “num-participants” returned by the report-meeting-sessions API above. In addition to the fields returned earlier, this API now also returns session_date_created and session_date_end indicating when the meeting session itself started and ended.

Note that, in either case, passing ‘&report-version=deprecated’ as a separate parameter with the URL will bypass these changes and retain the older form of both these queries, should you need the calls to work as they previously did in prior Adobe Connect versions.

Specifically, if you are looking for each individual ‘start’ and ‘end’ time of a user’s session with the ‘report-meeting-attendance-details‘ API call in Adobe Connect 9.1 you need to append the ‘&report-version=deprecated‘ to the end of the call.  Otherwise, you will get the start and end time of the meeting session itself and not the user  session start/end times.

Connect On-Premise Installer for 9.1.1 on the Adobe LWS – Version Questions

Issue: There was an earlier version of 9.1 that looks very similar to the current (9.1.1), but the earlier version is missing some important updates. This will be fixed with the release of Connect 9.1.2

Solution: The normal way to check the Connect version is to poll the version.txt file at any Connect account domain name. To see an example, check this Adobe Connect hosted account for one of our training partners:

http://reximedia.adobeconnect.com/version.txt

The output from this shows the versions of all components of the release: package=9.1.1.80.20130729.1194934… patch=CPS_9.1.1.55_9.1.1.59, patch=CPS_9.1.1.59_9.1hotfix.12

This normal means of checking the build will not work with the 9.1.1 released installer. See the output from its version.txt:

package=9.1.1.92.20130804.1194934….

The version.txt is missing the patch numbers.

Workaround technique to find the version:

Look in the downloaded zip installer for versionInfo.xml

  • The date should read: 2013/09/27:08:12:57
  • The build should read: 9.1.1.5.20130924.1215873

This is valid as of the writing of this tech-note. It is safe to say that if you see a later date and build number on a full installer download, then you are not going to see this problem and your version.txt will be correct.

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.

Untitled-3.fw

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.

Untitled-6.fw

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.

Untitled-4a.fw

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:

Untitled-1.fw

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:

Untitled-7.fw

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

Untitled-8.fw
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

six-cams.fw

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:

meeting-preferences.fw

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

meeting-preferences-room-bandwidth.fw

meeting-preferences-video.fw

 

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

webcam.fw

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:

VoIP.fw

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

Meeting Connection Test Page Fails at Step Two

Issue: Meeting test page fails at step 2; there are many possible causes for this:

1. If it is failing when you attempt to connect through a remote edge but does not fail when you connect directly to an origin, then the most likely culprit is name resolution. Audit your remote Edge name-resolution against these tutorials:

Adobe Connect Edge Server Deployment Options: part 1

Adobe Connect Edge Server Deployment Options: part 2

2. MS Patch MS12-006 (installed on client workstation) has been problematic:

MS Update MS12-006 (http://technet.microsoft.com/en-us/security/bulletin/ms12-006) causes step two of the meeting test page to fail; more details on the Patch regarding TLS/SSL can be found here:  http://support.microsoft.com/kb/2643584

3. Other network and client-side constraints and configuration issues can cause this test to fail. In order to troubleshoot, try the following tests and gather the data from them:

For on-premise customers who are experiencing a failure at step two, try hitting the test page on the Adobe hosted service:

https://my.adobeconnect.com/common/help/en/support/meeting_test.htm

Firefox and IE should look like this:

FFMT.fw

Chrome looks like this; notice the absence of an addin:

ChromeMT.fw

To drill deeper, click on the Send Results link:

FFMTSendResults.fw

And then click on the Details link

FFMTSendResultsDetails.fw

FFMTSendResultsDetailsPV.fw

Note: Currently, as of the writing of this blog entry, in Connect 9.1, there is a known bug that prevents the addin version from appearing in the the meeting test-link output. In the screen capture above, you only see the Flash-player version. This is scheduled, tentatively to be fixed in Connect 9.2.

You may copy and paste the output from the details link to assist the Adobe Customer Care team with diagnosing meeting connection issues. Do not use the Send Results link on the meeting connection test page, but manually copy and paste the results into an email.

On the meeting test page, if you find that you need the addin, (excluding Chrome) simply click on the Downloads link:

FFMTDownloads.fw

Note that the Flash-player download link is also available:

FFMTDownloadsAddinFP.fw

The meeting test link has some limitations, for example, it will not diagnose tunneling RTMP(S) over HTTP(S). To figure out if you are tunneling and thereby experiencing additional latency and connection drops caused by something on the network blocking RTMP, (usually a proxy or firewall), look in the upper left corner of a live meeting room and see if there is a “T” in the output when you click on the green connection indicator:

.tunneljpgOctagon

All of this information is vital when trying to diagnose meeting connection issues.

Look for an upcoming blog article on diagnosing and traversing sources of network blockages of RTMP(S) resulting in tunneling RTMP(S) over HTTP(S) and causing increased latency in a meeting. You should have a lightening fast connection and it is very doable with the right configuration:

no-tunnel-star.fw