├── Configuration.md
├── Configuration_AVPF_tail_length.md
├── Configuration_Audio.md
├── Configuration_Audio_Video_codecs.md
├── Configuration_Bridge_configuration.md
├── Configuration_Debugging_the_system.md
├── Configuration_NAT_Firewall_traversal.md
├── Configuration_Presentation_sharing.md
├── Configuration_RTP_buffer_size.md
├── Configuration_Recording_conference_to_a_file.md
├── Configuration_SIP_network_transports.md
├── Configuration_SIP_registration.md
├── Configuration_Security.md
├── Configuration_Video.md
├── Makefile.am
├── README.md
├── SSL_CA.der
├── SSL_CA.pem
├── SSL_Priv.pem
├── SSL_Pub.der
├── SSL_Pub.pem
├── Support_BuildingSourceCode.md
├── Support_FAQ.md
├── Support_Known_issues.md
├── Support_Roadmap.md
├── Support_Testing_the_system.md
├── Support_Tips.md
├── Technical_Audio_mixer_design.md
├── Technical_Bandwidth_management_and_congestion_control.md
├── Technical_Call_session_management.md
├── Technical_NAT_and_firewall_traversal.md
├── Technical_Presentation_sharing.md
├── Technical_Protecting_a_bridge_with_password.md
├── Technical_Recording_conference_to_a_file.md
├── Technical_SA_versus_AS_modes.md
├── Technical_Security.md
├── Technical_Stereoscopic_spatial_3D_audio.md
├── Technical_Video_mixer_design.md
├── Technical_Video_quality.md
├── autogen.sh
├── configure.ac
├── documentation
├── technical-guide.doc
└── technical-guide.pdf
├── doubango
├── tinyBFCP.vcproj
├── tinyDAV.vcproj
├── tinyHTTP.vcproj
├── tinyIPSec.vcproj
├── tinyMEDIA.vcproj
├── tinyMSRP.vcproj
├── tinyNET.vcproj
├── tinyRTP.vcproj
├── tinySAK.vcproj
├── tinySDP.vcproj
├── tinySIGCOMP.vcproj
├── tinySIP.vcproj
├── tinySMS.vcproj
└── tinyXCAP.vcproj
├── fonts
└── truetype
│ └── freefont
│ ├── AUTHORS
│ ├── COPYING
│ ├── CREDITS
│ ├── ChangeLog
│ ├── FreeMonoBold.ttf
│ ├── FreeSerif.ttf
│ ├── INSTALL
│ ├── README
│ ├── TROUBLESHOOTING
│ └── USAGE
├── images
├── audio_mixer_resampler.png
├── logo.jpg
├── logo.png
├── logo35x34.jpg
└── presentation_sharing.png
├── include
├── OpenTelepresenceAPI.h
├── OpenTelepresenceConfig.h
└── opentelepresence
│ ├── OTBridge.h
│ ├── OTBridgeInfo.h
│ ├── OTCodec.h
│ ├── OTCodecAudio.h
│ ├── OTCodecVideo.h
│ ├── OTCommon.h
│ ├── OTEngine.h
│ ├── OTFrame.h
│ ├── OTFrameAudio.h
│ ├── OTFrameVideo.h
│ ├── OTMixerMgr.h
│ ├── OTMixerMgrAudio.h
│ ├── OTMixerMgrMgr.h
│ ├── OTMixerMgrVideo.h
│ ├── OTMutex.h
│ ├── OTObject.h
│ ├── OTProcess.h
│ ├── OTProxyPlugin.h
│ ├── OTProxyPluginConsumer.h
│ ├── OTProxyPluginConsumerAudio.h
│ ├── OTProxyPluginConsumerVideo.h
│ ├── OTProxyPluginMgr.h
│ ├── OTProxyPluginProducer.h
│ ├── OTProxyPluginProducerAudio.h
│ ├── OTProxyPluginProducerVideo.h
│ ├── OTResampler.h
│ ├── OTRole.h
│ ├── OTSessionInfo.h
│ ├── OTWrap.h
│ ├── cfg
│ ├── OTCfg.h
│ └── OTCfgParser.h
│ ├── docstreamer
│ ├── OTDocStreamer.h
│ └── OTDocStreamerOpenOffice.h
│ ├── filters
│ ├── OTFilter.h
│ └── OTOverlay.h
│ ├── jsoncpp
│ ├── json-forwards.h
│ └── json.h
│ ├── mixers
│ ├── OTMixer.h
│ ├── OTMixerAudio.h
│ ├── OTMixerAudio2D.h
│ ├── OTMixerAudio3D.h
│ ├── OTMixerVideo.h
│ ├── OTMixerVideo2D.h
│ └── OTMixerVideo3D.h
│ ├── nettransport
│ ├── OTHttpTransport.h
│ └── OTNetTransport.h
│ ├── patterns
│ ├── OTPattern.h
│ ├── OTPatternVideo.h
│ ├── OTPatternVideoHangout.h
│ └── OTPatternVideoWebEx.h
│ ├── platforms
│ ├── generic
│ │ └── OTEngineGen.h
│ ├── osx
│ │ └── OTEngineOSX.h
│ └── win32
│ │ └── OTEngineWin32.h
│ ├── presence
│ ├── OTPresenceNotifer.h
│ └── OTPresenceParser.h
│ └── recorder
│ ├── OTRecorder.h
│ └── OTWebM.h
├── opentelepresence.sln
├── ragel
├── cfg.rl
└── ragel.sh
├── self-signed-certs.sh
├── source
├── OTBridge.cc
├── OTBridgeInfo.cc
├── OTCodec.cc
├── OTCodecAudio.cc
├── OTCodecVideo.cc
├── OTEngine.cc
├── OTFrame.cc
├── OTFrameAudio.cc
├── OTFrameVideo.cc
├── OTMixerMgr.cc
├── OTMixerMgrAudio.cc
├── OTMixerMgrMgr.cc
├── OTMixerMgrVideo.cc
├── OTMutex.cc
├── OTObject.cc
├── OTProcess.cc
├── OTProxyPlugin.cc
├── OTProxyPluginConsumer.cc
├── OTProxyPluginConsumerAudio.cc
├── OTProxyPluginConsumerVideo.cc
├── OTProxyPluginMgr.cc
├── OTProxyPluginProducer.cc
├── OTProxyPluginProducerAudio.cc
├── OTProxyPluginProducerVideo.cc
├── OTResampler.cc
├── OTSessionInfo.cc
├── OTWrap.cc
├── cfg
│ ├── OTCfg.cc
│ └── OTCfgParser.cc
├── docstreamer
│ ├── OTDocStreamer.cc
│ └── OTDocStreamerOpenOffice.cc
├── filters
│ ├── OTFilter.cc
│ └── OTOverlay.cc
├── jsoncpp
│ └── jsoncpp.cc
├── main.cc
├── mixers
│ ├── OTMixer.cc
│ ├── OTMixerAudio.cc
│ ├── OTMixerAudio2D.cc
│ ├── OTMixerAudio3D.cc
│ ├── OTMixerVideo.cc
│ ├── OTMixerVideo2D.cc
│ └── OTMixerVideo3D.cc
├── nettransport
│ ├── OTHttpTransport.cc
│ └── OTNetTransport.cc
├── patterns
│ ├── OTPattern.cc
│ ├── OTPatternVideo.cc
│ ├── OTPatternVideoHangout.cc
│ └── OTPatternVideoWebEx.cc
├── platforms
│ ├── generic
│ │ └── OTEngineGen.cc
│ ├── osx
│ │ └── OTEngineOSX.cc
│ └── win32
│ │ └── OTEngineWin32.cc
├── presence
│ ├── OTPresenceNotifer.cc
│ └── OTPresenceParser.cc
└── recorder
│ ├── OTRecorder.cc
│ └── OTWebM.cc
├── telepresence.cfg
├── telepresence.vcproj
├── thirdparties
├── common
│ └── include
│ │ └── AL
│ │ ├── al.h
│ │ ├── alc.h
│ │ ├── alext.h
│ │ ├── efx-creative.h
│ │ ├── efx-presets.h
│ │ └── efx.h
└── win32
│ └── lib
│ ├── OpenAL-patched
│ ├── OpenAL32.dll
│ └── readme.txt
│ ├── OpenAL-unpatched
│ └── OpenAL32.dll
│ └── OpenAL32.lib
└── website
├── assets
├── css
│ ├── bootstrap-responsive.css
│ ├── bootstrap.css
│ └── docs.css
├── ico
│ ├── apple-touch-icon-114-precomposed.png
│ ├── apple-touch-icon-144-precomposed.png
│ ├── apple-touch-icon-57-precomposed.png
│ ├── apple-touch-icon-72-precomposed.png
│ ├── favicon.ico
│ └── favicon.png
├── img
│ ├── bootstrap-docs-readme.png
│ ├── bs-docs-bootstrap-features.png
│ ├── bs-docs-masthead-pattern.png
│ ├── bs-docs-responsive-illustrations.png
│ ├── bs-docs-twitter-github.png
│ ├── glyphicons-halflings-white.png
│ ├── glyphicons-halflings.png
│ ├── grid-baseline-20px.png
│ ├── less-logo-large.png
│ ├── responsive-illustrations.png
│ ├── tp-logo.jpg
│ └── webrtc-logo.png
└── js
│ ├── application.js
│ ├── bootstrap-affix.js
│ ├── bootstrap-alert.js
│ ├── bootstrap-button.js
│ ├── bootstrap-carousel.js
│ ├── bootstrap-collapse.js
│ ├── bootstrap-dropdown.js
│ ├── bootstrap-modal.js
│ ├── bootstrap-popover.js
│ ├── bootstrap-scrollspy.js
│ ├── bootstrap-tab.js
│ ├── bootstrap-tooltip.js
│ ├── bootstrap-transition.js
│ ├── bootstrap-typeahead.js
│ ├── bootstrap.js
│ ├── bootstrap.min.js
│ ├── google-code-prettify
│ ├── prettify.css
│ └── prettify.js
│ ├── holder
│ └── holder.js
│ ├── html5shiv.js
│ └── jquery.js
├── contact.htm
├── index.html
├── settings.htm
└── sounds
└── ringbacktone.wav
/Configuration.md:
--------------------------------------------------------------------------------
1 | The Telepresence system is configured using **cfg** files. The main cfg file is named **telepresence.cfg** and should be on the same directory where the binary is installed unless you run the app with _"--config=PATH"_ argument. The source code contains a sample configuration file to use to get started. The sample configuration is installed after successfully building the system and running _"make samples"_.
2 |
3 | The configuration files are parsed using code generated with [Ragel tool](http://www.complang.org/ragel/).
4 | A configuration file contains comments, sections and entries:
5 |
6 |
7 |
8 | ## Comments ##
9 | A comment starts with **#**
10 | ```
11 | # I’m a comment
12 | Age = 25 # I’m another comment
13 | ```
14 |
15 | ## Sections ##
16 | A section name must be enclosed by square brackets. The section name is case insensitive.
17 | ```
18 | # this is a bridge section
19 | [bridge]
20 | ```
21 |
22 | ## Entries ##
23 | An entry is a key-value-pair and must be tied to a section. Both the key and the value are case insensitive. **The key must not start with a SPACE**.
24 | ```
25 | [product] # I’m the section
26 | version = 1.2 # I’m an entry with floating number value
27 | name = telepresence # I’m an entry with a string value
28 | ```
--------------------------------------------------------------------------------
/Configuration_AVPF_tail_length.md:
--------------------------------------------------------------------------------
1 | **avpf-tail-length** configuration entry defines the maximum and minimum queue length used to store the outgoing RTP packets. The stored packets are used to honor incoming **RTCP-NACK** requests. See [here](Technical_Video_quality#AVPF_tail_length.md) for more technical information.
2 | ```
3 | avpf-tail-length = 200;500 # min;max
4 | ```
5 | _Configuration 8: Setting AVPF tail length_
--------------------------------------------------------------------------------
/Configuration_Audio.md:
--------------------------------------------------------------------------------
1 | This section explains how to use settings related to the audio.
2 |
3 |
4 |
5 | # Pivot settings #
6 | The notion of **pivot settings** is explained [here](Technical_Audio_mixer_design.md).
7 | ```
8 | audio-channels = 1
9 | audio-bits-per-sample = 16
10 | audio-sample-rate = 8000
11 | audio-ptime = 20
12 | audio-volume = 1.0f
13 | audio-dim = 2d
14 | audio-max-latency = 200
15 | ```
16 | _Configuration 11: Audio settings_
17 |
18 | * **audio-channels** - number of audio channels to use. Supported values are 1 and 2.
19 | * **audio-bits-per-sample** - number of bits for each audio sample. Supported values are 8, 16 and 32.
20 | * **audio-sample-rate**: - audio sample rate. Almost any value is supported: http://en.wikipedia.org/wiki/Sampling_rate. Unit: Hz.
21 | * **audio-ptime** - number of milliseconds for each audio frame. The value should be multiple of 10. Supported values: [
1 - 255]
22 | * **audio-volume** - attenuation (or gain) to apply to the mixed audio. Supported values: [
0.0f - 1.0f]
.
23 | * **audio-dim** - mixer dimensions. The value must be 2d (Linear) or 3d (Spatial). 3d requires building the system with [OpenAL Soft](Support_BuildingSourceCode#Building_OpenAL_Soft.md).
24 | * **audio-max-latecncy** - maximum audio delay (because of clock drift) before resetting the jitter buffer. The value could be any positive value. Unit: milliseconds.
--------------------------------------------------------------------------------
/Configuration_Audio_Video_codecs.md:
--------------------------------------------------------------------------------
1 | **codecs** configuration entry defines the list of all supported codecs. Only **G.711** and **G.722** are natively supported and all other codecs have to be enabled when building the Doubango VoIP framework source code.
2 | Each codec priority is equal to its position in the list. First codecs have highest priority.
3 | Supported values are:
4 | * opus
5 | * pcma
6 | * pcmu
7 | * amr-nb-be
8 | * amr-nb-oa
9 | * speex-nb
10 | * speex-wb
11 | * speex-uwb
12 | * g729
13 | * gsm
14 | * g722
15 | * ilbc
16 | * h264-bp
17 | * h264-mp
18 | * vp8
19 | * h263
20 | * h263+
21 | * theora
22 | * mp4v-es.
23 |
24 | ```
25 | codecs = pcma;pcmu;vp8;h264-bp;h264-mp
26 | ```
27 | _Configuration 9: Setting audio/video codecs_
--------------------------------------------------------------------------------
/Configuration_Bridge_configuration.md:
--------------------------------------------------------------------------------
1 | In this beta version, global configuration entries are ignored when reused with a [
bridge]
section. For example, setting the audio sample rate at global scoop applies to all bridges but redefining it for a [bridge](bridge.md) section will be ignored. In the release version, it will be possible to override almost any configuration entry.
2 | It’s not required to add a bridge in order to be able to make conference calls.
3 | You can add as many [
bridge]
sections as you want.
4 |
5 | Supported entries are: **id** and **pin-code**.
6 | ```
7 | [bridge]
8 | id=10060
9 | pin-code=1234
10 |
11 | [bridge]
12 | id=10061
13 | pin-code=0000
14 | ```
15 | _Configuration 17: Bride settings_
16 |
17 | * **id** - defines the bridge identifier (a SIP client would call _"sip:@domain"_ to connect to this bridge).
18 | * **pin-code** – A 4-digit code used to protect the bridge.
19 | For information on how a client authenticates to a bridge, check [here](Technical_Protecting_a_bridge_with_password.md).
--------------------------------------------------------------------------------
/Configuration_Debugging_the_system.md:
--------------------------------------------------------------------------------
1 | As a developer, the first action is to edit your configuration file to change the debug-level from **ERROR** to **INFO**.
2 |
3 | When you connect to the MCU you always have video stream back (you see yourself) but your audio stream is never sent back. For debugging purposes, it could be useful to ask your audio stream back. Hearing your own sound helps testing that everything work. Without loopback audio, you must connect at least two endpoints to test audio (encoding, decoding, streaming, resampling…).
4 | ```
5 | debug-level = INFO
6 | debug-audio-loopback = yes
7 | ```
8 | _Configuration 1: Useful debug settings_
9 |
10 | **debug-level** - defines the minimum debug level to display. Supported values: INFO, WARN, ERROR and FATAL.
11 |
12 | **debug-level-loopack** - whether to enable audio loopback for testing (see above for more information).
13 |
14 | We require having your **debug-level** equal to **INFO** when reporting/sharing issues.
--------------------------------------------------------------------------------
/Configuration_NAT_Firewall_traversal.md:
--------------------------------------------------------------------------------
1 | This section shows how to enable or disable symmetric RTP (technical details [here](Technical_NAT_and_firewall_traversal#Symmetric_RTP.md)), ICE (technical details [here](Technical_NAT_and_firewall_traversal#ICE.md)) and RTCP-MUX (technical details [here](Technical_NAT_and_firewall_traversal#RTCP-MUX.md)).
2 | ```
3 | rtp-symmetric-enabled = yes # no to disable
4 | ice-enabled = yes # no to disable
5 | icestun-enabled = yes
6 | stun-server = stun.l.google.com;19302;stun-user;stun-password
7 | rtcp-mux-enabled = yes # no to disable
8 | ```
9 | _Configuration 6: Enabling/disabling NAT traversal features_
10 |
11 | * **rtp-symmetric-enabled** - whether to enable symmetric RTP ([RFC 4961](http://tools.ietf.org/html/rfc4961)) for NAT and firewall traversal
12 | * **ice-enabled** - whether to enable ICE ([RFC 5245](http://tools.ietf.org/html/rfc5245)) for NAT and firewall traversal.
13 | * **icestun-enabled** - whether to use STUN to gather reflexive addresses or not. This option is useful when the server is on a public network or all peers are on the same local network. In these cases, disabling STUN for ICE will speed up the call setup. Disabling icestun is also useful when the system is installed on a PC without access to internet.
14 | * **stun-server** - defines the STUN/TURN server to use to gather reflexive addresses for the ICE candidates. If no server is defined then, a default one will be used. The default STUN/TURN server is **numb.viagenie.ca:3478**.
15 | * Format: server-fqdn-value; server-port-value; user-name-value; user-password-value
16 | * server-fqdn-value: A valid IPv4/v6 address or host name.
17 | * server-port: A valid port number.
18 | * user-name-value: The login to use for TURN authentication. Use star (`*`) to ignore.
19 | * user-password-value: The password to use for TURN authentication. Use star (`*`) to ignore.
20 | * **rtcp-mux-enabled** - whether to enable RTC-MUX ([RFC 5761](http://tools.ietf.org/html/rfc5761)).
--------------------------------------------------------------------------------
/Configuration_Presentation_sharing.md:
--------------------------------------------------------------------------------
1 | A presentation is any **PowerPoint** document and it could be shared from any SIP client running on any device. The presentation is uploaded to the TelePresence system using **HTTP(S) POST** request which means a http (or https) transport must be configured as explained [here](Configuration_SIP_network_transports.md). More technical details could be found [here](Technical_Presentation_sharing.md).
2 | ```
3 | presentation-sharing-enabled = yes
4 | presentation-sharing-process-local-port = 2083
5 | presentation-sharing-base-folder = ./presentations
6 | presentation-sharing-app = soffice
7 | ```
8 | _Configuration 11: Presentation sharing_
9 |
10 | * **presentation-sharing-enabled** - whether to enable presentation sharing. Default is **yes**. The application must be built with [OpenOffice](Support_BuildingSourceCode#Building_openOffice.md) (recommended) or [LibreOffice](Support_BuildingSourceCode#Building_openOffice.md) SDK to support this feature. This feature will be silently disabled if both SDKs are missing.
11 | * **presentation-sharing-process-local-port** - some implementations requires a third-party application (e.g. OpenOffice or LibreOffice) to export the presentation. The third-party application will be forked to run in the background and the local port ([1024-65535]) is used to communicate with the TelePresence system. For example, if the third-party application is OpenOffice and the local port is equal to **2083** then:
12 | * command string would be: `soffice -norestore –headless -nofirststartwizard -invisible "-accept=socket,host=localhost,port=2083;urp;StarOffice.ServiceManager"`
13 | * and the connection string would be: `uno:socket,host=localhost,port=2083;urp;StarOffice.ServiceManager`. **soffice** is the OpenOffice application binary. Your **$PATH** environment variable must reference the folder containing the binary or **presentation-sharing-app** must contain a full path (e.g. _/opt/openoffice4/program/soffice_).
14 | * **presentation-sharing-base-folder** - base folder where to store uploaded presentations and temporary exported jpeg images. For example, a document named _mypres.ppt_ uploaded by _bob_ who is connected to a bridge with number equal to _100600_ would have a path equal to `/100600/bob/mypres.ppt`.
15 | * **presentation-sharing-app** - third-party application name. Could be full (e.g. _"/opt/openoffice4/program/soffice"_) or relative (e.g. _"soffice"_) path. Relative path requires having the folder containing the application in your **$PATH** environment variable.
--------------------------------------------------------------------------------
/Configuration_RTP_buffer_size.md:
--------------------------------------------------------------------------------
1 | **rtp-buffersize** configuration entry is used to define the internal buffer size to use for RTP sockets. The higher this value is the lower will be the RTP packet loss. Please note that the maximum value depends on your system (e.g. 65535 on Windows). A very high value could introduce delay on video stream and it’s highly recommended to also [enable video jitter buffer option](Technical_Video_quality#Jitter_buffer.md).
2 |
3 | Code usage:
4 | ```
5 | setsockopt(SOL_SOCKET, SO_RCVBUF, rtp-buffsize-value);
6 | setsockopt(SOL_SOCKET, SO_SNDBUF, rtp-buffsize-value);
7 | ```
8 | Configuration:
9 | ```
10 | rtp-buffersize = 65535
11 | ```
12 | _Configuration 7: Setting RTP buffer size_
--------------------------------------------------------------------------------
/Configuration_Recording_conference_to_a_file.md:
--------------------------------------------------------------------------------
1 | The configuration file is used to specify whether to record the sessions, which container to use and where to store the output file.
2 | ```
3 | record = yes
4 | record-file-ext = mp4
5 | ```
6 | _Configuration 10: Recording conference to a file_
7 |
8 | * **record** - whether to record the sessions.
9 | * **record-file-ext** - defines the container to use. Almost any container (avi, mp4, webm, mkv …) could be used but this depends on how you built FFmpeg. For more technical information, please check [here](Technical_Recording_conference_to_a_file.md).
10 | We highly recommend using [VLC](http://www.videolan.org/vlc/index.html) to play the output file.
--------------------------------------------------------------------------------
/Configuration_SIP_network_transports.md:
--------------------------------------------------------------------------------
1 | The system supports many network transports for the SIP signaling protocol and content sharing. The network connections are declared using **transport** configuration entries.
2 | ```
3 | transport = udp;*;20060;*
4 | transport = ws;*;20060;4
5 | transport = wss;*;20062;*
6 | transport = tcp;*;20063
7 | transport = tls;*;20064;*
8 | transport = http;*;20065
9 | transport = https;*;20066
10 |
11 | ```
12 | _Configuration 2: Signaling (SIP) transports_
13 |
14 | **Format**: protocol-value;ip-address-value;port-value;ip-version-value.
15 |
16 | * protocol-value must be **udp** , **tcp** , **tls** , **ws**, **wss**, **http** or **https**. **ws** protocol defines WebSocket and **wss** the secure version (requires OpenSSL). At least one WebSocket transport must be added to allow a web browser (WebRTC SIP client) to connect to the system. The other protocols (tcp, tls and udp) are used for SIP-legacy devices or PSTN.
17 | * local-ip-value is any valid IPv4/IPv6 address or FQDN. Use star (`*`) to let the system choose the best local IP address to bind to. Examples: udp;`*`;5060 or ws;`*`;5061 or wss;192.168.0.10;5062
18 | * local-port-value is any unused local port to bind to. Use star (`*`) to let the system choose the best unused port to bind to. Examples: udp;`*`;`*` or ws;`*`;`*` or wss;`*`;5062
19 | * ip-version-value defines the IP version to use. Must be **4**, **6** or *
. Star (`*`) is used to let the system choose the best one. Using star (`*`) only make sense if local-ip-value is a FQDN instead of IP address.
20 | A transport configuration entry must have at least a protocol, IP address (or star) and port (or star). The IP version is optional.
21 | **udp** , **tcp** , **tls** , **ws** and **wss** protocols are used to transport SIP messages while **http** and **https** are used to upload presentations.
--------------------------------------------------------------------------------
/Configuration_SIP_registration.md:
--------------------------------------------------------------------------------
1 | Many SIP clients require to be registered (logged in) before being able to make calls. By default, any **REGISTER** request to the gateway will be rejected.
2 |
3 | **accept-sip-reg** entry defines whether to accept incoming SIP REGISTER requests or not (acting as SIP registrar).
4 | ```
5 | accept-sip-reg = yes # no to disable
6 | ```
7 | _Configuration 5: Enabling/disabling SIP registration_
8 |
9 | When the Telepresence system is behind a SIP registrar (e.g. **Asterisk**) then, this configuration entry is useless as the REGISTER requests will not be forwarded to the MCU.
10 |
11 | See also:
12 | * [SA versus AS modes](Technical_SA_versus_AS_modes.md)
--------------------------------------------------------------------------------
/Configuration_Security.md:
--------------------------------------------------------------------------------
1 | The configuration file allows setting the SSL certificate files to be used for TLS and WSS signaling protocols. The certificates are also used for DTLS-SRTP. The Doubango framework must be built with [OpenSSL](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_OpenSSL) enabled as explained [here](Support_BuildingSourceCode#Building_OpenSSL.md).
2 | ```
3 | ssl-private-key = /tmp/ssl.pem
4 | ssl-public-key = /tmp/ssl.pem
5 | ssl-ca = /tmp/ssl.pem
6 | ssl-mutual-auth = no
7 | ```
8 | _Configuration 3: Setting SSL certificates_
9 |
10 | * **ssl-private-key** - the full path to the PEM file.
11 | * **ssl-public-key** - the full path to the PEM file.
12 | * **ssl-ca** - the full path to the PEM file.
13 | * **ssl-mutual-auth** - whether the incoming connection requests must fail if the remote peer certificates are missing or do not match the local ones. This only applies to **TLS** or **WSS** and is useless for **DTLS-SRTP** as certificates are always required.
14 |
15 | The configuration file also allows setting the _SRTP_ type.
16 | ```
17 | srtp-mode = optional
18 | srtp-type = sdes;dtls
19 | ```
20 | _Configuration 4: SRTP settings_
21 |
22 | **srtp-mode** – defines the SRTP mode to use for negotiation. Supported values are none, optional and mandatory. Only optional and mandatory modes will work if the SIP client is a WebRTC browser as SRTP is required.
23 | Based on the mode, the SDP on the outgoing INVITEs will be formed like this:
24 | * none:
25 | * profile will be equal to _RTP/AVP_
26 | * no crypto lines or certificate fingerprints will be added
27 | * optional:
28 | * profile will be equal to _RTP/AVP_
29 | * two crypto lines will be added if **srtp-type** includes sdes, plus certificate fingerprints if **srtp-type** also includes ‘dts’.
30 | * mandatory:
31 | * profile will be equal to _RTP/SAVP_ if **srtp-type** is equal to SDES or _UDP/TLS/RTP/SAVP_ if **srtp-type** is equal to dtls
32 | * two crypto lines will be added if **srtp-type** is equal to sdes or certificate fingerprints if **srtp-type** is equal to dtls
33 |
34 | **srtp-type** - defines the list of all supported SRTP types. Defining multiple values only make sense if the srtp-mode value is equal to optional which means we want to negotiate the best one. Supported values are sdes and dtls.
35 |
36 | _DTLS-SRTP_ requires valid SSL certificates and Doubango source code must be compiled with [OpenSSL](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_OpenSSL) version 1.0.1 or later.
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Source code freely provided to you by Doubango Telecom ®. This is a good and viable **open source** alternative to Google Hangouts.
2 |
3 |
4 |
5 |
6 |
7 |  |
8 |  |
9 |
10 |
11 | Demonstration |
12 | Presentation sharing |
13 |
14 |
15 |
16 | ## Main features ##
17 | This is a short but not exhaustive list of supported features on this beta version:
18 |
19 | * Powerful [MCU (Multipoint Control Unit)](http://en.wikipedia.org/wiki/Multipoint_control_unit) for audio and video mixing
20 | * **Stereoscopic** (spatial) 3D and stereophonic audio
21 | * Full (**1080p**) and Ultra (**2160p**) HD video up to **120fps**
22 | * Conference **recording** to a file (containers: **.mp4**, **.avi**, **.mkv** or **.webm**)
23 | * Revolutionary way to **share presentations**: documents are "streamed" in the video channel to allow any SIP client running on any device to participate
24 | * Smart adaptive audio and video bandwidth management
25 | * Congestion control mechanism
26 | * SIP registrar
27 | * 4 SIP transports (**WebSocket**, **TCP**, **TLS** and **UDP**)
28 | * SA (direct connection to SIP clients) and AS (behind a server, such as [Asterisk](http://www.asterisk.org/), [reSIProcate](http://www.resiprocate.org/Main_Page), [openSIPS](http://www.opensips.org/), [Kamailio](http://www.kamailio.org/w/)…) modes
29 | * Support for any [WebRTC](http://www.webrtc.org/)-capable browser ([WebRTC demo client](https://www.doubango.org/conf-call/) at [https://www.doubango.org/conf-call/](https://www.doubango.org/conf-call/))
30 | * Mixing different audio and video codecs on a single bridge (**h264**, **vp8**, h263, mp4v-es, theora, **opus**, **g711**, speex, **g722**, gsm, **g729**, amr, ilbc)
31 | * **Protecting** a bridge with PIN code
32 | * **Unlimited** number of bridges and participants
33 | * Connecting **any SIP client** (Mobiles, Tablets, Desktops, Set-top-boxes, Smart TVs...)
34 | * Easy interconnection with **PSTN**
35 | * **NAT traversal** (Symmetric RTP, RTCP-MUX, ICE, STUN and TURN)
36 | * **RTCP Feedbacks** (NACK, PLI, FIR, TMMBN, REMB…) for better video experience
37 | * Secure signalling (WSS, TLS) and media (SDES-SRTP and DTLS-SRTP)
38 | * Continuous presence
39 | * Smart algorithm to detect speakers and listeners
40 | * Different video patterns/layouts
41 | * Multiple operating systems (**Linux**, **OS X**, **Windows** …)
42 | * 100% open source and free (no locked features)
43 | * [Full documentation](https://www.doubango.org/conf-call/technical-guide.pdf)
44 | * …and many others
45 |
46 | This short list is a good starting point to help you to understand what you could expect from our Telepresence system.
47 |
48 | ## Getting started ##
49 | 1. Read the [technical guide](https://www.doubango.org/conf-call/technical-guide.pdf?svn=2) for more information on how to [build](Support_BuildingSourceCode.md), [install](Support_BuildingSourceCode#Installing_the_configuration_and_fonts_files.md) and run the system
50 | 1. Test the system as explained [here](Support_Testing_the_system.md)
51 | 1. Share issues and technical questions on our [developer group](https://groups.google.com/group/opentelepresence)
52 | 1. Find our roadmap [here](Support_Roadmap.md)
53 |
54 | Even if any SIP client could be used we highly recommend for this beta version to use our [WebRTC demo client](https://www.doubango.org/conf-call) to ease debugging.
55 |
56 | ## Technical help ##
57 | Please check our [issue tracker](https://github.com/DoubangoTelecom/telepresence/issues) or [developer group](https://groups.google.com/group/opentelepresence) if you have any problem.
58 | We highly recommend reading our [Technical guide](https://www.doubango.org/conf-call/technical-guide.pdf?svn=2).
59 | Please check the list of [known issues](Support_Known_issues.md) before reporting.
60 |
--------------------------------------------------------------------------------
/SSL_CA.der:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/SSL_CA.der
--------------------------------------------------------------------------------
/SSL_CA.pem:
--------------------------------------------------------------------------------
1 | -----BEGIN CERTIFICATE-----
2 | MIIEITCCAwmgAwIBAgIJAPItJ/nUv/rKMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD
3 | VQQGEwJGUjEWMBQGA1UECAwNSWxlLWRlLUZyYW5jZTEOMAwGA1UEBwwFUGFyaXMx
4 | HjAcBgNVBAoMFURvdWJhbmdvIFRlbGVjb20gRVVSTDENMAsGA1UECwwEVm9JUDEe
5 | MBwGA1UEAwwVRG91YmFuZ28gVGVsZWNvbSBFVVJMMSAwHgYJKoZIhvcNAQkBFhFp
6 | bmZvQGRvdWJhbmdvLm9yZzAeFw0xNTAzMDQwMTUwNDNaFw0yNTAzMDEwMTUwNDNa
7 | MIGmMQswCQYDVQQGEwJGUjEWMBQGA1UECAwNSWxlLWRlLUZyYW5jZTEOMAwGA1UE
8 | BwwFUGFyaXMxHjAcBgNVBAoMFURvdWJhbmdvIFRlbGVjb20gRVVSTDENMAsGA1UE
9 | CwwEVm9JUDEeMBwGA1UEAwwVRG91YmFuZ28gVGVsZWNvbSBFVVJMMSAwHgYJKoZI
10 | hvcNAQkBFhFpbmZvQGRvdWJhbmdvLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP
11 | ADCCAQoCggEBAKzwFx7dj50Zcyruel9wgLhVbNIDV7jmnYglUbydSjZ9TPOfM8Zp
12 | 7bT2rrIl6DK4tnnjdB9OOCRpSm8tOfPsUGSG3ivkheNU2P2lrdn7MM6L9kFiiyZQ
13 | n3ROlvoeyIA4MkoYDOwE26CmXqNQY8f/4eaKwRtaWdT1Iddv+vFAqWycoL0MD9vA
14 | PO7K2TKyVvzSIiGMCMCj2WHhW58871kwl517fMIB//8vqa8MqXRGzLJ/uHm7xHbJ
15 | NPJAac6JIjOZEI7GdLgPnNldE92VnralWokIc9GhZEkOxIIez4lf4XE2aYiGiVAi
16 | NAjrw0QMif+eV89z5B/k66RkjlkzCPPpxOMCAwEAAaNQME4wHQYDVR0OBBYEFHyh
17 | mn70KRaiZfDVFIP00JcDBZ9xMB8GA1UdIwQYMBaAFHyhmn70KRaiZfDVFIP00JcD
18 | BZ9xMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAFjL3MRC/UIT6PfV
19 | 49DxZi06yyJMdcV+Q4eq63PScUIKO+MH2QvTd4Pxs6ZKPPfDVNZ5Wu8B/EvydIp6
20 | ohMKtEXbi6zJOVi11BZy8+DJYSLoHU45ZpmQM6tmbRWu9x4h87uuB3j9dQdewpk3
21 | z38t/CotfkOz/xW+bAnK0xcq+9ejt/RJK/HTj03W7TfE+Vg4DoXC/QDOFyda8c15
22 | 9kkXqnil7QlBo4Eh0dFlDuYTEHVJNTaBoYZXS38MlthPuvWnR8BSMmGpejIvT2R9
23 | cTDjQYenY2FSgRZQwhlFIVLSQh/2MSJmyDm+N2puUJvExTx0QYDzkGXMxZ5t5GWT
24 | PR+M1Yk=
25 | -----END CERTIFICATE-----
26 |
--------------------------------------------------------------------------------
/SSL_Priv.pem:
--------------------------------------------------------------------------------
1 | -----BEGIN RSA PRIVATE KEY-----
2 | MIICXQIBAAKBgQDoamwwk2XO7zmBoot4SQ8Gq6wP504lolg3hITfW7Q2Eu+NpDLe
3 | ItM+NsnbbMn89Zbul1MYD+UIMBa+w5R7bBnFPD7bGqfsLAs5czxLranIEg0ri9L1
4 | gBHWKRCSSSWjXBvESB6jE1k28DV4/j7+q7Ka9W8bNDI1/eRVAs3m7v1WYwIDAQAB
5 | AoGAEa2upw8/KjtmG2c6xp6ABxjd0KPefNxZa3eoB7lY/tf34sU/nUf223+dYRRo
6 | VNZ1cZaPGoBzAmluAXqs+6pgV0w5RYBR9pbTahD+VwM1PTOjawl68Hc45y3h3PTz
7 | qYMWeLM34JTgndzOjgUF7FymEP2Ecu26FGzw7On4XU06X/ECQQD8rvu9gY53Bs0X
8 | qBOS0VDqc5qShYINxq+oi6+Jk7HTgL573eFxVeMzflHs0XJrc4d9kYv6k154rdE0
9 | BTuZfSeZAkEA63dW4r/RDyS7At6hgbHgpGjmOg+sv9G6kRqxnKs8upLravVuJM02
10 | mQDAe/2Tg4ywyX7xQD6l3CMpbhHi3mA7WwJAAq38X3MbRqnczO5sXrc3i3T0Y69k
11 | xK6huEDa+LOHRD3uRzQAKwqFIUuqpL9H3lnYSv2bJWogq1j0if+wNR19qQJBANBW
12 | HPgvg8gEVbsqRHg+bGbLsbh5mf12kb5FghT+pZLm34kZcsT5FW+27JhIOrbQSrNd
13 | sBOJ2rK2IbgT90mOl7UCQQC3UsS2SJt6cFLBWvjS5Q8ZEcGX/Jpe/pgKqtSHWSGR
14 | t3X69kDEe9lpounth65WSq6t76GwCRRWNnuQcCbwwv39
15 | -----END RSA PRIVATE KEY-----
16 |
--------------------------------------------------------------------------------
/SSL_Pub.der:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/SSL_Pub.der
--------------------------------------------------------------------------------
/SSL_Pub.pem:
--------------------------------------------------------------------------------
1 | -----BEGIN CERTIFICATE-----
2 | MIIDPjCCAiYCAQEwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAkZSMRYwFAYD
3 | VQQIDA1JbGUtZGUtRnJhbmNlMQ4wDAYDVQQHDAVQYXJpczEeMBwGA1UECgwVRG91
4 | YmFuZ28gVGVsZWNvbSBFVVJMMQ0wCwYDVQQLDARWb0lQMR4wHAYDVQQDDBVEb3Vi
5 | YW5nbyBUZWxlY29tIEVVUkwxIDAeBgkqhkiG9w0BCQEWEWluZm9AZG91YmFuZ28u
6 | b3JnMB4XDTE1MDMwNDAxNTUxMloXDTI1MDMwMTAxNTUxMlowgaYxCzAJBgNVBAYT
7 | AkZSMRYwFAYDVQQIDA1JbGUtZGUtRnJhbmNlMQ4wDAYDVQQHDAVQYXJpczEWMBQG
8 | A1UECgwNRG91YmFuZ28gVGVzdDEdMBsGA1UECwwURG91YmFuZ28gVGVzdCAoVm9J
9 | UCkxFjAUBgNVBAMMDURvdWJhbmdvIFRlc3QxIDAeBgkqhkiG9w0BCQEWEWluZm9A
10 | ZG91YmFuZ28ub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoamwwk2XO
11 | 7zmBoot4SQ8Gq6wP504lolg3hITfW7Q2Eu+NpDLeItM+NsnbbMn89Zbul1MYD+UI
12 | MBa+w5R7bBnFPD7bGqfsLAs5czxLranIEg0ri9L1gBHWKRCSSSWjXBvESB6jE1k2
13 | 8DV4/j7+q7Ka9W8bNDI1/eRVAs3m7v1WYwIDAQABMA0GCSqGSIb3DQEBBQUAA4IB
14 | AQCK2ovrf0MVFnhXw+EZHFuBrBjguLGxitlnTqDswSmJnnoVhllI6TWSTANX9Yhe
15 | dxx0Z7mlYTxZ6dFW9JLvISHG/9uJghQQLGEzM1ZVb5sK8HKKoQFRW7plY8IUQqtk
16 | Zzh/OZ/nOnUR8mSi2ms9CcQZHskXCppgPgpSlUV+TJpH5MqxF8iwFzgDd1N1Buxc
17 | YDWhkiGi3vwx/7rv1yCwxcvxENcecQVfaCJNMOLzUP4wI6tHhrwj8+A5yTKZ6vRM
18 | TFu7QIdd61GRnAhleNpc7Tc1K0XjdbB6o5BneM6KGb2Aa59btb1HaBS5z2HC6ZgC
19 | GW8ZYgRxU9o+YONxhaK6mlcn
20 | -----END CERTIFICATE-----
21 |
--------------------------------------------------------------------------------
/Support_FAQ.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ## How to report issue? ##
4 | We receive tens of messages on our dev-groups and private mailboxes every day. Without a commercial license, we only provide a best-effort support on [opentelepresence group](http://groups.google.com/group/opentelepresence).
**We're happy to help you to fix your issues** but we'll not spend hours on them to understand what's wrong. If you want help, you **must**:
5 | * Provide clear technical description of the issue.
6 | * Change you _telepresence.cfg_ to use INFO debug level. See [here](Configuration_Debugging_the_system.md) for more information.
7 | * Attach the **full** logs to the message.
8 | * Provide information about the SVN revisions (both Doubango and TelePresence).
9 | If the report is about building issues:
10 | * Attach config.log files for both Doubango and TelePresence
11 | If the report is about video issues:
12 | * Attach results from http://www.speedtest.net/
13 | you _should_ also:
14 | * Provide the network (Wireshark) capture at the server-side
15 | * Provide the client logs.
16 |
17 | ## How to create self-signed SSL certificates? ##
18 | We'd recommend reading [this thread](https://groups.google.com/forum/#!topic/doubango/asAfP5ZCgdI).
19 |
20 | ## I see "error while loading shared libraries: XXX.so.y: cannot open shared object file: No such file or directory" when I run the server. How can I fix this? ##
21 | When a program is started the loader search for all dependencies (shared libraries) in a predefined list of folders. You're getting this error because the folder containing _XXX.so.y_ is not in the list. To fix the issue, run:
22 | ```
23 | # /!\IMPORTANT: change
24 | echo "" >> /etc/ld.so.conf.d/telepresence.conf
25 | ldconfig
26 | ```
27 | To find __:
28 | ```
29 | find / -name 'XXX.so.y'
30 | ```
31 |
32 |
33 | ## I see "Remote party requesting DTLS-DTLS (UDP/TLS/RTP/SAVPF) but this option is not enabled". How can I fix this ##
34 | DTLS-SRTP is required by some WebRTC implementations (e.g. Firefox). You MUST:
35 | 1. use a new OpenSSL version with support for DTLS-SRTP as explained [here](Support_BuildingSourceCode#Building_OpenSSL.md). Linux almost always comes with OpenSSL pre-installed which means building and installing OpenSSL by yourself will most likely duplicate it.
36 | 1. make sure you don't have more than one OpenSSL version installed (look for libssl).
37 | 1. rebuild TelePresence and make sure the "CONGRATULATIONS" message says that you have DTLS-SRTP enabled.
38 | 1. make sure you're using SSL certificates in your configuration (see [here](Configuration_Security.md) for more information). DTLS-SRTP requires at least a valid Public Key (could be self signed).
--------------------------------------------------------------------------------
/Support_Known_issues.md:
--------------------------------------------------------------------------------
1 | This is a short list with all **known issues** (to be fixed before the end of the beta phase).
2 | 1. The audio quality on the recorded files is not as good as we expect. This looks like an issue on the PTS and DTS.
3 | 1. Sometimes, the recorded file cannot be played. **Fixed in [r118](https://code.google.com/p/telepresence/source/detail?r=118)**.
4 | 1. Mixed video looks stretched when the SIP clients is a mobile in portrait (e.g. iDoubs and IMSDroid). No issue when device is in landscape or using our WebRTC demo client. **Fixed in [r118](https://code.google.com/p/telepresence/source/detail?r=118)**.
5 | 1. The algorithm to detect the current speaker and listeners is buggy.
6 | 1. 3D (spatial) mixed audio quality is not as good as we expect.
7 | 1. Mixer fails to negotiate H.263. **Fixed in [r118](https://code.google.com/p/telepresence/source/detail?r=118)**.
8 | 1. "error while loading shared libraries: libtinySAK.so.0: cannot open shared object file: No such file or directory". You can find a temporary workaround at https://groups.google.com/forum/#!topic/opentelepresence/qR7OdJGAcAE. **Fixed in [r118](https://code.google.com/p/telepresence/source/detail?r=118)**.
--------------------------------------------------------------------------------
/Support_Roadmap.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | # Roadmap #
4 | 1. Fix [known issues](Support_Known_issues.md)
5 | 1. Adds support for more video layouts/patterns (Only Hangout-like pattern is supported for now)
6 | 1. Adds support for live slides sharing (or any other format). **Fixed in [r118](https://code.google.com/p/telepresence/source/detail?r=118)**.
7 | 1. Adds support for desktop sharing
8 | 1. Adds support for whiteboard
9 | 1. Allows setting bridge manager
10 | 1. Adds support for keepAlive (SIP OPTIONS)
11 | 1. Allows interconnection with Skype, Lync, Cisco....
12 | 1. JSON API to get information on the call (participants, statues, positions, volume level...) and manage the bridge (invite user, mute participant, kick off...). **Started in [r118](https://code.google.com/p/telepresence/source/detail?r=118). Check [here](Technical_Call_session_management.md)**.
13 | 1. Add a beep sound when new participant join
14 | 1. Add support for file broadcasting (e.g. .mp4 or .webm).
--------------------------------------------------------------------------------
/Support_Testing_the_system.md:
--------------------------------------------------------------------------------
1 | This section explains how to test the Telepresence system.
2 |
3 | As already explained on this document, any SIP client can be used to connect to the Telepresence system but we highly recommend using our WebRTC client. The WebRTC client is hosted at [http://conf-call.org/](http://conf-call.org/).
4 |
5 | Few steps to get started (we assume you have successfully built and installed the system):
6 | 1. Build, install and run the system as explained [here](Support_BuildingSourceCode.md).
7 | 1. Change (in your configuration file) the _debug level_ value to _INFO_ as explained [here](Configuration_Debugging_the_system.md) (not required).
8 | 1. The default configuration already has a WebSocket transport listening on port 20060 but the IP address is automatically retrieve at the startup (because of the star (`*`) in the transport configuration entry). To bind to a specific IP address, change your settings as explained [here](Configuration_SIP_network_transports.md).
9 | 1. Starts the system and check the console logs to be sure that all is ok. The logs also show which IP addresses and port are used for each protocol (WS, WSS, TCP, TLS and UDP).
10 | 1. Go to [http://conf-call.org/settings.htm](http://conf-call.org/settings.htm) and enter your Private Identity and the WebSocket connection URL. The Private Identity is a SIP authentication name (**without special characters or SPACEs**). The connection URL must be the same the transport entry defined in the configuration file (the star (`*`) after the protocol name -scheme- must be replaced with a valid IP address or host name). Save your settings.
11 | 1. Go back to the home page, enter a bridge identifier (any number would work) and press **"join"** button. If a bridge with this identifier doesn’t exist then, it will be created automatically. Any person calling the same identifier will be part of the conference. No pin code is required unless one is defined in the configuration file.
12 |
13 | * To report issues: [https://groups.google.com/group/opentelepresence](https://groups.google.com/group/opentelepresence).
14 | * For issues related to bandwidth, please attach results from [http://www.speedtest.net/](http://www.speedtest.net/).
--------------------------------------------------------------------------------
/Support_Tips.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ## 1. Lowering CPU ##
4 | ### 1.1 Avoid audio resampling ###
5 | To avoid audio resampling, the SIP clients connecting to a bridge have to use a codec with the sample rate, channels and bits per sample as the ["pivot settings"](Technical_Audio_mixer_design.md). For more information, check [here](Technical_Audio_mixer_design.md).
6 | tip: In you configuration file, enable codecs with same settings as the pivot.
7 |
8 | ### 1.2 Only record sessions if needed ###
9 | Do not enable recording if it’s not important to you or use `*`.avi container which consume less CPU than `*`.mp4 (because of AAC encoder from [libfaac](Support_BuildingSourceCode#Building_libfaac.md)).
10 |
11 | ### 1.3 Use common video codec ###
12 | All SIP clients with the same video codec will share a single encoder. Try to use common video codec for all clients. For example, if you have two clients, A and B, with A supporting both H.264 and VP8 and B only H.264 then, you should make sure that A will offer H.264 with highest priority. For more information, check [here](Technical_Video_mixer_design#Encoders_and_decoders.md).
13 | tip: In your configuration file, enable a single video codec if you cannot control the SIP clients.
14 |
15 | ### 1.4 Use 2d audio mixing ###
16 | Enable 2D audio mixing instead of 3D.
17 |
18 | ### 1.5 Lower mixed video size and fps ###
19 | If you have a weak CPU then, consider using a reasonable video size (e.g. VGA) and fps ([- 30](15.md)).
20 |
21 | ### 1.5 Multi-threading and ASM ###
22 | Make sure to enable [YASM](Support_BuildingSourceCode#Building_YASM.md) and pthread when building [FFmpeg](Support_BuildingSourceCode#Building_FFmpeg.md), [x264](Support_BuildingSourceCode#Building_x264.md) and [VP8](Support_BuildingSourceCode#Building_libvpx.md).
23 |
24 | ## 2. Lowering bandwidth ##
25 | * Use "slow" motion rank (see [here](Configuration_Video#Bandwidth_and_congestion_control.md))
26 | * Use small mixed video size (see [here](Configuration_Video#Output_mixed_size.md))
27 | * Set the maximum upload and download bandwidth (see [here](Configuration_Video#Bandwidth_and_congestion_control.md))
28 | * Use small video frame rate (see [here](Configuration_Video#Bandwidth_and_congestion_control.md))
29 |
30 | tip: To test your available bandwidth, we recommend http://www.speedtest.net/.
31 | tip: To check bandwidth usage, we recommend iftop.
32 |
33 | ## 3. Improving audio quality ##
34 | * Use [Opus](Support_BuildingSourceCode#Building_libopus.md) (or G.722) audio codec if supported by the SIP clients (see [here](Configuration_Audio_Video_codecs.md)).
35 | * Avoid audio up-sampling and down-sampling (see [here](Technical_Audio_mixer_design.md)).
36 | * If the ["pivot settings"](Technical_Audio_mixer_design.md) use a sample rate (SR) equal to S then, try to use codecs with a SR equal to "S << n" or "S >> n".
37 |
38 | ## 4. Improving video quality ##
39 | * Use Google Chrome as SIP client (check our WebRTC demo client at [http://conf-call.org/](http://conf-call.org/)).
40 | * Enable "Zero-Artifacts" feature (see [here](Technical_Video_quality#Zero-artifacts.md) and [here](Configuration_Video#Zero-artifacts.md))
41 | * Use a client supporting something close to 16/9 video size to avoid stretching issues
42 | * Avoid video up-sampling and down-sampling
43 |
44 | ## 5. Lowering recorded video file size ##
45 |
46 | _--This section intentionally left blank--_
--------------------------------------------------------------------------------
/Technical_Audio_mixer_design.md:
--------------------------------------------------------------------------------
1 | The audio mixer is part of the [MCU](http://en.wikipedia.org/wiki/Multipoint_control_unit) engine.
2 |
3 | The audio mixer supports mixing several streams with different settings (rate, channels, bits per sample or ptime). For example, a bridge can host a conference with two endpoints, one using g711 (8khz, mono, 20ms) and the other using opus (48khz, stereo, 30ms). As you may expect, it’s not technically possible to mix two streams with different settings without resampling.
4 |
5 | In the audio mixer there is a notion of "pivot settings". "pivot settings" is the audio parameters to which any stream is resampled to, before mixing. The pivot settings are defined using the configuration file as explained [here](Configuration_Audio#Pivot_settings.md).
6 |
7 | The Doubango framework use [libspeexdsp](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_libspeex_and_libspeexdsp) for the resampling while the [MCU](http://en.wikipedia.org/wiki/Multipoint_control_unit) uses libswresample (from FFmpeg). Both libraries are required.
8 | It’s very important to understand the notion of "pivot settings" because using wrong values could lead to poor audio quality and high CPU usage.
9 |
10 |
11 | 
12 | Figure 1: Audio resampling
13 |
14 | From the above figure, you can easily see that the incoming audio samples from an endpoint to the MCU could be resampled up to two times if your pivot and negotiated codec settings mismatch. To minimize the number of audio resampling processes your codec settings have to be as close as possible to those used as pivot. If the settings (pivot, codecs) match, then no resampling will be done.
15 |
16 | In this beta version, we support 2d and 3d mixing types. The type of mixing is defined using the configuration file as explained [here](Configuration_Audio#Pivot_settings.md).
17 |
18 | The 2d mixing is linear (monophonic or stereophonic) and very basic. No additional thirdparties library is required for this.
19 |
20 | The 3d mixing is stereoscopic (spatial) and requires [OpenAL Soft](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_OpenAL_Soft).
--------------------------------------------------------------------------------
/Technical_Bandwidth_management_and_congestion_control.md:
--------------------------------------------------------------------------------
1 | In this current beta version we only focus on video bandwidth.
2 |
3 | The upload and download video bandwidth settings have to be defined using the configuration file as explained [here](Configuration_Video#Bandwidth_and_congestion_control.md). The maximum download bandwidth is signaled to the remote endpoints using the SDP (b=AS:X attribute as per RFC [3556](http://tools.ietf.org/html/rfc3556)) and **RTCP-REMB** packets (as per [draft-alvestrand-rmcat-remb-02](http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-02)). In this beta version, **RTCP-TMMBN** ([RFC 5104](http://tools.ietf.org/html/rfc5104)) packets are deserialized but not processed by the system.
4 |
5 | The congestion control manager could be enabled using the configuration file as explained [here](Configuration_Video#Bandwidth_and_congestion_control.md). In this beta version, [draft-alvestrand-rtcweb-congestion-03](http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03) is not fully implemented yet and we’re using our own algorithms to compute the bandwidth usage. The computed maximum bandwidth (periodically) when the congestion control is enabled will never be higher than the maximum allowed values defined in your configuration file (this is kind of safe guard).
--------------------------------------------------------------------------------
/Technical_Call_session_management.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | A call session is managed using **SIP INFO** messages with **JSON** content. For now only muting/unmuting the session is supported. Next versions will add support for ejecting a participant, getting the list of participants, getting the call state (packet loss, RTT, audio/video quality, etc etc
4 | ## Muting/unmuting ##
5 | The MCU could detect that a session is muted based on the RTP packets but it’s highly recommended to also send a **SIP INFO** message for confirmation. For audio-only sessions, muting a session without sending a **SIP INFO** could be interpreted as a crash or network issue which automatically disconnects the call.
6 | When the _“hangout”_ video pattern is selected the MCU renders the speaker's video with the highest quality and size. Detecting a speaker could be problematic when the participants are in a noisy environment. Manually muting/unmuting your session is a way to avoid such issues.
7 | JSON content:
8 |
9 |
10 | Field name |
11 | Field value |
12 | Type |
13 | Availability |
14 |
15 |
16 | action |
17 | “req_call_mute” |
18 | String |
19 | Mandatory |
20 |
21 |
22 | enabled |
23 | < user defined > |
24 | Boolean |
25 | Mandatory |
26 |
27 |
28 |
29 | ## Ejecting a participant ##
30 | _--This section intentionally left blank--_
31 |
32 | ## Getting the list of participants ##
33 | _--This section intentionally left blank--_
34 |
35 | ## Getting the call state ##
36 | _--This section intentionally left blank--_
--------------------------------------------------------------------------------
/Technical_NAT_and_firewall_traversal.md:
--------------------------------------------------------------------------------
1 | This section explains how to tackle NAT and firewall traversal issues.
2 |
3 |
4 |
5 | # Symmetric RTP #
6 | This feature is enabled or disabled as explained [here](Configuration_NAT_Firewall_traversal.md).
7 |
8 | The Telepresence system fully supports [RFC 4961](http://tools.ietf.org/html/rfc4961).
9 |
10 | An RTP/RTCP stream is symmetric if the same port is used to send and receive packets. This helps for NAT and firewall traversal as the outgoing packets open a pinhole for the ongoing ones.
11 |
12 | The local/outgoing stream (MCU → endpoints) is always symmetric.
13 |
14 | If both parties (remote and local) have successfully negotiated ICE candidates then, none will be forced to use symmetric RTP/RTCP.
15 |
16 | Let’s imagine your Telepresence instance is on a public network and the SIP client/endpoint on private network:
17 | 1. Telepresence: Public IP address is **1.1.1.1**
18 | 1. Client: Private IP address is **2.2.2.2** and public IP address is 1.1.1.2
19 | 1. The SDP from the client to the Telepresence system will contain client’s private IP address (**2.2.2.2**) which is not reachable
20 | 1. The RTP/RTCP packets from the client to the server will be received with source IP address equal to the client’s public IP address (**1.1.1.2**)
21 | 1. If [rtp-symetric-enabled](Configuration_NAT_Firewall_traversal.md) option is used then, the Telepresence system will send RTP/RTCP packets to **1.1.1.2** (learnt from the received packets) instead of **2.2.2.2** which is private and unreachable.
22 |
23 | # ICE #
24 | This feature is enabled or disabled as explained [here](Configuration_NAT_Firewall_traversal.md).
25 |
26 | The Telepresence system fully supports [RFC 5245](http://tools.ietf.org/html/rfc5245).
27 |
28 | ICE is negotiated only if this feature is enabled and incoming SDP (SIP endpoint → MCU) contains candidates.
29 |
30 | **ICE is mandatory for WebRTC endpoints**.
31 |
32 | # RTCP-MUX #
33 | This feature is enabled or disabled as explained [here](Configuration_NAT_Firewall_traversal.md).
34 |
35 | The Telepresence system fully supports [RFC 5761](http://tools.ietf.org/html/rfc5761).
36 |
37 | RTCP-MUX is used to minimize the number of ports and help for NAT traversal and administration.
--------------------------------------------------------------------------------
/Technical_Protecting_a_bridge_with_password.md:
--------------------------------------------------------------------------------
1 | This feature is configured as explained [here](Configuration_Bridge_configuration.md).
2 |
3 | There are two ways for a SIP client to authenticate to a protected bridge: DTMF or **TP-BridgePin** SIP header. If authentication fails, a SIP 403 response will be returned with a short description.
4 |
5 | The **DTMF** method doesn’t require changing your SIP client but is not supported yet in this beta version (on the roadmap for the release version). The second method (using the SIP header) requires some modifications on you SIP client to include this new header. If you are using our [WebRTC SIP telepresence demo client](http://conf-call.org/) then, no modification is needed.
--------------------------------------------------------------------------------
/Technical_Recording_conference_to_a_file.md:
--------------------------------------------------------------------------------
1 | This feature is configured as explained [here](Configuration_Recording_conference_to_a_file.md).
2 |
3 | We support almost any container depending on how you built _FFmpeg_ and which codecs are enabled. Right now we recommend only **.avi** and **.mp4** as they are fully tested. **.mkv** and **.webm** will also work but not fully tested yet. The audio and video mixing is done using _libavformat_ from FFmpeg.
4 |
5 | * _**.avi**_ (recommended) requires FFmpeg with **MPEG4** video codec and **AC3** audio codec
6 | * _**.mp4**_ requires FFmpeg with **H.264** ([libx264](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_x264) thirdparty library) video codec and AAC audio codec. There is a built-in experimental **AAC** codec in FFmpeg but the code is intentionally designed to not accept such codec because of random crashes. For AAC audio codec, you’ll need to build FFmpeg with [libfaac](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_libfaac) or any other [third-party AAC library](http://ffmpeg.org/trac/ffmpeg/wiki/AACEncodingGuide). Please note that all AAC libraries are not free.
7 | * _**.avi**_ is recommended instead of **.mp4** for the simple reason that the first one consume less CPU.
8 | The output file will have the bridge identifier as name and container type as extension, e.g. _+336000000.avi_. The file is locked and invalid until the last user quit the bridge.
9 |
10 | We highly recommend using [VLC](http://www.videolan.org/vlc/index.html) to play the output files.
--------------------------------------------------------------------------------
/Technical_SA_versus_AS_modes.md:
--------------------------------------------------------------------------------
1 | The server supports two modes: **SA** (stand-alone) and **AS** (application server). These modes are not exclusive and no special configuration is needed.
2 |
3 | The **SA** mode allows any SIP client to directly connect to the system without any intermediate node. If the client requires to be registered then, you can enable this option as explained [here](Configuration_SIP_registration.md) because the SIP registrar mode is OFF by default.
4 |
5 | The **AS** mode is useful if you already have your own SIP network/server and want to integrate the Telepresence system as an application server. This mode has been tested against [Asterisk](http://www.asterisk.org/), [reSIProcate](http://www.resiprocate.org/Main_Page), [openSIPS](http://www.opensips.org/) and [Kamailio](http://www.kamailio.org/w/). This is as easy as forwarding any INVITE (based on some criterias, e.g. _[name equal to @conf-call.org](domain.md)_) received by the SIP registrar to the Telepresence system.
--------------------------------------------------------------------------------
/Technical_Security.md:
--------------------------------------------------------------------------------
1 | This section explains how to secure both signaling and media plans.
2 |
3 |
4 |
5 | # Signaling #
6 | Two secure signaling protocols are supported: **TLS** and **WSS**. **WSS** is WebSocket secured using **TLS**. For more information on how to enable these transport protocols using the configuration file, please refer to [this wiki page](Configuration_SIP_network_transports.md).
7 |
8 | Both transports require [OpenSSL](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_OpenSSL) which have to be enabled when building the Doubango framework only.
9 |
10 | More information on how to configure the SSL certificates could be found [here](Configuration_Security.md).
11 |
12 | # Media #
13 | Both **SRTP-SDES** ([RFC 4568](http://tools.ietf.org/html/rfc4568)) and **SRTP-DTLS** ([RFC 5763](http://tools.ietf.org/html/rfc5763), [RFC 5764](http://tools.ietf.org/html/rfc5764)) are supported.
14 |
15 | Check [here](Configuration_Security.md) for more information on how these features have to be configured.
16 |
17 | _--This section intentionally left blank--_
--------------------------------------------------------------------------------
/Technical_Stereoscopic_spatial_3D_audio.md:
--------------------------------------------------------------------------------
1 | Our 3D audio mixer is based on [OpenAL Soft](http://kcat.strangesoft.net/openal.html) and supports up to 256 sources. Your OpenAL version must be at least 1.15.1 and implements [ALC\_SOFT\_loopback](http://kcat.strangesoft.net/openal-extensions/SOFT_loopback.txt) extension.
2 |
3 | To have a 3D audio, each SIP client should signal its position in the virtual room. The signaling is done using two SIP headers: TP-AudioPosition and TP-AudioVelocity. These two SIP headers must contain an array of three floating numbers.
4 | ```
5 | TP-AudioPosition: [0.0f, 0.0f, 0.0f]
6 | TP-AudioVelocity: [0.0f, 0.0f, 0.0f]
7 | ```
8 | Using our [WebRTC TelePresence client](http://conf-call.org/contact.htm), the 3D settings could be defined at [http://conf-call.org/settings.htm](http://conf-call.org/settings.htm).
9 |
10 | From OpenAL documentation, "AL_POSITION specifies the current location of the object in the world coordinate system. Any 3-tuple of valid float values is allowed. Implementation behavior on encountering NaN and infinity is not defined. The object position is always defined in the world coordinate system."
11 |
12 | From OpenAL documentation, “AL_VELOCITY specifies the current velocity (speed and direction) of the object, in the world coordinate system. Any 3-tuple of valid float/double values is allowed. The object AL_VELOCITY does not affect the source's position. OpenAL does not calculate the velocity from subsequent position updates, nor does it adjust the position over time based on the specified velocity. Any such calculation is left to the application. For the purposes of sound processing, position and velocity are independent parameters affecting different aspects of the sounds.”
--------------------------------------------------------------------------------
/Technical_Video_mixer_design.md:
--------------------------------------------------------------------------------
1 | The video mixing and scaling is completely managed using FFmpeg. In this beta version, only 2D mixing is supported. We’ll consider support for [libyuv](https://code.google.com/p/libyuv/) in the next versions.
2 |
3 |
4 |
5 | # Encoders and decoders #
6 | To minimize CPU utilization, all endpoints with the same video codec use the same encoder but different decoders. For example, if you have 7 endpoints using VP8 codec then, the MCU will have 1 encoder and 7 decoders. Using a single encoder gives better CPU performances but more bandwidth than what’s needed because if one endpoint requests an IDR then, the prediction chain is restarted for all other peers.
7 |
8 | # Overlays #
9 | The overlays are configured as explained [here](Configuration_Video#Overlays.md).
10 |
11 | The mixed video contains many overlays displayed using [FFmpeg filters](http://www.ffmpeg.org/ffmpeg-filters.html). There are two kinds of overlays: texts and images. The text overlays use [drawtext filter](http://www.ffmpeg.org/ffmpeg-filters.html#drawtext-1) which requires [libfreetype](https://code.google.com/p/telepresence/wiki/Support_BuildingSourceCode#Building_libfreetype) to be enabled when building FFmpeg. The image overlays (watermarks) use [movie filter](http://www.ffmpeg.org/ffmpeg-filters.html#movie-1) and accept any PNG or JPEG file as input. JPEG images are natively supported by FFmpeg (thanks to MPEG4) while PNG requires [zlib](http://zlib.net/) to be enabled.
12 |
13 | The configuration file could be used to define custom font types for the text overlays. The font types must be [TrueType](https://en.wikipedia.org/wiki/TrueType)-compatible. The default fonts come from [ftp://ftp.gnu.org/pub/gnu/freefont](ftp://ftp.gnu.org/pub/gnu/freefont).
--------------------------------------------------------------------------------
/Technical_Video_quality.md:
--------------------------------------------------------------------------------
1 | This section explains how to make sure to have a good video quality when using the system.
2 |
3 |
4 |
5 | # Packet loss recovery #
6 | This feature requires the jitter buffer to be enabled.
7 | When a RTP packet is lost then, we request the remote party to send it again using RTCP-NACKs as per [RFC 5104](http://tools.ietf.org/html/rfc5104). Support for this feature is indicated using the SDP (attribute _a=rtcp-fb: `*` nack_). If the remote peer cannot honor the request in a reasonable delay then, the packet is considered as definitely lost. If we’re very lucky then, losing a packet would just introduce artifacts. Otherwise (not lucky), this will break the prediction chain and any attempt to decode the video would fail until the next IDR frame. Enabling zero-artifacts feature would fix artifact and prediction issues.
8 | Increasing the internal RTP buffer size as explained [here](Configuration_RTP_buffer_size.md) could also help to lower packet loss.
9 |
10 | # Jitter buffer #
11 | The video jitter buffer could be enabled as explained [here](Configuration_Video#Jitter_Buffer.md).
12 | Enabling the video jitter buffer introduce small delay (~100ms) but worth it. Buffering the video packets allows requesting missing packets using RTCP-NACK ([RFC 5104](http://tools.ietf.org/html/rfc5104)) and reordering them based on the RTP sequence numbers. It’s also up to the jitter buffer to consume any delay or burst to have smooth video according to the frame rate. The video frame rate is negotiated using the SDP but this value will be updated based on the RTP timestamps.
13 |
14 | # Zero-artifacts #
15 | This feature is enabled or disabled as explained [here](Configuration_Video#Zero-artifacts.md).
16 | A video stream contains artifacts when some RTP packets are lost. The MCU try its best to avoid packet loss (see [here](Technical_Video_quality#Packet_loss_recovery.md)) but sometimes it fails and this leads to visual artifacts. As the video streams are mixed then, the artifacts will be propagated to all endpoints. When ‘zero-artifact’ is enabled then, the MCU pauses the rendering on the stream and sends RTCP-FIR ([RFC 5104](http://tools.ietf.org/html/rfc5104)) to request new IDR frame to repair the prediction chain. Only the stream with the missing RTP packets is paused until the next IDR frame is received. Support for RTCP-FIR is signaled to the remote endpoints using the SDP (attribute _a=rtcp-fb: `*` fir_). The MCU sends IDR frames when it receives RTCP-FIR or RTCP-PLI from one of the endpoints.
17 |
18 | # AVPF tail length #
19 | As already explained, RTCP-NACKs are used to ask a peer to send a packet again. In order to be able to honor these requests we need to save the outgoing RTP packets in a queue. The AVPF tail length option defines the minimum and maximum lengths for the queue. The higher these values are the better will be the video quality. The default queue length will be equal to the minimum value and it’s up to the MCU to increase this value depending on the number of unrecoverable packet loss. The final value will be at most equal to the maximum defined in the configuration file. Unrecoverable packet loss occurs when the MCU receives an RTCP-NACK for an already removed sequence number (very common when network RTT is very high or bandwidth very low).
20 | Setting the AVPF tail length (min, max) is done as explained [here](Configuration_AVPF_tail_length.md).
21 |
22 | # FEC (Forward Error Correction) #
23 | --This section intentionally left blank--
24 |
25 | # RED (Redundant video data) #
26 | --This section intentionally left blank--
--------------------------------------------------------------------------------
/autogen.sh:
--------------------------------------------------------------------------------
1 | echo libtoolize
2 | if [ `(uname -s) 2>/dev/null` == 'Darwin' ]
3 | then
4 | glibtoolize --copy --force
5 | else
6 | libtoolize --copy --force
7 | fi
8 |
9 | echo "aclocal"
10 | aclocal
11 |
12 | echo "autoheader"
13 | autoheader
14 |
15 | echo "create NEWS, README, AUTHORS and ChangeLog"
16 | touch NEWS README AUTHORS ChangeLog
17 |
18 | echo "autoreconf"
19 | autoreconf -i
20 |
21 | echo "automake"
22 | automake -a
--------------------------------------------------------------------------------
/documentation/technical-guide.doc:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/documentation/technical-guide.doc
--------------------------------------------------------------------------------
/documentation/technical-guide.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/documentation/technical-guide.pdf
--------------------------------------------------------------------------------
/fonts/truetype/freefont/FreeMonoBold.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/fonts/truetype/freefont/FreeMonoBold.ttf
--------------------------------------------------------------------------------
/fonts/truetype/freefont/FreeSerif.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/fonts/truetype/freefont/FreeSerif.ttf
--------------------------------------------------------------------------------
/fonts/truetype/freefont/INSTALL:
--------------------------------------------------------------------------------
1 | Installing GNU FreeFont
2 | =======================
3 |
4 | GNU FreeFont can be used in any modern operating system.
5 |
6 | This document explains how to install FreeFont on some common systems.
7 |
8 | UNIX/GNU/Linux/BSD Systems
9 | --------------------------
10 |
11 | FreeFont works with any system using the free font rasterizer FreeType
12 | . Some features such as glyph substitution and
13 | positioning may be handled by the text layout library
14 | Pango .
15 |
16 | Most recent systems using FreeType2 and Pango handle OpenType fonts well,
17 | but on older systems TrueType may perform better.
18 |
19 | * Debian GNU/Linux
20 |
21 | Users of Debian GNU/Linux system will probably want to use the Debian package,
22 | named 'ttf-freefont', available from the Debian Linux site.
23 |
24 | Install the fonts by issuing the command
25 | apt-get install ttf-freefont
26 |
27 |
28 | * KDE local installation
29 |
30 | Users of KDE can install .ttf files on a per-user basis using the KDE
31 | Control Center module "kcmfontinst", which may appear in the menu as
32 |
33 | Settings -> System Administration -> Font Installer
34 |
35 | This is especially helpful for developers and testers.
36 |
37 |
38 | * Generic X Window systems
39 |
40 | 1) Fetch the freefont-ttf.tar.gz package with Free UCS outline fonts
41 | in the TrueType format.
42 |
43 | 2) Unpack TrueType fonts into a suitable directory,
44 | e.g. /usr/local/share/fonts/default/TrueType/
45 |
46 | 3) If you have chosen any other directory, make sure the directory you
47 | used to install the fonts is listed in the path searched by the X
48 | Font Server by editing the config file in /etc/X11/.
49 |
50 | In some systems, you list the directory in the item "catalogue="
51 | in the file /etc/X11/fs/config.
52 |
53 | 4) Run ttmkfdir in the directory where you unpacked the fonts.
54 |
55 |
56 | Microsoft Windows 95/98/NT/2000/XP; Vista/7
57 | -------------------------------------------
58 |
59 | Note that in at least Windows 7, Vista, XP and 2000, the TrueType versions
60 | perform much better than, and are recommended over, the OpenType ones.
61 |
62 | For good font smoothing in Windows, Microsoft ClearType must be enabled.
63 | The native Windows web browser must be used to install, enable, and configure
64 | ClearType. A web search for "ClearType Tuner" will find the proper web pages.
65 | Recent versions of the browser raise a security block (a yellow bar at the
66 | top of the window), which you must act upon to allow installation. A
67 | checkbox in the window turns ClearType on (in Win-speek, "Turn on ClearType").
68 | The change happens immediately.
69 |
70 | * Vista, Windows 7:
71 | 1) From the Start menu, open Control Panels
72 | 2) Drag-n-drop font files onto Fonts control panel
73 | You may get a dialog saying
74 | "Windows needs your permission to continue"
75 | a) Click Continue
76 |
77 | * 95/98/NT:
78 | The font installation is similar to Vista.
79 |
80 | In order to use OpenType, users of Windows 95, 98 and NT 4.0 can
81 | install Adobe's 'Type Manager Light', which may be obtained from
82 | the Adobe web site.
83 |
84 | Otherwise, use the TrueType versions.
85 |
86 | Apple Mac OS X
87 | --------------
88 |
89 | Support for OpenType on MacOS X started with OS 10.4, and has been improved
90 | gradually in later versions.
91 |
92 | Installing on Mac OS X consists of moving the font files to either
93 | /Library/Fonts/ or ~/Library/Fonts/
94 | depending on whether they should be available to all users on your system
95 | or just to your own user.
96 |
97 | --------------------------------------------------------------------------
98 | $Id: INSTALL,v 1.11 2011-06-12 07:14:12 Stevan_White Exp $
99 |
--------------------------------------------------------------------------------
/images/audio_mixer_resampler.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/images/audio_mixer_resampler.png
--------------------------------------------------------------------------------
/images/logo.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/images/logo.jpg
--------------------------------------------------------------------------------
/images/logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/images/logo.png
--------------------------------------------------------------------------------
/images/logo35x34.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/images/logo35x34.jpg
--------------------------------------------------------------------------------
/images/presentation_sharing.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DoubangoTelecom/telepresence/8442ad7948081d4019e973bbe4588365a38714d9/images/presentation_sharing.png
--------------------------------------------------------------------------------
/include/OpenTelepresenceAPI.h:
--------------------------------------------------------------------------------
1 | /*
2 | * Copyright (C) 2013 Mamadou DIOP
3 | * Copyright (C) 2013 Doubango Telecom
4 | * License: GPLv3
5 | * This file is part of the open source SIP TelePresence system
6 | */
7 | #ifndef OPENTELEPRESENCE_API_H
8 | #define OPENTELEPRESENCE_API_H
9 |
10 | #include "OpenTelepresenceConfig.h"
11 | #include "opentelepresence/OTCodec.h"
12 | #include "opentelepresence/OTCodecAudio.h"
13 | #include "opentelepresence/OTCodecVideo.h"
14 | #include "opentelepresence/OTEngine.h"
15 | #include "opentelepresence/OTCommon.h"
16 | #include "opentelepresence/OTMixerMgrAudio.h"
17 | #include "opentelepresence/OTMixerMgr.h"
18 | #include "opentelepresence/OTMixerMgrVideo.h"
19 | #include "opentelepresence/OTObject.h"
20 | #include "opentelepresence/OTProxyPlugin.h"
21 | #include "opentelepresence/OTProxyPluginConsumer.h"
22 | #include "opentelepresence/OTProxyPluginConsumerAudio.h"
23 | #include "opentelepresence/OTProxyPluginConsumerVideo.h"
24 | #include "opentelepresence/OTProxyPluginMgr.h"
25 | #include "opentelepresence/OTProxyPluginProducer.h"
26 | #include "opentelepresence/OTProxyPluginProducerAudio.h"
27 |
28 |
29 | #endif /* OPENTELEPRESENCE_API_H */
30 |
--------------------------------------------------------------------------------
/include/opentelepresence/OTBridge.h:
--------------------------------------------------------------------------------
1 | /*
2 | * Copyright (C) 2013 Mamadou DIOP
3 | * Copyright (C) 2013 Doubango Telecom
4 | * License: GPLv3
5 | * This file is part of the open source SIP TelePresence system
6 | */
7 | #ifndef OPENTELEPRESENCE_BRIDGE_H
8 | #define OPENTELEPRESENCE_BRIDGE_H
9 |
10 | #include "OpenTelepresenceConfig.h"
11 |
12 | #include "opentelepresence/OTBridgeInfo.h"
13 | #include "opentelepresence/OTMixerMgrMgr.h"
14 | #include "opentelepresence/cfg/OTCfg.h"
15 |
16 | #include "tinydav/tdav.h"
17 |
18 | #include "tsk_mutex.h"
19 |
20 | #include
21 | #include