# stream-name: {
# type = rtp|live|ondemand|rtsp
#        rtp = stream originated by an external tool (e.g., gstreamer or
#              ffmpeg) and sent to the plugin via RTP
#        live = local file streamed live to multiple listeners
#               (multiple listeners = same streaming context)
#        ondemand = local file streamed on-demand to a single listener
#                   (multiple listeners = different streaming contexts)
#        rtsp = stream originated by an external RTSP feed (only
#               available if libcurl support was compiled)
# id = <unique numeric ID> (if missing, a random one will be generated)
# description = This is my awesome stream
# metadata = An optional string that can contain any metadata (e.g., JSON)
#		   associated with the stream you want users to receive
# is_private = true|false (private streams don't appear when you do a 'list'
#			request)
# secret = <optional password needed for manipulating (e.g., destroying
#			or enabling/disabling) the stream>
# pin = <optional password needed for watching the stream>
# filename = path to the local file to stream (only for live/ondemand)
# audio = true|false (do/don't stream audio)
# video = true|false (do/don't stream video)
#    The following options are only valid for the 'rtp' type:
# data = true|false (do/don't stream text via datachannels)
# audioport = local port for receiving audio frames
# audiortcpport = local port, if any, for receiving and sending audio RTCP feedback
# audiomcast = multicast group port for receiving audio frames, if any
# audioiface = network interface or IP address to bind to, if any (binds to all otherwise)
# audiopt = <audio RTP payload type> (e.g., 111)
# audiocodec = name of the audio codec (e.g., opus)
# audioskew = true|false (whether the plugin should perform skew
#		analisys and compensation on incoming audio RTP stream, EXPERIMENTAL)
# videoport = local port for receiving video frames
# videortcpport = local port, if any, for receiving and sending video RTCP feedback
# videomcast = multicast group port for receiving video frames, if any
# videoiface = network interface or IP address to bind to, if any (binds to all otherwise)
# videopt = <video RTP payload type> (e.g., 100)
# videocodec = name of the video codec (e.g., vp8)
# videobufferkf = true|false (whether the plugin should store the latest
#		keyframe and send it immediately for new viewers, EXPERIMENTAL)
# videosimulcast = true|false (do|don't enable video simulcasting)
# videoport2 = second local port for receiving video frames (only for rtp, and simulcasting)
# videoport3 = third local port for receiving video frames (only for rtp, and simulcasting)
# videoskew = true|false (whether the plugin should perform skew
#		analisys and compensation on incoming video RTP stream, EXPERIMENTAL)
# videosvc = true|false (whether the video will have SVC support; works only for VP9-SVC, default=false)
# collision = in case of collision (more than one SSRC hitting the same port), the plugin
#		will discard incoming RTP packets with a new SSRC unless this many milliseconds
#		passed, which would then change the current SSRC (0=disabled)
# dataport = local port for receiving data messages to relay
# dataiface = network interface or IP address to bind to, if any (binds to all otherwise)
# datatype = text|binary (type of data this mountpoint will relay, default=text)
# databuffermsg = true|false (whether the plugin should store the latest
#		message and send it immediately for new viewers)
# threads = number of threads to assist with the relaying part, which can help
#		if you expect a lot of viewers that may cause the RTP receiving part
#		in the Streaming plugin to slow down and fail to catch up (default=0)
#
# In case you want to use SRTP for your RTP-based mountpoint, you'll need
# to configure the SRTP-related properties as well, namely the suite to
# use for hashing (32 or 80) and the crypto information for decrypting
# the stream (as a base64 encoded string the way SDES does it). Notice
# that with SRTP involved you'll have to pay extra attention to what you
# feed the mountpoint, as you may risk getting SRTP decrypt errors:
# srtpsuite = 32
# srtpcrypto = WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
#
# The Streaming plugin can also be used to (re)stream media that has been
# encrypted using something that can be consumed via Insertable Streams.
# In that case, we only need to be aware of it, so that we can send the
# info along with the SDP. How to decrypt the media is out of scope, and
# up to the application since, again, this is end-to-end encryption and
# so neither Janus nor the Streaming plugin have access to anything.
# DO NOT SET THIS PROPERTY IF YOU DON'T KNOW WHAT YOU'RE DOING!
# e2ee = true
#
# To allow mountpoints to negotiate the playout-delay RTP extension,
# you can set the 'playoutdelay_ext' property to true: this way, any
# subscriber can customize the playout delay of incoming video streams,
# assuming the browser supports the RTP extension in the first place.
# playoutdelay_ext = true
#
# The following options are only valid for the 'rtsp' type:
# url = RTSP stream URL (only for restreaming RTSP)
# rtsp_user = RTSP authorization username (only if type=rtsp)
# rtsp_pwd = RTSP authorization password (only if type=rtsp)
# rtsp_quirk = Some RTSP servers offer the stream using only the path, instead of the fully qualified URL.
#		If set true, this boolean informs Janus that we should try a path-only DESCRIBE request if the initial request returns 404.
# rtsp_failcheck = whether an error should be returned if connecting to the RTSP server fails (default=true)
# rtspiface = network interface or IP address to bind to, if any (binds to all otherwise), when receiving RTSP streams
# rtsp_reconnect_delay = after n seconds passed and no media assumed, the RTSP server has gone and schedule a reconnect (default=5s)
# rtsp_session_timeout = by default the streaming plugin will check the RTSP connection with an OPTIONS query,
# 		the value of the timeout comes from the RTSP session initializer and by default
# 		this session timeout is the half of this value In some cases this value can be too high (for example more than one minute)
# 		because of the media server. In that case this plugin will calculate the timeout with this
# 		formula: timeout = min(session_timeout, rtsp_session_timeout / 2). (default=0s)
# rtsp_timeout = communication timeout (CURLOPT_TIMEOUT) for cURL call gathering the RTSP information (default=10s)
# rtsp_conn_timeout = connection timeout for cURL (CURLOPT_CONNECTTIMEOUT) call gathering the RTSP information (default=5s)
#
# Notice that, for 'rtsp' mountpoints, normally the plugin uses the exact
# SDP codec and fmtp attributes the remote camera or RTSP server sent.
# In case the values set remotely are known to conflict with WebRTC viewers,
# you can override both using the settings introduced above.
#
# To test the 'gstreamer-sample' example, check the test_gstreamer.sh
# script in the plugins/streams folder. The live and on-demand  audio
# file streams, use a couple of files (radio.alaw, music.mulaw) that are
# provided in the plugins/streams folder.
#}

general: {
	#admin_key = "supersecret"		# If set, mountpoints can be created via API
									# only if this key is provided in the request
	#rtp_port_range = "20000-40000"	# Range of ports to use for RTP/RTCP when '0' is
									# passed as port for a mountpoint (default=10000-60000)
	#events = false					# Whether events should be sent to event
									# handlers (default=true)

	# By default, integers are used as a unique ID for both mountpoints. In case
	# you want to use strings instead (e.g., a UUID), set string_ids to true.
	#string_ids = true
}

#
# This is an example of an RTP source stream, which is what you'll need
# in the vast majority of cases: here, the Streaming plugin will bind to
# some ports, and expect media to be sent by an external source (e.g.,
# FFmpeg or Gstreamer). This sample listens on 5002 for audio (Opus) and
# 5004 for video (VP8), which is what the sample gstreamer script in the
# plugins/streams folder sends to. Whatever is sent to those ports will
# be the source of a WebRTC broadcast users can subscribe to.
#
rtp-sample: {
	type = "rtp"
	id = 1
	description = "Opus/VP8 live stream coming from external source"
	metadata = "You can use this metadata section to put any info you want!"
	audio = true
	video = true
	audioport = 5002
	audiopt = 111
	audiocodec = "opus"
	videoport = 5004
	videopt = 100
	videocodec = "vp8"
	secret = "adminpwd"
}

#
# This is a better example that uses the new settings to configure a live
# mountpoint to send multiple streams of the same type at the same time:
# that is, not simulcasting, but different streams (e.g., two audio
# streams and two video streams). To do so, you don't set the audio,
# video and data properties inline, but use an array of properties instead,
# each identifying a single stream to add, that will then translate to
# a dedicated m-line in the SDP. For each stream, you specify the type,
# a unique ID (mid), and can provide a short description (label) so that
# the client side can know what's what when rendering the streams;
# optionally, a msid to add to the SDP m-line can be provided as well. Notice
# how the port/pt/codec/fmtp/etc. stuff is called just like that, without
# any audio/video/data prefix: in fact, each media stream can be configured
# the same way, and it's the type that allows us to differentiate them.
# As such, you can use the same approach for creating regular mountpoints
# as well (e.g., 1 audio and 1 video) in a much clearer, and cleaner, way.
#
multistream-test: {
	type = "rtp"
	id = 123
	description = "Multistream test (1 audio, 2 video)"
	metadata = "This is an example of a multistream mountpoint: you'll get an audio stream and two video feeds"
	media = (
		{
			type = "audio"
			mid = "a"
			label = "Audio stream"
			port = 5102
			pt = 111
			codec = "opus"
		},
		{
			type = "video"
			mid = "v1"
			label = "Video stream #1"
			port = 5104
			pt = 100
			codec = "vp8"
		},
		{
			type = "video"
			mid = "v2"
			label = "Video stream #2"
			port = 5106
			pt = 100
			codec = "vp8"
		}
	)
	secret = "adminpwd"
}

#
# This is a sample of the file-based streaming support. Specifically,
# this simulates a radio broadcast by streaming (in a loop) raw a-Law
# (that is, G.711) frames. Since type is "live", anyone subscribing to
# this mountpoint will listen to the same broadcast as if it were live.
# Notice that file-based streaming supports Opus files too, but no video.
#
file-live-sample: {
	type = "live"
	id = 2
	description = "a-law file source (radio broadcast)"
	filename = "@streamdir@/radio.alaw"
	audio = true
	video = false
	secret = "adminpwd"
}

#
# This is another sample of the file-based streaming support, but using
# the "ondemand" type instead. In this case, the file we're streaming
# contains raw mu-Law (still G.711) frames. Since this is "ondemand",
# anyone subscribing to this mountpoint will listen to their own version
# of the stream, meaning that it will start from the beginning and then
# loop when it's over. On-demand streaming supports Opus files as well.
#
file-ondemand-sample: {
	type = "ondemand"
	id = 3
	description = "mu-law file source (music)"
	filename = "@streamdir@/music.mulaw"
	audio = true
	video = false
	secret = "adminpwd"
}

#
# All browsers also support H.264, often through Cisco's OpenH264 plugin.
# The only profile that is definitely supported is the baseline one, which
# means that if you try a higher one it might or might not work. No matter
# which profile you encode, though, you can put a custom one in the SDP if
# you override the fmtp SDP attribute via 'videofmtp'. The following is an
# example of how to create a simple H.264 mountpoint: you can feed it via
# an x264enc+rtph264pay pipeline in gstreamer, an ffmpeg script or other.
#
#h264-sample: {
	#type = "rtp"
	#id = 10
	#description = "H.264 live stream coming from gstreamer"
	#audio = false
	#video = true
	#videoport = 8004
	#videopt = 126
	#videocodec = "h264"
	#videofmtp = "profile-level-id=42e01f;packetization-mode=1"
	#secret = "adminpwd"
#}

#
# The Streaming plugin also supports the broadcasting of datachannel
# messages, either by themselves or along other audio/video streams (e.g.,
# to add a subtitle to a stream you're sending). The following is an
# example of how you can create a datachannel-only mountpoint: you can
# feed it with any tool that can send UDP datagrams, e.g., netcat.
# Notice that the 'rtp' type just indicates this is a live mountpoint:
# datachannel messages will be sent as usual, and not use RTP at all.
#
#data-example: {
	#type = "rtp"
	#id = 15
	#description = "Datachannel stream from an UDP source"
	#audio = false
	#video = false
	#data = true
	#dataport = 5008
	#datatype = "text"
	#secret = "adminpwd"
#}

#
# This is a variation of the rtp-sample configuration for Opus/VP8 shown
# before, where multicast support is used to receive the streams. You
# need an external script to feed data on those ports, of course.
#
#rtp-multicast: {
	#type = "rtp"
	#id = 20
	#description = "Opus/VP8 live multicast stream sample"
	#audio = true
	#video = true
	#audioport = 5002
	#audiomcast = "232.3.4.5"
	#audiopt = 111
	#audiocodec = "opus"
	#videoport = 5004
	#videomcast = "232.3.4.5"
	#videopt = 100
	#videocodec = "vp8"
	#secret = "adminpwd"
#}

#
# This is a sample configuration for an RTSP stream: you can specify
# the url to connect to and whether or not authentication is needed
# using the url/rtsp_user/rtsp_pwd settings (but notice that digest
# authentication will only work if you installed libcurl >= 7.45.0)
# NOTE WELL: the plugin does NOT transcode, so the RTSP stream MUST be
# in a format the browser can digest (e.g., VP8 or H.264 baseline for video)
# Again, you can override payload type, codec and/or fmtp, if needed.
#
#rtsp-test: {
	#type = "rtsp"
	#id = 99
	#description = "RTSP Test"
	#audio = false
	#video = true
	#url = "rtsp://127.0.0.1:8554/unicast"
	#rtsp_user = "username"
	#rtsp_pwd = "password"
	#secret = "adminpwd"
	#rtsp_reconnect_delay = 5
	#rtsp_session_timeout = 0
	#rtsp_timeout = 10
	#rtsp_conn_timeout = 5
#}