Users need a web browser capable of running Flash or webRTC. To check the version of flash, visit Adobe’s Flash Version Check page.
If a Mac user is running an out-of-date version of Flash (Oritor will check the version of flash), they can upgrade by visiting the get Flash player page at Adobe.
To run the desktop sharing, the presenter (and only the presenter) needs to have a Java runtime. You can test that Java is installed by visiting Java Test Page (there are download links on this page if you need to install Java). For bandwidth, we recommend 1Mbits download and 0.5 Mbits upload speed. Users can test their actual bandwidth using speedtest.net.
For hardware, we recommend a Dual-core CPU with at least 2G of memory. For Mac, we recommend any Mac running Mac OS X operating system.
Oritor Conferencing has automatic audio clipping, which means it will not transmit a speaker’s audio if the volume is too low.
If the speaker’s audio is low, Oritor Conferencing might take a moment to recognize that someone is speaking before transmitting, causing others to hear your audio only after you have started speaking a few words.
Try placing the microphone closer to your mouth. Also, try increasing the sensitivity of your microphone (see why can’t others hear me when I join the voice conference).
In Oritor, we use the built-in acoustic echo cancellation, so in most cases, you should not hear any echo from remote users.
We recommend that you have your remote users use a headset with microphone. This will ensure the best audio in a session. If a remote user is using a laptop with a built-in microphone, you should not hear an echo. If you are using Oritor broadcast as a participant, we recommend you turn off “One way audio” by clicking on the speaker icon.
However, if two remote users are using laptops with built-in microphones and neither is using a headset and both are sitting close to each other (close enough for the microphone in one laptop to pickup the audio from the speakers in the other laptop), then you will hear an echo.
The reason is the built-in echo cancellation only works with the audio coming from the host laptop — the audio coming from the second laptop will be picked up as an external audio source.
If a participant is causing echo, the best way to solve this problem, if you are logged in as a moderator, is to mute the user by clicking the microphone icon to the left of their name. Overall, the best solution is ask all users to use a headset — this will ensure no background noise or echo.
Oritor uses 16 KHz wideband speeks audio codec and Opus48, which is a high-quality audio codec that compresses very well. If you run an Oritor server within a LAN environment, you can get a sense of the audio quality. It should sound much richer than a plain ordinary telephone system (which is 8 Khz audio).
We recommend that users have 0.5 Mbits/sec upload speed and 1.0 Mbits/sec download speed. Of course, these are not hard numbers, and Oritor will certainly work with less bandwidth, but if your clients have bandwidth in this range, they should experience good audio.
To test a user’s actual internet bandwidth, have them visit http://speedtest.net/. The results at http://speedtest.net/ will give a fairly accurate test of the user’s upload and download speeds. If these numbers are much less than 0.5 Mbits/sec upload speed and 1.0 Mbits/sec download speed, their audio will be poor. One quick check is to ask users to turn off any file transfer they have in the background (such as bittorrent clients) and run the test again.
If you have them use the ping command (windows or Unix prompt) to ping the Oritor server, you want to see a ping response of less than 100ms.
Also, if the user’s client takes over a minute to load, they are likely tunneling through port 80, which will further degrade the audio.
If a specific user is having poor audio quality (i.e. only their audio is choppy but everyone else sounds good), have the individual do a speed test.
Flash restricts applications to use TCP/IP for audio, if the user’s network connection to the Oritor server is experiencing packet loss (dropped packets). Their computer will resend dropped packets, which will incur audio problems if this occurs frequently.
If there are a lot of packets getting cued for resend, you can try having the user drop from audio and then rejoin (click the headset icon twice). If you are a moderator, you can click the ‘x’ next to their name in the listener’s window. This will eject them from the audio session and have their Oritor client automatically rejoin.
If majority of users are experiencing good audio, but a few are not, ask them to join the conference via telephone as that is an ultra reliable and fully supported option.
Conference host may choose from 4 audio options. If a participant browser supports webRTC, this offers the highest quality audio, opus48. This is only realized however if all participants are using webRTC. Dial access supporting G.722 is the next best option, followed by Skye and standard VoIP. Regardless of audio connection, all audio streams are recorded, mixed in real time.
If others in the voice conference don’t hear you when you speak, It may be that webRTC or Flash has picked the wrong microphone on your computer. You can change this with the following steps:
You see a volume indicator next to the drop down for choosing a microphone. Try selecting a different microphone. When you select the active microphone, you’ll immediately see activity in the volume indicator when you speak.
Close this settings dialog and others in the voice conference should now hear you.
When you use webRTC audio, you are using the highest quality, lowest latency audio option. Audio from your mic is going directly to Oritor Conferencing switch, supporting opus48. If you are using standard VoIP, you may experience a delay, depending on the network latency from the speaker to the Oritor server, when using the built-in VoIP in Oritor (clicking the headset icon).
Here’s a breakdown of the path for the audio packets, from your Oritor client, when using VoIP. When you speak, your audio is transmitted by the Oritor client to the FMS server using speex codec. It is then transmitted by the FMS server to the Oriotr switch where it mixes in the audio, then the resulting audio stream is sent back the FMS server, and transmitted back to the client.
Yes, you may upload MS Office documents to Oritor conference or library.
If possible, for best results, save your Word or PowerPoint documet as PDF. If you are using Office 2007, we recommend using Microsoft’s free download to enable Office 2007 to save any document to PDF: download link.
You’ll always get the best results with PDF.
Oritor records all activity in the presentation, chat, webcams, audio, and desktop sharing for playback. Collaborative text can be saved and downloaded at any time separately.
Oritor supports playback in Chrome, FireFox and IE with plugin.
In Oritor, the audio from a recorded session is encoded into Vorbis, an open source audio format that is not patent encumbered. Playback of Vorbis audio is supported in FireFox and Chrome, IE with plugin, but not in Safari.
Oritor will playback the webcams from a session using the WebM container, which, provides a high-quality open source video codec VP8. Playback of video in VP8 is supported by FireFox, Chrome, IE with pluging, but not Safari. See HTML5 video wikipedia article.
Storage values for different types of session in Oritor.
The file sizes are for a one hour session. When a recorded session ends, Oritor archives all the raw content, then runs the recording scripts to create a publish format (presentation).
audio111 MB/h11 MB/h122 MB/h
audio + webcam (1 webcam)131 MB/h51 MB/h182 MB/h
audio + desktop sharing236 MB/h73 MB/h309 MB/h
For audio, the storage of the audio stream is 110 MB/h. The storage is a .wav file
For audio + webcam, the additional storage is for saving each individual webcam stream. A one hour webcam stream at the default resolution (320×240) is 20M.
For audio + deskshare, the additional storage is for the desktop sharing stream (there will only be one stream at any one time). A one hour desktop sharing stream is 125M.
For playback, the audio, webcams, and desktop share are processed into a single playback file WebM (VP8 Codec).
For audio only, the WebM file is 5.4M. There is an additional Vorbis Audio File that is 5M.
For audio + webcam only, there is a single webM file that is 51M
For audio + desktop sharing, there is a single WebM that is 72M.
The information displayed during playback is browser specific.
In Chrome, the audio playback component shows only the current time index for the playback. To see the overall length of the session, you can sadvance to the end of the audio after the audio file has loaded.
In FireFox, the audio playback component shows both the current time index and total time of the audio file.
When looking to download a recorded session, most expect a single link to download the video file.
In contrast, Oritor does not create a video file for playback. Video files for a three hour lecture can get very large. Instead, Oritor creates an HTML5 page that references PNG images and audio, and time indexes the PNG images against the audio to match their display in the session. The result is the source playback files are very small and can be hosted on any web server. The drawback is there will be a pause for the browser to download all this content, but, once downloaded, there is no more load on the web server
You’ll need good upstream and downstream bandwidth from the server. We recommend (at least) 100 MBits/second bandwidth in both directions.
When sharing a webcam as a moderator Oritor lets you select 160×120, 320×240 or 640×480. These use the same amount of bandwidth, roughly 30-50 kbytes/second per stream.
For example, if you have a room with 5 users, each sharing their webcam, then you can calculate the bandwidth usage as follows:
Y = 30-50 Kbytes/sec; let’s assume 40 Kbytes/sec on average
W = amount of webcams that are streaming
U = amount of users that are watching
server incoming bandwidth: W*Y
server outgoing bandwidth: W*(U-1)*Y (minus one since a broadcaster does not have to subscribe to his own stream)
For example, with 5 users in a room with 5 webcams streaming, the bandwidth calculation is as follows:
in: 5*40 = 200 Kbytes/sec incoming bandwidth needed to the server (e.g. 1.6 Mbit)
out: 5*(5-1)*40 = 800 Kbytes/sec outgoing bandwidth needed from the server (e.g. 6.4 Mbit)
Total traffic used after one hour: 60 mins*60 secs*(200 + 800) = 3.6 Gbyte traffic per hour
If you’d have a typical conference situation with the presenter broadcasting their webcam to 30 remote participants, the calculation is as follows:
in: 1*40 = 40 Kbytes/sec incoming (e.g. 0.32 Mbit/sec)
out: 1*(30-1)*40 = 1160 Kbytes/sec outgoing (e.g. 9.3 Mbit/sec)
Total traffic used after one hour: 60 mins*60 secs*( 40 + 1160) = 4.3 Gbyte traffic per hour
If you have 10 of those conferences, then your server needs to be able to output 93 Mbit/sec; that’s not much in a LAN, but it’s a lot if you’re in a hosted environment.
Large “cafe-style chatroom”: 20 viewers, 8 people broadcasting with a webcam:
in: 8*40 = 320 Kbytes/sec ( 2.5 Mbit )
out: 8*(20-1)*40 = 6080 Kbytes/sec ( 48.6 Mbit )
Total traffic used after one hour: 60 mins*60 secs*( 320 + 6080 ) = 23 Gbyte traffic per hour
Sharing slides takes almost no bandwidth beyond the initial uploading/downloading of slides. When the presenter clicks to show the next slide, the viewers receive a “move next slide” command in their Oritor client, and they load the next slide from the local cache. Chat has almost no bandwidth as well.
Desktop sharing takes the most bandwidth, and it’s dependent on the area chosen by the presenter (full screen and region) and how often their screen updates.
A VoIP connection to the Oritor server takes roughly 20 kB/sec per user. The bandwidth for VoIP grows linearly with number of users. For example, if there are 20 participants in a conference, then the bandwidth requirements for the server to support VoIP is 20 * 20 KBytes/sec = 400 kBytes/sec.
If the presenter has only 100 KByte/second upstream, then performing VoIP, video, and desktop sharing will not fit within that upstream constraint. In reality, red5/Flash does a good job of using limited bandwidth and actually works quite well. In the case of desktop sharing, the remote desktops will still receive updates, but the refresh will be much slower than if the presenter was on a LAN (such as within the university or college network).
Oritor uses a Java applet to capture screen updates. Oritor requires Java 7u41 (or later). We will be announcing a option available shortly supporting HD video desktop sharing without requiring Java; check announcments.
Desktop sharing works for Mac, Unix, and PC platforms. Only the presenter needs to have Java installed to share their desktop. You can test if your system has Java installed using the following link. To download Java onto your computer, visit the Java download page.
If you can run the above test applet from your browser, you can run the desktop sharing in Oritor. Please note that on Mac OS X with Java 7, you can run applets with FireFox but not Google Chrome, as Chrome is a 32-bit browser and Java 7 requires a 64-bit browser to run. Hence, on Mac OS X, if you need to run desktop sharing, we recommend using FireFox.
There are no additional requirements (beyond having Flash installed) for viewers to run Oritor and view the presenter’s desktop.
Right-click within the chat area and choose the option “Copy All Text”.