Archive for April, 2014

How to make Connect use a browser-based email client to send Meeting invitations

When invoking a browser-based email client to invite participants to a Connect Meeting from within a Connect Meeting you will see this error message unless you first make the browser-based email your default email service:




Sending a browser-based email invitation from within a Connect Meeting is possible if you first make the browser-based email option your default email program. As an example, you can use the instructions at the following links to make Gmail your default email program :

Note that once you enable a browser-based email client and invoke it from within a Connect Meeting, the behavior will be different based on whether the host issuing the invitation is using the Connect Meeting addin or the Flash Player. In the addin it will look like this:

Using the Connect Meeting addin, invoke the invitation: Meeting> Manage Access & Entry > Invite Participants



See how the invitation is fully populated with important details:


Following the same procedure using the Flash Player instead of the addin (?launcher=false) also works, but with an abbreviated invitation message:



Connect 9.1.x on-premise server – “Send Invitations” checked by default

When creating a new meeting you are asked if you want to send out meeting invitations by email.

In Connect 9.1.x the option to send invitations is selected by default.

If you do not wish to send out invitations for your meetings you have to select “Do not send invitations” every time you create a new meeting.


You can change this behavior to make  “Do not send invitations” the default when creating a new meeting.

To do so, edit the notify.xsl file which is located in \Connect\9.1.1\appserv\apps\meeting\  ( but please remember to take a backup copy of the file).

1. Open the notify.xsl in an xml-friendly editor such as notepad++

2. Find this section:

<table cellpadding=”0″ cellspacing=”0″>
<xsl:call-template name=”input”>
<xsl:with-param name=”title”   select=”‘send-invitations'”/>
<xsl:with-param name=”name”    select=”‘date-scheduled'”/>
<xsl:with-param name=”type”    select=”‘radio'”/>
<xsl:with-param name=”value”   select=”/results/common/date”/>
<xsl:with-param name=”checked” select=”true()”/>

<xsl:call-template name=”input”>
<xsl:with-param name=”title”   select=”‘no-invitations'”/>
<xsl:with-param name=”name”    select=”‘date-scheduled'”/>
<xsl:with-param name=”type”    select=”‘radio'”/>
<xsl:with-param name=”value”   select=”‘ignore'”/>
<xsl:with-param name=”checked” select=”false()”/>

3. Change “false” to “true” and “true” to “false” to swap the selection.

It should now look like this:

<table cellpadding=”0″ cellspacing=”0″>
<xsl:call-template name=”input”>
<xsl:with-param name=”title”   select=”‘send-invitations'”/>
<xsl:with-param name=”name”    select=”‘date-scheduled'”/>
<xsl:with-param name=”type”    select=”‘radio'”/>
<xsl:with-param name=”value”   select=”/results/common/date”/>
<xsl:with-param name=”checked” select=”false()”/>

<xsl:call-template name=”input”>
<xsl:with-param name=”title”   select=”‘no-invitations'”/>
<xsl:with-param name=”name”    select=”‘date-scheduled'”/>
<xsl:with-param name=”type”    select=”‘radio'”/>
<xsl:with-param name=”value”   select=”‘ignore'”/>
<xsl:with-param name=”checked” select=”true()”/>


4. Save the file and restart the services.

5. Check your changes by creating a new meeting. If you encounter any issues, restore the original file.



Specifications for Offline MP4 Conversion for Connect Recordings

Prior to Connect version 9.5, the specifications for MP4 conversion on Adobe Connect hosted multi-tenancy accounts were similar to our FLV specifications albeit with better compression:

  • Resolution: 1024X768
  • Frames Per Second: 8 FPS
  • Video Bitrate: 1024kbps
  • Audio:
    • Codec – AAC (Advanced Audio Codec)
    • Profile – Main@3.1
    • Bit Rate – ~55Kbps (VBR)
    • Channels – 1 (Mono)
    • Sampling rate – 44.1Khz

With the advent of Connect 9.5, those legacy hosted server-side MP4 conversion options are end of life and the new client side offline conversion options offer a broader range of quality control conversion and output options for all Connect users running 9.5 whether hosted, on-premise or managed ISP. To view the panoply of possible settings, login to Connect Central and select the “Make Offline” option under any Meeting recording as shown below:


The following dialog box will appear:


On clicking Next, offline recording download options appear offering MP4 or FLV,  Video quality presets on a sliding scale and also Advanced Options. With MP4 selected, see how the Video quality presets on a sliding scale affect Resolution, Quality, Profile, Bandwith and FPS:

The Mobile preset option uses:

  • Resolution-480p
  • Quality-70
  • Profile-Basline
  • Bandwith-400 kbps
  • FPS-15


The Desktop preset uses:

  • Resolution-600p
  • Quality-80
  • Profile-Basline
  • Bandwith-600 kbps
  • FPS-20


The HD preset uses:

  • Resolution-720p
  • Quality-90
  • Profile-Main
  • Bandwith-800 kbps
  • FPS-30


The Full HD preset uses:

  • Resolution-1080p
  • Quality-100
  • Profile-Main
  • Bandwith-1.4mbps
  • FPS-30


On clicking Advanced Options, you may override the Video quality preset options and customize the output settings:


The resolution options range from 480p to 1080p:


The quality settings drop-down ranges from 50 to 100:


The Profile settings are: Baseline, Main and High. The lower the profile setting, the easier it is for a platform to implement (simpler, smaller code-base that puts less demand on resources).  The higher the profile, the more difficult the implementation for the software developer, the more demand it puts on system resources such as battery life while in exchange, the file size is smaller for the same quality of content.

  • Baseline- All platforms and devices support baseline — but since the features are less sophisticated, the file sizes tend to be larger to obtain the same result.  Use this if you need the content to be universally accessible.
  • Main- Used for standard-definition digital TV broadcasts.
  • High- Modern mobile devices support high profile and the file sizes are typically smaller than baseline. High profile is sometimes referred to loosely as broadcast-quality. Desktops and newer mobile devices (all devices supported with iOS 8.4) support generic high profile although there are non-generic flavors in high profile, such as high422 and high444 that are not. Here the generic option is in play.


The Bandwidth range is: 400kbps to 1.8gbps. Video encoders target encoding settings dynamically so that, on average, the content is consumable at the specified bandwidth.  This means that when content takes advantage of the encoder’s features (such as when the image is still, or when the camera is doing a simple sweep of a still scene), more detail can be pushed. Alternatively, when there’s an action shot, the detail is typically reigned in.  There may be bursts of time in a video that exceed the specified bandwidth, but the encoder manages it in a way that anticipates that some buffering is taking place while ensuring that the video broadly fits within the specified bandwidth. The general categories of end users are:

  • Corporate intranet bandwidth
  • Broadband consumers
  • Wifi users
  • Mobile users on cellular networks

When specifying bandwidth, you typically would use a value that is less than the bandwidth available.   If a broadband users has a 10Mbps connection that does not mean that there is always 10Mbps available or that other applications aren’t also consuming resources. The ramifications of select uses of QoS is also a relevant variable.


FPS options range in increments of 10 up to 30:


Note: The FPS set in the offline settings dialog is the maximum that addin will try to achieve during the making of mp4. There are a lot of factors which affect the final FPS such as CPU usage and graphic card capability. The addin may not always achieve the desired FPS if there aren’t enough system resources available.

Enable Video Vs Enable Webcam for Participants

In Connect 9.2, there are two ways you can allow a ‘participant’ to turn their camera on – but each has slightly different results.

Enable Video – this option gives full rights to the video pod, same as a host. Or in other words, if you enable Video for any participant, that particular participant will get presenter rights over the Camera pod just like in case of Enhanced rights over any pod.




Enable Webcam For Participants – this doesn’t give overall video pod rights (the participants can’t Force Presenter View, or choose who is in the main Filmstrip, etc.), but it allows them to turn their camera on. However you cannot be selective with this option – everyone will be able to turn on their camera.


FYI, If you “enable video” for a participant and then “enable webcam for participants” you lose the ability to “disable video” for any already enabled participant until you first “Disable Webcam for participants”

Be Aware of the Closed Captioning Pod Defaults

Last week we found out that Caption Colorado changed their IP address and port number for the Closed Captioning pod downloadable from the Connect Exchange Website. Here is the direct link to the Connect version 9 Closed Captioning Pod

The new Caption Colorado information includes:

If you are experiencing any trouble with the Closed Captioning pod while using it in a Connect Meeting with Caption Colorado, please set your host to “” and to port 11100 in the adobe pod. Note that the new IP,, depending on your infrastructure’s network security settings, may need to be white-listed.

For an updated user’s guide referencing the Closed Caption Pod, see this PDF:



XML API Tips: Arkadin Profile Creation – Display Numbers

Previously I posted a blog entry on creating audio profiles via the XML API (  This is an add-on article describing one additional step for finalizing an Arkadin profile.

Once you complete the Arkadin profile, you may notice the Conference Numbers aren’t showing up at the bottom of the profile (in the UI).  When you build a profile in the UI (without the API) and you save the profile, it will display the Conference Number and Conference Number Toll Free in a datagrid below the credentials.  When you create a profile with the API, it will not (unless you go into the UI and then click Edit and then Save again).


Notice no Conference Numbers listed in the grid below the Profile Status.

Also, if you create the profile with the API (and you don’t go into the UI and click Edit/Save), you may notice that the conference numbers are not displayed in the Dial In dialogue box in the meeting room for participants.  It will only list the Moderator and Participant codes.


Notice, no numbers appearing to call into…

To get the numbers to show up in the Profile and in the dial-in dialogue box inside of the meeting room itself, you need to add one additional web service call to your workflow as below:

Once you build your telephony profile from the previous article,  you need to take the profile-id value and make the ‘telephony-profile-dial-in-number-update‘ API call to input the new numbers as such:


Where you add the profile-id
where you add all the ‘locations’ you want (the string for the conference number description)
where you add the applicable conference numbers for each (toll + toll free for instance)

After completing this step, if you view the profile in the UI again, you see the numbers appear:


Conference Numbers now listed in the grid below the Profile Status.



Notice now the number(s) appear.

Arkadin Audio Profile Conference Numbers

For Arkadin customers who integrate Arkadin audio profiles into Adobe Connect Meeting rooms, they need to be very careful in what numbers they are inputting into the profile fields when they are creating the telephony profiles.  Also, if these profiles are being provisioned automatically by an application utilizing the API, developers need to make sure the values they are passing in via the web services are also correct.

Arkadin has 3 phone numbers that are required when building an audio profile (UI pictured below).


  1. Toll Access Number‘ (in the API this is: ‘x-tel-arkadin-conference-number‘)
  2. Toll Free Access Number‘ (in the API this is ‘x-tel-arkadin-conference-number-free‘)
  3. SIP Access Number‘ (in the API this is ‘x-tel-arkadin-conference-number-uvline‘)

It is crucial that you do NOT inadvertently put the Toll number (a non ‘1-8xx’ number) in for the Toll Free value and vice versa.  If you put a toll number in for the toll free number, the audio profile will save correctly, HOWEVER the UV line (Universal Voice) will not be able to connect to your meeting room when you try to start the audio (for Audio Broadcast and for Meeting Recording with Arkadin).  Universal Voice can only call out to a toll FREE number.  So if you are seeing your Arkadin audio conference not connecting correctly in the Adobe Connect Meeting room, please make sure to check your Arkadin profile that is assigned to the meeting, to make sure the toll free number is actually a toll free number, and the toll number is also correct.  The SIP access number should be set to the toll FREE number as well.



Recently we have discovered that a newer setting for on-premise (licensed) Adobe Connect servers may lead to a memory leak on the system in certain rare circumstances.  Here is some history and recommendations in case you believe you may be running into a memory leak problem in your Adobe Connect licensed environment and you are running a version newer than 9.0.3.

The DB_PING_TIMEOUT value was introduced back in Connect 7 (2008 timeframe).  It enables invalidated DB connections to be recognized quickly. In the absence of a reasonable value for this timeout, we have had instances in the past where critical CPS threads (e.g. the scheduler sweeper thread) have waited on a stale DB connection for too long, causing fastfails. This value had since always been set to ‘0’ which means there is no time out.  Since the default host health check time out value is 40 seconds, it is recommended that the DB_PING_TIMEOUT default value be set to 30 seconds, so that it is under the limit that causes potential server fast-fails. This was a fairly minor change in the config.ini, where the DB_PING_TIMEOUT value was changed from 0 to 30.  This was done at the Connect 9.0.3 version.  So every version above 9.0.3 will have the default set to 30.  [Important note – this value is in seconds, not milliseconds]

Recent longevity tests in version 9.2 suggested that this might be triggering a memory leak in the driver. The going theory for why that behavior wasn’t seen in previous longevity tests (between 9.0.3 and 9.2) is that we only upgraded to JRE 7 in 9.2. So the setting we were running with previously suddenly seemed to be a problem once we also upgraded to 1.7.

That value of 30 was introduced for a reason, so we don’t suggest turning it off without knowing that it causes a problem. On the Adobe hosted clusters, we have made the decision to do so since there were signs of memory issues even previously and we didn’t want to compound that.

That said, there are known issues with our driver and JRE 1.7, but only under some circumstances. In the case of Adobe Connect system administrators observing  (continuous) increases in heap memory usage, this parameter value should be set back to 0.

This can be done by changing this value either in the config.ini  from 30 to 0 (DB_PING_TIMEOUT=0)  or by adding this value in the custom.ini (it won’t be there by default, but if you add it, it will take precedence over what is in the config.ini)


XML API Tips: Creating Telephony Profiles Via the XML API

UPDATED – 5-17-2016

The workflow for creating telephony profiles for INTEGRATED telephony providers via the XML API has changed over the last year or so.  Here is an update on the supported method for creating telephony profiles for users using the Adobe Connect Web Services (XML API).

First, you need to find the telephony provider id number (provider-id) that you want to create a profile from.

To do this, you can make the ‘telephony-provider-list‘ API call as follows:


The results will look like this (with obvious real values for the provider-id and acl-id parameters):

<status code=”ok”/>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<name>PGi NA</name>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>
<provider provider-id=”xxxxxxxxx” acl-id=”xxxxxxxxx” provider-type=”integrated”>

Next, you take the provider-id from the call above, and make the ‘telephony-provider-field-list‘ call to list out the telephony Provider fields you need to add to the new telephony profile.  The formatted call will look like this:


provider-id = the provider-id value from the first API call above, for which you are creating the profile.

The results will look like this (for InterCall as an example although all providers will have different ‘x-tel’ fields and different fields that are required in order to build a profile):

<status code=”ok/>
<field provider-id=”xxxxxxxxx field=”xxxxxxxxx” field-id=”x-tel-intercall-conference-number display-in-meeting=”participants required=”false user-specified=”false input-type=”textarea is-hidden=”false>
<name>Conference Number</name>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-intercall-participant-code display-in-meeting=”participants required=”true user-specified=”true input-type=”text is-hidden=”false>
<name>Conference Code</name>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-intercall-leader-pin display-in-meeting=”none required=”true user-specified=”true input-type=”text is-hidden=”false>
<name>Leader Pin</name>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-intercall-company-url display-in-meeting=”participants required=”false user-specified=”false input-type=”url is-hidden=”false>
<name>Further Dial In Numbers</name>
<field provider-id=”xxxxxxxxx” field=”xxxxxxxxx” field-id=”x-tel-intercall-uv-conference-number display-in-meeting=”none required=”false user-specified=”false input-type=”text is-hidden=”true>


Next, once you have the fields you need, you call the telephony-profile-update call to create the profile with all the required fields.  The formatted call will look like this:

(this is using INTERCALL as an example. Your fields may be different depending on your provider and the results from the above call).



principal-id = the principal id of the user for whom you are creating the profile (obtained by other APIs).
profile-status=enabled (to enable the profile).
provider-id = the provider-id value from the first API call above, for which you are creating the profile.
profile-name =the name of the profile you are creating for the user (it’s up to you for naming convention).
x-tel-{field} = the telephony field(s) you are populating (different depending on provider)
value = the value of the telephony field you are setting (numeric). This comes from your telephony provider when you purchase telephony accounts.

The results will look like this:

<status code=”ok”/>
<telephony-profile profile-status=”enabled” provider-id=”xxxxxxxxx” principal-id=”xxxxxxxxx” profile-id=”xxxxxxxxx”>




UPDATED – 4-11-2014
For completing an ARKADIN profile, please also add the following to the workflow:

For all the main providers on hosted, here are the required ‘x-tel’ values: