CDN 2.0¶
CDN based on WCS servers can be organized in two ways:
- Static CDN with pre-configured nodes. Changing CDN configuration requires restarting the server(s), because in this scheme the server(s) are the source of streams in the network. Such CDN 1.0 can be organized based on the load balancing function.
- Dynamic CDN with dynamically changing nodes. To include/exclude a node to/from such CDN, restarting of this node only is required.
Warning
CDN 1.0 is obsoleted and is strongly not recommended to use in production.
In this section we describe dynamic CDN.
Overview¶
Dynamic CDN operation basics¶
Distributed dynamic content delivery network (CDN) based on WCS operates as follows:
-
Upon startup of the server, a special CDN module starts. The module sends a request to the server specified as the CDN entry point to retrieve from it the list of other servers in the CDN and the list of available streams. If the entry point is not specified or if the specified server is not available, the module waits for a notification from another server in the CDN (for example, if that server was already added to the list of CDN servers on another server, or if it was specified as the entry point). As a result, each active CDN server at any given moment has the up-to-date list of all other CDN servers.
-
All interaction between nodes of CDN is performed via Websocket.
Server roles in CDN¶
A server can perform one of two roles
- Origin: works as a source of streams for other servers in CDN. Can distribute both streams published on it and streams fetched from other servers.
- Edge: can fetch streams from Origin servers, but do not distribute its own (local) streams to other servers.
Streams are not distributed forcefully. An Edge server fetches a specific stream from Origin only upon user request from a browser or a mobile application.
Operation flowchart¶
- The browser connects to the Origin server via the Websocket protocol and sends the
publishStream
command. - The browser captures the microphone and the camera and sends the WebRTC stream to the server.
- The second browser establishes a connection to the Edge3 server via Websocket and sends the
playStream
command. - The Edge3 server requests the stream from the Origin server.
- The Edge3 server receives the WebRTC stream.
- The second browser receives the WebRTC stream and plays this stream on the page.
Stream identification basics in CDN¶
A stream name is unique for every WCS server (and identifies the stream unambiguously), but not for the CDN in a whole. Hence, there are two limitations:
- If a stream is published on the server, and there is another stream with the same name on some other Origin server, the local (non-CDN) stream will be played on that server.
- When a CDN stream is played on the server, a stream with the same name cannot be published on that server. The same name can be used for publishing only when the playback stops and the pull agent is deleted after the activity checking timeout expires (by default it is 1 minute).
Configuration¶
Parameters of the settings file¶
To configure CDN, the following main settings in the flashphoner.properties file are used (see the complete list in the settings file description):
Parameter | Default value | Type | Description |
---|---|---|---|
cdn_enabled | false | Boolean | Enable/disable CDN |
cdn_ip | String | Server address in CDN | |
cdn_nodes_resolve_ip | false | Boolean | Resolve server names to IP addresses |
cdn_point_of_entry | String | Address of the server, the entry point to CDN for the given server. If the server is Origin, this parameter should not be set to this servers' IP address or hostname | |
cdn_port | 8084 | Int | Port number for CDN |
cdn_role | edge | String |
Role of the server in CDN: - origin - source of streams for other servers in CDN- edge - can receive streams from other servers
|
Configuration examples¶
Minimum configuration example¶
Two servers: Origin origin.flasphoner.com
and Edge edge.flasphoner.com
Origin settings:
Edge settings:
cdn_enabled=true
cdn_ip=edge.flashphoner.com
cdn_nodes_resolve_ip=true
cdn_point_of_entry=origin.flashponer.com
cdn_role=edge
Two Origin servers configuration example¶
Four servers: Origin1 origin1.flasphoner.com
, Origin2 origin2.flasphoner.com
and Edge1 edge1.flasphoner.com
, Edge2 edge2.flasphoner.com
Origin1 settings:
Origin2 settings:
cdn_enabled=true
cdn_ip=origin2.flashponer.com
cdn_point_of_entry=origin1.flashponer.com
cdn_nodes_resolve_ip=true
cdn_role=origin
Edge1 settings:
cdn_enabled=true
cdn_ip=edge1.flashphoner.com
cdn_point_of_entry=origin1.flashponer.com
cdn_nodes_resolve_ip=true
cdn_role=edge
Edge2 settings:
cdn_enabled=true
cdn_ip=edge2.flashphoner.com
cdn_point_of_entry=origin1.flashponer.com
cdn_nodes_resolve_ip=true
cdn_role=edge
Manage CDN using CLI¶
Obtaining information about the current status of CDN from the WCS command line is performed with the following commands:
Command | Description | Result example |
---|---|---|
show cdn-nodes
|
Displays the list of node servers in CDN: - ACTIVE - the server is running, responds to queries and/or sends notifications- PASSIVE - the server is stopped or unavailable
|
|
show cdn-routes
|
Shows the list of active streams in CDN |
Manage CDN using REST API¶
A REST-query should be HTTP/HTTPS POST request as follows:
- HTTP:
http://test.flashphoner.com:8081/rest-api/cdn/show_routes
- HTTPS:
https://test.flashphoner.com:8444/rest-api/cdn/show_routes
Where:
test.flashphoner.com
is the address of the WCS server8081
is the standard REST / HTTP port of the WCS server8444
is the standard HTTPS portrest-api
is the required part of the URL/cdn/show_routes
REST-method to use
REST methods and responses¶
/cdn/show_routes¶
Show active CDN routes
Request example¶
Response example¶
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"1-origin2.flashphoner.com-2": "stream1",
"0-origin2.flashphoner.com-0": "stream2",
"2-origin1.flashphoner.com-1": "stream1"
}
Return codes¶
Code | Reason |
---|---|
200 | OK |
500 | Internal error |
Parameters¶
Description | Example |
---|---|
Route identifier |
1-origin2.flashphoner.com-2
|
Stream name in CDN |
stream1
|
Removing stopped servers from CDN nodes list¶
By default, when server is stopped or unavailable, it will be displayed in CDN nodes list in PASSIVE
state until it will be started again or all the CDN will be stopped. The time interval may be set if necessary to remove inactive node from nodes list. This interval should be set in seconds using the following parameter in flashphoner.properties file, for example
In this case inactive nodes will be removed from CDN nodes list after 60 seconds of inactivity.
Choosing audio codecs for stream forwarding through CDN¶
Forwarding audio through CDN¶
When forwarding audio through CDN, a set of available codecs is formed with the
- codec used to publish stream (as preferred), and
- codecs supported on Origin and Edge servers (
codecs
setting in flashphoner.properties file)
excluding codecs listed in codecs_exclude_cdn
setting on Edge.
By default, if AAC is not excluded, the following AAC sample rates are defined in SDP: 48, 44.1, 32, 24, 22.05, 16, 12, 8 kHz.
For example, if Edge requests from Origin RTMP stteam published with AAC 48 kHZ, audio SDP will be following
m=audio 31006 RTP/SAVPF 102 111 8 18 100 9 103 104 105 106 107 108 109 110
c=IN IP4 192.168.1.5
a=mid:1
a=rtpmap:102 mpeg4-generic/48000/2
a=rtpmap:111 opus/48000/2
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 speex/16000
a=rtpmap:9 G722/8000
a=rtpmap:103 mpeg4-generic/44100/2
a=rtpmap:104 mpeg4-generic/32000/2
a=rtpmap:105 mpeg4-generic/24000/2
a=rtpmap:106 mpeg4-generic/22050/2
a=rtpmap:107 mpeg4-generic/16000/2
a=rtpmap:108 mpeg4-generic/12000/2
a=rtpmap:109 mpeg4-generic/11025/2
a=rtpmap:110 mpeg4-generic/8000/2
PCMU is not available by default and will be enabled only when PCMA is excluded:
Custom SDP settings for RTMP (flash_handler_publish.sdp
and flash_handler_play.sdp
) does not affect SDP for sound forwarding through CDN.
With the default settings, transcoding will not occur, for example, in the following cases:
- WebRTC (Opus) stream published on Origin is played as WebRTC on Edge (Opus)
- RTMP (AAC, any of sample rates listed above) stream published on Origin is played as RTMP on Edge (AAC with the same sample rate without resampling)
- RTMP (Speex) stream published on Origin is played as RTMP on Edge (Speex)
If there is no codec used to publish a stream in the subscribers codecs set, then transcoding will be on Edge server:
- WebRTC (Opus) stream published on Origin is played as RTMP on Edge (AAC): Opus-AAC transcoding on Edge
- RTMP (AAC stream published on Origin is played as WebRTC on Edge (Opus): AAC-Opus transcoding on Edge
- RTMP (Speex) stream published on Origin is played as WebRTC on Edge (Opus): Speex-Opus transcoding on Edge
- RTMP (Speex) stream published on Origin is played as RTMP on Edge (AAC): Speex-AAC transcoding on Edge
If the subscribers codecs set includes not only AAC, then Speex for example may be used to playback RTMP as RTMP without transcoding.
If the subscribers codecs set is limited to AAC only (flash\_handler\_play.sdp
on Edge includes AAC only), then transcoding will be on Edge if another codec is used to publish RTMP stream:
To exclude codecs while stream forwarding trough CDN, to escape transcoding on Edge server,codecs_exclude_cdn
setting should be used on Edge. Then the only remaining codec will be used to forward a stream through CDN, and if stream is published with another codec transcoding will be on Origin server.
For example, if supposed to be connected to Edge
-
RTMP subscribers with AAC only: all the codecs should be excluded except
mpeg4-generic
:
-
WebRTC subscribers with Opus only: all the codecs should be excluded except
opus
:
Custom SDP setting to publish and play RTMP stream in CDN¶
flash_handler_publish.sdp¶
flash_handler_publish.sdp
is used as publish SDP when subscriber connects to stream before WCS get audio and video from publishing client (i.e. before the real codec used by publisher is known).
In this case codecs priority will be determined in order set in flash_handler_publish.sdp
. If there is no flash_handler_publish.sdp
, then the default priority audio codec will be Speex.
For example, with default settings (without flash_handler_publish.sdp
), when RTMP (AAC) stream published on Origin is played as WebRTC (Opus) on Edge through CDN
- if subscriber connects after receiving audio from publisher (i.e. it is known that AAC is used): AAC-Opus transcoding on Edge
- if subscriber connects before receiving audio from publisher (i.e. default Speex is used): AAC-Speex transcoding on Origin and Speex-Opus transcoding on Edge
If Origin has flash_handler_publish.sdp
, in which AAC is set as first for example, then AAC will be used including the case when subscriber connects before receiving audio from publisher. Thus, if publication codec is known in advance then additional transcoding can be escaped by setting a codec in flash_handler
_publish.sdp`.
flash_handler_publish.sdp
is not used to restrict publication codecs: if any codec is excluded from flash_handler_publish.sdp
, it can still be used for publishing.
flash_handler_play.sdp¶
flash_handler_play.sdp
is used for subscriber SDP only, and not affect codecs restrictions when frowarding stream through CDN. If some code is excluded from flash_handler_play.sdp
, it will not be used to play RTMP stream by subscriber.
Choosing audio codec to play a stream¶
If there is a codec used to publish the stream in subscrbers codecs set then this codec will be used to play the stream (regardless of its priority). Otherwise, the subscribers priority codec will be used for playback, and transcoding will occur.
Read and write timeout settings in CDN for RTMP streams delivery¶
If CDN is used mostly for publishing and playing RTMP streams, and Keep Alive packets is disabled on CDN servers for some reason (for example, publishers and players do not support Keep Alives), it is necessary to setup read and write timeouts to control state of RTMP connections:
-
Read timeout can be set on Origin server that is used only to publish streams, which will not be played directly from the Origin
-
Write timeout can be set on Edge server that is used only to play CDN streams
-
Read and write timeout can be used both on Origin and Edge servers
Quick manual on testing¶
- For testing we use:
- two WCS servers;
- the Two Way Streaming web application to publish the stream;
- the Player web application to play the stream.
Configuring WCS¶
- For the test, configure CDN in the minimum configuration: one Origin and one Edge server
Origin settings:
Edge settings:
Wherecdn_enabled=true cdn_nodes_resolve_ip=true cdn_point_of_entry=origin.flashphoner.com cdn_ip=edge.flashphoner.com cdn_role=edge
origin.flashphoner.com
andedge.flashphoner.com
are example names of the WCS servers.
Restart Origin and Edge servers. Enter the command line interface of the Edge server, authorize and enter this command
The result of the command is as follows:
Running a broadcast form a web camera to the Origin server¶
-
Open the Two Way Streaming web application on the Origin server. Click the
Connect
button and specify the name of the broadcast streamtestCDN
:
-
Click the
Publish
button. The stream is published from the web camera:
Playing the stream on the Edge server¶
-
Open the Player web application on the Edge server. Specify the name of the stream broadcast to the Origin server,
testCDN
:
-
Click the
Start
button. Playing of thetestCDN
stream starts
-
In the command line interface of the Edge server enter the command
The result of executing the command is:
Stopping broadcasting from the web camera to the Origin server¶
- Click the
Stop
button on the stream publishing page. Publishing stops:
On the player page of the Edge server playing of the stream also stops and the messageStopped by publisher stop
displays
Known limits¶
-
It is strongly not recommended to publish streams with same name to two Origin servers in the same CDN.
-
A stream published to one of Origin servers should be played on the same Origin server or any Edge server, but should not be played from another Origin server in the same CDN.
Known issues¶
1. Changing codec settings on the Edge server may increase the load to the server due to transcoding¶
Symptoms
When a large number of streams are broadcast, the load on the CPU of the Edge server increases
Solution
Configure codec settings on Origin and Edge servers to reduce excessive transcoding.
For example, if the codec setting on the Origin server specifies the following set of codecs:
``` ini
codecs=opus,mpeg4-generic,alaw,ulaw,g729,g722,telephone-event,h264,vp8
```
and the setting on the Edge server is
``` ini
codecs=opus,speex16,mpeg4-generic,g729,g722,h264,vp8
```
then, when a stream is broadcast through the Edge server, audio transcoding from Speex16 or AAC is activated. With a large number of streams, the load to the CPU of the server can greatly increase.
2. Stream playback on Edge server may be terminated when Keep Alive is disabled on Origin server¶
Symptoms
When Keep Alive is disabled on Origin server
stream playback on Edge server stops even with the following setting