Posts in Category "Seminars"

XML API Tips: Obtaining Quotas for Seminar Licenses

A while back I blogged about how to create a Seminar Session via the XML API in Adobe Connect 9.1 (view original blog here).  A question has since come up around how to obtain the quota for a Seminar License, so you know what to put in for the seminar-expected-load value in the acl-field-update call in the last step of that article.

You can obtain the Seminar License quotas for your different licenses by running this API call:

https://{myConnectURL}/api/xml?action=sco-seminar-licenses-list&sco-id=XXXXXXX

where sco-id = the sco-id of the SHARED SEMINARS folder (or the ‘seminars’ tree-id of the shortcut ‘seminars’).

Example Result (showing an example where there are 2 Licenses):

<results>
<status code=”ok”/>
<seminar-licenses>
<sco>
<begindate>2011-12-02T01:00:01.000+00:00</begindate>
<date-begin>2011-12-01T20:00:01.000-05:00</date-begin>
<date-created>2011-12-02T23:47:02.353-05:00</date-created>
<date-end>2016-12-01T19:59:59.000-05:00</date-end>
<date-modified>2013-11-29T10:53:56.590-05:00</date-modified>
<display-seq>0</display-seq>
<duration>XXXXXXXX</duration>
<enddate>2016-12-02T00:59:59.000+00:00</enddate>
<folder-id>XXXXXXXX</folder-id>
<icon>folder</icon>
<is-expired>false</is-expired>
<is-folder>1</is-folder>
<is-seminar>false</is-seminar>
<name>My Seminar License 1</name>
<quota>1000</quota>
<sco-id>XXXXXXXX</sco-id>
<type>folder</type>
<url-path>/fXXXXXXXX/</url-path>
</sco>
<sco>
<begindate>2011-12-02T01:00:01.000+00:00</begindate>
<date-begin>2011-12-01T20:00:01.000-05:00</date-begin>
<date-created>2011-12-02T23:47:04.490-05:00</date-created>
<date-end>2016-12-01T19:59:59.000-05:00</date-end>
<date-modified>2013-11-29T10:54:04.010-05:00</date-modified>
<display-seq>0</display-seq>
<duration>XXXXXXXX</duration>
<enddate>2016-12-02T00:59:59.000+00:00</enddate>
<folder-id>XXXXXXXX</folder-id>
<icon>folder</icon>
<is-expired>false</is-expired>
<is-folder>1</is-folder>
<is-seminar>false</is-seminar>
<name>My Seminar License 2</name>
<quota>1500</quota>
<sco-id>XXXXXXXX</sco-id>
<type>folder</type>
<url-path>/XXXXXXXX/</url-path>
</sco>
</seminar-licenses>
</results>

Again, there are multiple ways of getting the id of the main Seminars folder.  One quick one is :

https://{myConnectURL}/api/xml?action=sco-shortcuts

and pull the value from either in blue (the will both be the same):

<sco tree-id=”XXXXXXX” sco-id=”XXXXXXX” type=”seminars”>
<domain-name>http://{myConnectURL}</domain-name>
</sco>

Another is:

https://{myConnectURL}/api/xml?action=sco-expanded-contents&sco-id=XXXXXXXX&filter-type=tree

where the sco-id is = the account-id

and pull the value in blue:

<sco depth=”1″ sco-id=”XXXXXXX” folder-id=”XXXXXX” type=”tree” icon=”folder” lang=”en” source-sco-id=”” display-seq=”0″ source-sco-type=”” source-sco-icon=”” content-source-sco-icon=”” duration=””>
<name>Shared Seminars</name>
<url-path>/XXXXXXX/</url-path>
<date-created>2011-12-02T23:46:53.563-05:00</date-created>
<date-modified>2013-11-29T10:54:03.053-05:00</date-modified>
</sco>

Seminar Session Extensions Explained

In Adobe Connect 9.1.1, when you schedule Seminar Sessions, we allow extensions for a certain period of time should you need to go over your allotted (scheduled) session time.  This is handy if you need to wrap up a session that is obviously running a little later than planned.  If there are no other Seminar Sessions scheduled up against your Seminar Session, you can extend a session (depending on when the next session is scheduled to start).  Best case scenario, the maximum extension time for a session is up to 70 total minutes (technically) if there is enough free time on the Seminar Calendar.  But that is ONLY if the conditions are just right.  That maximum (best case scenario) is 2 x 30 minute extensions + a 10 minute shutdown warning countdown.  Here’s the breakdown of how all this works.

Once your scheduled time of your Seminar Session is up, one of two things can happen if you need to go longer:

1) If there is a Seminar Session that is schedule to start in the open time slot on the Seminar Calendar immediately following your session, you will only get prompted for the 10 minute shutdown.  This means that in 10 minutes, your session will terminate because another session was scheduled to begin immediately after your session was scheduled to end.  So basically it’s no real extension other than the 10 minute warning.

10min2

Once the 10 minutes is up, the session ends and all users are disconnected from the session due to the conflict of the other session being active.

2) If there isn’t a Seminar Session that is scheduled to start in the open time slot on the Seminar Calendar immediately following your session, you will get prompted for a 30 minute extension (as shown below). It is automatic.  The prompt is shown to hosts.

extension1

Once that first 30 minute extension is up, Adobe Connect will check the Seminar Calendar again for a session coming up against your active session.  At this point, one of two things will happen (similar to above):

1) If there is no other upcoming session again on the calendar, it will trigger one more 30 minute extension (as shown below):

extension1

2) If there IS a session on the calendar that is going to start, you will get the 10 minute warning instead.  Meaning that your session was able to go just 40 minutes over the end time (first 30 min extension + 10 minute warning).

10min2

If you did get the second 30 minute extension, after the second 30 minute extension is up (so currently having been extended for 60 total minutes passed your initial end time of the session), you will no longer be given another 30 minute extension option and instead, you will be presented with the 10 minute warning (even if there is no other session coming up on the Seminar Calendar). This means that in total, you would have been granted 70 extra minutes of extension before the session ends (30 + 30 + 10), should the conditions have been just right on the Seminar Calendar.

10 minute

 

Vantage Point is not just about Bandwidth

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

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

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

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

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

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

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

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

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

Check it out at Refined Data: http://vantagepoint.refineddata.com/

Troubleshooting Caption Colorado Domain Names in Meeting Pod

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

Symptom looks like this:

CC.fw

Always make certain you have the correct pod version: http://www.adobe.com/products/adobeconnect/feature-details/closed-captioning.html

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

C:\flyfishing\frank>nslookup connect.captioncolorado.com
Server:  dns.adobe.com
Address:  xx.xx.xx.xx
Non-authoritative answer:
Name:    connect.captioncolorado.com
Address:  216.241.103.7
C:\flyfishing\frank>nslookup breeze.captioncolorado.com
Server:  dns.adobe.com
Address:  xx.xx.xx.xx
Non-authoritative answer:
Name:    breeze.captioncolorado.com
Address:  216.241.103.7

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

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

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

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

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

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

Untitled-1.fw

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

Untitled-2.fw

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

Untitled-1.fw

Untitled-3.fw

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

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

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

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

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

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

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

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

.tunneljpgOctagon

Compare with a connection without tunneling:

no-tunnel

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

<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 separate third Administration option in Connect Central that manages the timeout of sessions that do not have any activity:

Untitled-1.fw

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

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