# You can configure static mountpoints that should be made available
# when Janus starts in this configuration file. The syntax and the
# available properties are listed below. Notice that, for the sake of
# simplicity, only the global and legacy properties are listed in the
# following text: you can use the new stream-based syntax as well (see
# the 'multistream-test' example below for reference), but in that case
# all properties whose names start with audio/video/data should be
# renamed to have that prefix removed. Please refer to the Streaming
# plugin documentation for more details, as the static configuration
# in that case mirrors the dynamic API syntax.
#
# 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)
# 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)
# h264sps = if using H.264 as a video codec, value of the sprop-parameter-sets
#		that would normally be sent via SDP, but that we'll use to instead
#		manually ingest SPS and PPS packets via RTP for streams that miss it
# 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)
#
# Note: by default, the Streaming plugin only forwards the latest packets
# it receives, never performing any buffering. This means that, for video
# streams, new viewers may initially start receiving frames they cannot
# decode right away, since they'd refer to keyframes that were sent before
# they joined. In such scenarios, they'd have to wait until the next keyframe
# arrives before video can be decoded and displayed, which could take a
# while depending on the frequency of keyframes encoded by the source.
# For forwarded streams (e.g., from the VideoRoom) this can be easily
# addressed by using the RTCP support. For sources that can't or won't
# honour dynamic keyframe requests, a partial and experimental solution
# might be storing the latest keyframe and the following deltas, to send
# to new viewers before new live packet are delivered. This feature can
# be enabled in the Streaming plugin using the 'bufferkf_ms' and/or
# the 'bufferkf_bytes' properties, which configure how many milliseconds
# or how many bytes (in total) should be stored any time a keyframe is
# received: data exceeding those limits won't be stored, until a new
# keyframe arrives. The two properties are not mutually exclusive, and
# can be configured at the same time: in that case, the first one that
# hits the limit stops the buffering of the current keyframe. Notice
# that, again, this feature should be considered highly experimental,
# and that it comes with a few considerable drawbacks: the most obvious
# one is that, depending on how many packets were stored, new viewers
# may be hit with a considerable burst of data as soon as they connect,
# which may negatively impact performance or even cause issues of its own.
# Also notice that this is a global, and not per-stream, feature: this
# means that if you create a mountpoint with two video streams, the
# feature will impact both of them, and both streams will have a buffer
# of their own. This also works for RTSP mountpoints.
#	bufferkf_ms = how many milliseconds of packets to store, starting
#					from a new keyframe (default=0)
#	bufferkf_bytes = how many bytes of packets to store, starting
#					from a new keyframe (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
#
# To allow mountpoints to negotiate the abs-capture-time RTP extension,
# you can set the 'abscapturetime_src_ext_id' property to value in range 1..14 inclusive: this way, any
# subscriber can receive the abs-capture-time of incoming RTP streams,
# assuming the browser supports the RTP extension in the first place.
# Incoming RTP stream should provide abs-capture-time exactly in the same header id.
# abscapturetime_src_ext_id = 1
#
# 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)
# rtsp_notify_changes = if set to true, will send an event to connected users when the RTSP session
#		gets disconnected, and when it's reconnected (default=false)
#
# 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 = "Pseudo-live radio broadcast (a-law file source)"
	metadata = "This is a pseudo-live stream, whose source is actually a static Opus file on the disk: the Streaming plugin goes through the file in real-time, and sends the frames via RTP. It's pseudo-live because it progresses even when there are no subscribers, and all subscribers get the same audio."
	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
# is an Opus file containing stereo opus 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 G.711 files as well.
#
file-ondemand-sample: {
	type = "ondemand"
	id = 3
	description = "Remembrance, by Lorenzo Miniero (stereo music, Opus)"
	metadata = "This is an on-demand stream, whose source is actually a static Opus file on the disk: when a subscriber opens it, the Streaming plugin starts from the beginning and goes through the file in real-time, and sends the frames via RTP. Unlike the pseudo-live sample, each subscriber opening it will experience a personal playout."
	filename = "@streamdir@/remembrance.opus"
	audio = true
	audiopt = 100
	audiortpmap = "opus/48000/2"
	audiofmtp = "stereo=1"
	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
#}
