Janus流媒體服務器信令分析

---

目錄

房間配置文件

API分類

Video Room房間管理

VideoRoom Publishers

VideoRoom Subscribers

video room文檔：https://janus.conf.meetecho.com/docs/videoroom.html

---

1. 房間配置文件

room-<unique room ID>: {# 房間描述description = This is my awesome room# 是否是私有房間，當提出“list”請求時，私人房間不會出現is_private = true|false (private rooms don't appear when you do a 'list' request, default=false)# 密碼，操作房間時需要攜帶secret = <optional password needed for manipulating (e.g. destroying) the room># 密碼，加?房間時使?pin = <optional password needed for joining the room># 訂閱者是否需要提供?個有效的與發布者關聯的有效private_idrequire_pvtid = true|false (whether subscriptions are required to provide a valid private_idto associate with a publisher, default=false)# 房間內最?的發布者數量publishers = <max number of concurrent senders> (e.g., 6 for a videoconference or 1 for a webinar, default=3)# 發送者最?的視頻?特率bitrate = <max video bitrate for senders> (e.g., 128000)bitrate_cap = <true|false, whether the above cap should act as a limit to dynamic bitrate changes by publishers, default=false>,# FIR指令fir_freq = <send a FIR to publishers every fir_freq seconds> (0=disable)# ?頻編碼器，從左到右的優先級audiocodec = opus|g722|pcmu|pcma|isac32|isac16 (audio codec to force on publishers, default=opuscan be a comma separated list in order of preference, e.g., opus,pcmu)# 視頻編碼器，從左到右的優先級videocodec = vp8|vp9|h264|av1|h265 (video codec to force on publishers, default=vp8can be a comma separated list in order of preference, e.g., vp9,vp8,h264)vp9_profile = VP9-specific profile to prefer (e.g., "2" for "profile-id=2")h264_profile = H.264-specific profile to prefer (e.g., "42e01f" for "profile-level-id=42e01f")# 是否使?內置FECopus_fec = true|false (whether inband FEC must be negotiated; only works for Opus, default=false)# 是否?持編碼SVC模式，?前只?持VP9video_svc = true|false (whether SVC support must be enabled; only works for VP9, default=false)audiolevel_ext = true|false (whether the ssrc-audio-level RTP extension must benegotiated/used or not for new publishers, default=true)audiolevel_event = true|false (whether to emit event to other users or not, default=false)# 音頻級別的包數audio_active_packets = 100 (number of packets with audio level, default=100, 2 seconds)# ?頻?量基本平均值audio_level_average = 25 (average value of audio level, 127=muted, 0='too loud', default=25)videoorient_ext = true|false (whether the video-orientation RTP extension must benegotiated/used or not for new publishers, default=true)playoutdelay_ext = true|false (whether the playout-delay RTP extension must benegotiated/used or not for new publishers, default=true)transport_wide_cc_ext = true|false (whether the transport wide CC RTP extension must benegotiated/used or not for new publishers, default=true)# 是否錄制record = true|false (whether this room should be recorded, default=false)# 錄制?錄rec_dir = <folder where recordings should be stored, when enabled>lock_record = true|false (whether recording can only be started/stopped if the secretis provided, or using the global enable_recording request, default=false)# 當新?加?時是否通知所有的參會者notify_joining = true|false (optional, whether to notify all participants when a newparticipant joins the room. The Videoroom plugin by design only notifiesnew feeds (publishers), and enabling this may result extra notificationtraffic. This flag is particularly useful when enabled with require_pvtidfor admin to manage listening only participants. default=false)# 是否使?端對端加密require_e2ee = true|false (whether all participants are required to publish and subscribeusing end-to-end media encryption, e.g., via Insertable Streams; default=false) }

2. API分類

Video Room ?持不同的請求，?部分是同步請求，?部分是異步請求。

1. 同步請求

同步請求：直接在事務（ transacation ）的上下??獲取響應，即直接響應（ transaction 綁定即可）

create：動態創建?個新的房間，作為使?配置?件的替代?法

destroy：移除并銷毀房間，同時剔除房間?的所有?戶

edit：動態修改?些房間屬性

exists：查詢是否存在指定的房間

list：列出所有可?的房間

allowed：配置觀眾進?房間權限

kick：管理員踢除?戶操作

listparticipants：列出所有指定房間中活躍（?如當前正在發布）的參與者和他們的詳細信息

2. 異步請求

異步請求：在事件（ event ）通知中獲取成功（ success ）與失敗（ failure ）事件，先發?個ask后再發?個 event 進?響應（必須使? handle_id 綁定）

join：加?指定的房間，并指定連接?于發布或觀看?視頻

configure：修改?些參與者的設置，例如 bitrate cap

joinandconfigure：對于發布者，將前兩個請求合成?個

publish：開始發送媒體并?播給其他參與者

unpublish：停?發送媒體并?播給其他參與者

start：開始接收來?發布者的媒體數據

pause：停?傳遞媒體數據

switch：修改媒體連接的來源

leave：離開房間

3. Video Room房間管理

1. create-創建房間

1. 請求body

{"request" : "create","room" : <unique numeric ID, optional, chosen by plugin if missing>,"permanent" : <true|false, whether the room should be saved in the config file, default=false>,"description" : "<pretty name of the room, optional>","secret" : "<password required to edit/destroy the room, optional>","pin" : "<password required to join the room, optional>","is_private" : <true|false, whether the room should appear in a list request>,"allowed" : [ array of string tokens users can use to join this room, optional],... }

更多房間創建參數可參考房間配置?件—— conf/janus.plugin.videoroom.jcfg

請求都是以"request"為key，接著是命令，?如這?的"create"。

room：可選，唯?的房間ID，不提供時由video room插件?動?成；

permanent：可選，是否永久保存該房間；

secret: 可選，編輯/銷毀房間時?的密碼;

pin：可選，加?房間的密碼;

is_private：可選，是否是私有房間？如果是私有房間則不會出現在房間列表中;

allowed：可選，?戶加?房間的token數組;

2. 成功響應-created

{"videoroom" : "created","room" : <unique numeric ID>,"permanent" : <true if saved to config file, false if not> }

創建成功后返回房間ID

如果你請求了?個永久房間但返回的是false，則很有可能是權限的問題。

3. 失敗回調 event

{"videoroom" : "event","error_code" : <numeric ID, check Macros below>,"error" : "<error description as a string>" }

默認情況下，Janus 中所有?戶都可以創建房間，但我們可以在插件中配置 admin_key 來限制此功能，只有在 create 攜帶了正確的 admin_key 才可以創建成功。

也可以選擇將此功能擴展到RTP轉發，以便只允許受信任的客戶端使?此功能。

2. edit-編輯房間

在房間被創建后，我們可以使? edit 編輯房間的屬性（例如 room description 、 secret 、 pin 、private or not ），但不能修改?些靜態的屬性（例如 room ID 、 sampling rate ）。

1. 請求body

{"request" : "edit","room" : <unique numeric ID of the room to edit>,"secret" : "<room secret, mandatory if configured>","new_description" : "<new pretty name of the room, optional>","new_secret" : "<new password required to edit/destroy the room, optional>","new_pin" : "<new password required to join the room, optional>","new_is_private" : <true|false, whether the room should appear in a list request>,"new_require_pvtid" : <true|false, whether the room should require private_id from subscribers>,"new_bitrate" : <new bitrate cap to force on all publishers (except those with custom overrides)>,"new_fir_freq" : <new period for regular PLI keyframe requests to publishers>,"new_publishers" : <new cap on the number of concurrent active WebRTC publishers>,"new_lock_record" : <true|false, whether recording state can only be changed when providing the room secret>,"permanent" : <true|false, whether the room should be also removed from the config file, default=false> }

創建房間完成后，ID是不可以修改的。

2. 成功響應-edited

{"videoroom" : "edited","room" : <unique numeric ID> }

3. destroy-銷毀房間

?論是靜態還是動態的房間，都可以? destroy 進?銷毀。

1. 請求body

{"request" : "destroy","room" : <unique numeric ID of the room to destroy>,"secret" : "<room secret, mandatory if configured>","permanent" : <true|false, whether the room should be also removed from the config file, default=false> }

2. 成功響應-destroyed

{"videoroom" : "destroyed","room" : <unique numeric ID> }

3. 房間用戶接收的事件-event

當房間被destroy時，其他所有參與者都會收到這個事件，獲知房間被銷毀

{"videoroom" : "destroyed","room" : <unique numeric ID of the destroyed room> }

4. exist-房間是否存在

1. 請求body

{"request" : "exists","room" : <unique numeric ID of the room to check> }

2. 成功響應-success

{"videoroom" : "success","room" : <unique numeric ID>,"exists" : <true|false> }

5. allowd-出入管理

可以配置是否檢查tokens，或者添加/刪除增加/刪除允許加?房間的?戶。

1. 請求body

{"request" : "allowed","secret" : "<room secret, mandatory if configured>","action" : "enable|disable|add|remove","room" : <unique numeric ID of the room to update>,"allowed" : [// Array of strings (tokens users might pass in "join", only for add|remove)] }

2. 成功響應-success

{"videoroom" : "success","room" : <unique numeric ID>,"allowed" : [// Updated, complete, list of allowed tokens (only for enable|add|remove)] }

6. kick-踢出房間

房間的管理員可以通過 kick ?法將指定參與者踢出房間。注意，只是能將他踢出房間，并不能阻?他再次進?。若想阻?他再次進?，則需要使? allowed 對他進?限制

1. 請求body

{"request" : "kick","secret" : "<room secret, mandatory if configured>","room" : <unique numeric ID of the room>,"id" : <unique numeric ID of the participant to kick> }

2. 成功響應-success

{"videoroom" : "success", }

7. list-房間列表

?于展示公開的所有房間

1. 請求body

{"request" : "list" }

2. 成功響應-success

{"videoroom" : "success","list" : [ // Array of room objects{ // Room #1"room" : <unique numeric ID>,"description" : "<Name of the room>","pin_required" : <true|false, whether a PIN is required to join this room>,"is_private" : <true|false, whether this room is 'private' (as in hidden) or not>,"max_publishers" : <how many publishers can actually publish via WebRTC at the same time>,"bitrate" : <bitrate cap that should be forced (via REMB) on all publishers by default>,"bitrate_cap" : <true|false, whether the above cap should act as a limit to dynamic bitrate changes by publishers (optional)>,"fir_freq" : <how often a keyframe request is sent via PLI/FIR to active publishers>,"require_pvtid": <true|false, whether subscriptions in this room require a private_id>,"require_e2ee": <true|false, whether end-to-end encrypted publishers are required>,"notify_joining": <true|false, whether an event is sent to notify all participants if a new participant joins the room>,"audiocodec" : "<comma separated list of allowed audio codecs>","videocodec" : "<comma separated list of allowed video codecs>","opus_fec": <true|false, whether inband FEC must be negotiated (note: only available for Opus) (optional)>,"video_svc": <true|false, whether SVC must be done for video (note: only available for VP9 right now) (optional)>,"record" : <true|false, whether the room is being recorded>,"rec_dir" : "<if recording, the path where the .mjr files are being saved>","lock_record" : <true|false, whether the room recording state can only be changed providing the secret>,"num_participants" : <count of the participants (publishers, active or not; not subscribers)>"audiolevel_ext": <true|false, whether the ssrc-audio-level extension must be negotiated or not for new publishers>,"audiolevel_event": <true|false, whether to emit event to other users about audiolevel>,"audio_active_packets": <amount of packets with audio level for checkup (optional, only if audiolevel_event is true)>,"audio_level_average": <average audio level (optional, only if audiolevel_event is true)>,"videoorient_ext": <true|false, whether the video-orientation extension must be negotiated or not for new publishers>,"playoutdelay_ext": <true|false, whether the playout-delay extension must be negotiated or not for new publishers>,"transport_wide_cc_ext": <true|false, whether the transport wide cc extension must be negotiated or not for new publishers>},// Other rooms] }

8. listparticipants列出房間的參與者

可以使?listparticipants列出房間的參與者。

1. 請求body

{"request" : "listparticipants","room" : <unique numeric ID of the room> }

2. 成功響應-participants

{"videoroom" : "participants","room" : <unique numeric ID of the room>,"participants" : [ // Array of participant objects{ // Participant #1"id" : <unique numeric ID of the participant>,"display" : "<display name of the participant, if any; optional>","publisher" : "<true|false, whether user is an active publisher in the room>","talking" : <true|false, whether user is talking or not (only if audio levels are used)>},// Other participants] }

4. VideoRoom Publishers

發布者和訂閱者在房間?有不同的屬性。

發布者 Publisher

活躍的發布者 active publisher

不活躍的發布者 passive publisher

訂閱者 Subscriber

在Video Room中，發布者（Publisher）是將多媒體數據發布在房間中的參與者，他們可以成為 feeds讓其他?戶進?訂閱（subscribe）。

1. join-加入房間

可以通過 join 請求將指定的 handle 指定為 publisher 或 subscriber 。

指定為 publisher ：Janus 會將指定?戶添加到房間中的參與者列表（ the list ofparticipants ）中，此后，參與者可以接受到房間中關于 handle 的?系列通知（包括流的可?與移除）。

指定為 subscriber ：

1. 請求body

{"request" : "join","ptype" : "publisher","room" : <unique ID of the room to join>,"id" : <unique ID to register for the publisher; optional, will be chosen by the plugin if missing>,"display" : "<display name for the publisher; optional>","token" : "<invitation token, in case the room has an ACL; optional>" }

2. 成功響應-joined

成功 join ?房間后，將會接收到當前房間中活躍的 publishers 的列表。

{"videoroom" : "joined","room" : <room ID>,"description" : <description of the room, if available>,"id" : <unique ID of the participant>,"private_id" : <a different unique ID associated to the participant; meant to be private>,"publishers" : [{"id" : <unique ID of active publisher #1>,"display" : "<display name of active publisher #1, if any>","streams" : [{"type" : "<type of published stream #1 (audio|video|data)">,"mindex" : "<unique mindex of published stream #1>","mid" : "<unique mid of of published stream #1>","disabled" : <if true, it means this stream is currently inactive/disabled (and so codec, description, etc. will be missing)>,"codec" : "<codec used for published stream #1>","description" : "<text description of published stream #1, if any>","moderated" : <true if this stream audio has been moderated for this participant>,"simulcast" : "<true if published stream #1 uses simulcast (VP8 and H.264 only)>","svc" : "<true if published stream #1 uses SVC (VP9 only)>","talking" : <true|false, whether the publisher stream has audio activity or not (only if audio levels are used)>,},// Other streams, if any],"talking" : <true|false, whether the publisher is talking or not (only if audio levels are used); deprecated, use the stream specific ones>,},// Other active publishers],"attendees" : [ // Only present when notify_joining is set to TRUE for rooms{"id" : <unique ID of attendee #1>,"display" : "<display name of attendee #1, if any>"},// Other attendees] }

當房間配置了 notify_joining 為 TRUE 時，也會返回不推流的參與者。

private_id ：該屬性?于訂閱，便于插件對其進?關聯。

attendees：當notify_joining=true時返回。

3. 關于不活躍的發布者進出通知

不活躍的發布者加?房間不會通知其他參與者，因為?個?房間中可能會有很多參與者，如果每?個進?離開都需要通知所有?的話會顯得太過于繁瑣。如果開發者它進出房間也通知所有?，那么需要將房間的notify_joining 配置為 true 。通知的事件如下：

{"videoroom" : "event","room" : <room ID>,"joining" : {"id" : <unique ID of the new participant>,"display" : "<display name of the new participant, if any>"} }

2. publish-發布

發布者帶著 Offer 向 Janus 進?協商

publish 請求必須攜帶著 JSEP SDP offer去協商?個新的 PeerConnection，即插件會檢查編碼器和碼率是否是房間所?持的，之后將會回應?個 JSEP SDP answer 來關閉循環并完成配置?個PeerConnection。當指定的 PeerConnection 搭建好后，該指定的 publisher 才會變成?個活躍的publisher，之后其他參與者才可以訂閱它。

1. 請求body

{"request" : "publish","audiocodec" : "<audio codec to prefer among the negotiated ones; optional>","videocodec" : "<video codec to prefer among the negotiated ones; optional>","bitrate" : <bitrate cap to return via REMB; optional, overrides the global room value if present>,"record" : <true|false, whether this publisher should be recorded or not; optional>,"filename" : "<if recording, the base path/file to use for the recording files; optional>","display" : "<new display name to use in the room; optional>","audio_level_average" : "<if provided, overrided the room audio_level_average for this user; optional>","audio_active_packets" : "<if provided, overrided the room audio_active_packets for this user; optional>","display" : "<new display name to use in the room; optional>","descriptions" : [ // Optional{"mid" : "<unique mid of a stream being published>","description" : "<text description of the stream (e.g., My front webcam)>"},// Other descriptions, if any]}

audio：是否轉發?頻；

video：是否轉發視頻；

data：是否轉發數據；

該請求和JSEP SDP offer?起提供，插件收到此消息后，將協商與之匹配的 JSEP SDP Answer 。

2. 成功響應-event

{"videoroom" : "event","configured" : "ok" }

3. configure-配置（開始發布）

publish 和 configure 在功能上時相同的，他們都有開始發布的功能。從語義上， publish 更加合適。但是 configure 可以更新發布者會話的某些屬性。總的來說 configure 的功能更加強?。

1. 請求body

{"request" : "configure","bitrate" : <bitrate cap to return via REMB; optional, overrides the global room value if present (unless bitrate_cap is set)>,"keyframe" : <true|false, whether we should send this publisher a keyframe request>,"record" : <true|false, whether this publisher should be recorded or not; optional>,"filename" : "<if recording, the base path/file to use for the recording files; optional>","display" : "<new display name to use in the room; optional>","audio_active_packets" : "<new audio_active_packets to overwrite in the room one; optional>","audio_level_average" : "<new audio_level_average to overwrite the room one; optional>","mid" : <mid of the m-line to refer to for this configure request; optional>,"send" : <true|false, depending on whether the media addressed by the above mid should be relayed or not; optional>,"descriptions" : [// Updated descriptions for the published streams; see "publish" for syntax; optional] }

2. 成功響應-event

{"videoroom" : "event","configured" : "ok" }

4. joinandconfigure-加入并配置（加入并且發布）

1. 請求body

參考join請求用的body，并攜帶 JSEP SDP offer

2. 成功響應-joined

成功響應將是?個 joined 事件，并且攜帶 JSEP SDP answer。

5. 發布成功后推送

當?個?戶在房間中發布成功后，Janus 將會發送?個關于新對端的事件給所有參與者，事件如下：

{"videoroom" : "event","room" : <room ID>,"publishers" : [{"id" : <unique ID of the new publisher>,"display" : "<display name of the new publisher, if any>","streams" : [{"type" : "<type of published stream #1 (audio|video|data)">,"mindex" : "<unique mindex of published stream #1>","mid" : "<unique mid of of published stream #1>","disabled" : <if true, it means this stream is currently inactive/disabled (and so codec, description, etc. will be missing)>,"codec" : "<codec used for published stream #1>","description" : "<text description of published stream #1, if any>","moderated" : <true if this stream audio has been moderated for this participant>,"simulcast" : "<true if published stream #1 uses simulcast (VP8 and H.264 only)>","svc" : "<true if published stream #1 uses SVC (VP9 only)>","talking" : <true|false, whether the publisher stream has audio activity or not (only if audio levels are used)>,},// Other streams, if any],"talking" : <true|false, whether the publisher is talking or not (only if audio levels are used); deprecated, use the stream specific ones>,}] }

6. unpublish-停止發布

unpublish 請求?于停?發布并且銷毀相關的 PeerConnection，并且將發布者從活躍流列表中移除。

1. 請求body

{"request" : "unpublish" }

2. 成功響應-event

{"videoroom" : "event","unpublished" : "ok" }

3. 其他成員通知

?旦PeerConnections斷開，房間內的其他參與者會通過下?這個通知得知此事

{"videoroom" : "event","room" : <room ID>,"unpublished" : <unique ID of the publisher who unpublished> }

可以在同?個 handle 中多次發布和取消發布流

configure 基本上與 publish 的屬性相同。這就是為什么兩個請求都可以?來開始發布的原因。如果configure 成功，則返回 configured 事件，格式如下：

{"videoroom" : "event","configured" : "ok" }

當發送 configure 請求RTP擴展 ssrc-audio-level 時，如果 audiolevel_event 設置為true ，則可能會向所有發布者發送?些臨時事件。這些事件將具有以下格式：

{"videoroom" : <"talking"|"stopped-talking", whether the publisher started or stopped talking>,"room" : <unique numeric ID of the room the publisher is in>,"id" : <unique numeric ID of the publisher>,"audio-level-dBov-avg" : <average value of audio level, 127=muted, 0='too loud'> }

7. RTP轉發器

VideoRoom 插件的主要?的是從WebRTC源(發布者)獲取媒體，并將其轉發到WebRTC?的地（訂閱者），但實際上存在?種?案，可以將媒體轉發給外部（不?定與WebRTC兼容）組件。例如，?于媒體處理，外部錄制，轉碼，級聯等等。 rtp_forward 顧名思義，就是將發布者發送的RTP包（普通或加密）實時轉發到遠程后端。

可以使? rtp_forward 請求為現有發布者添加新的RTP轉發器，其格式如下：

{"request" : "rtp_forward","room" : <unique numeric ID of the room the publisher is in>,"publisher_id" : <unique numeric ID of the publisher to relay externally>,"host" : "<host address to forward the RTP and data packets to>","host_family" : "<ipv4|ipv6, if we need to resolve the host address to an IP; by default, whatever we get>","streams" : [{"mid" : "<mid of publisher stream to forward>","host" : "<host address to forward the packets to; optional, will use global one if missing>","host_family" : "<optional, will use global one if missing>","port" : <port to forward the packets to>,"ssrc" : <SSRC to use to use when forwarding; optional, and only for RTP streams, not data>,"pt" : <payload type to use when forwarding; optional, and only for RTP streams, not data>,"rtcp_port" : <port to contact to receive RTCP feedback from the recipient; optional, and only for RTP streams, not data>,"simulcast" : <true|false, set to true if the source is simulcast and you want the forwarder to act as a regular viewer (single stream being forwarded) or false otherwise (substreams forwarded separately); optional, default=false>,"port_2" : <if video and simulcasting, port to forward the packets from the second substream/layer to>,"ssrc_2" : <if video and simulcasting, SSRC to use to use the second substream/layer; optional>,"pt_2" : <if video and simulcasting, payload type to use the second substream/layer; optional>,"port_3" : <if video and simulcasting, port to forward the packets from the third substream/layer to>,"ssrc_3" : <if video and simulcasting, SSRC to use to use the third substream/layer; optional>,"pt_3" : <if video and simulcasting, payload type to use the third substream/layer; optional>,},{.. other streams, if needed..}],"srtp_suite" : <length of authentication tag (32 or 80); optional>,"srtp_crypto" : "<key to use as crypto (base64 encoded key as in SDES); optional>" }

如果配置了admin_key屬性，則在請求中也需要提供它，否則未授權的請求將被拒絕。默認情況下，沒有對rtp_forward進?限制。

如果請求成功則返回 rtp_forward 響應，其中格式如下：

{"videoroom" : "rtp_forward","room" : <unique numeric ID, same as request>,"publisher_id" : <unique numeric ID, same as request>,"forwarders" : [{"stream_id" : <unique numeric ID assigned to this forwarder, if any>,"type" : "<audio|video|data>","host" : "<host this forwarder is streaming to, same as request if not resolved>","port" : <port this forwarder is streaming to, same as request if configured>,"local_rtcp_port" : <local port this forwarder is using to get RTCP feedback, if any>,"remote_rtcp_port" : <remote port this forwarder is getting RTCP feedback from, if any>,"ssrc" : <SSRC this forwarder is using, same as request if configured>,"pt" : <payload type this forwarder is using, same as request if configured>,"substream" : <video substream this video forwarder is relaying, if any>,"srtp" : <true|false, whether the RTP stream is encrypted (not used for data)>},// Other forwarders, if configured] }

要停?以前創建的RTP轉發器，可以使? stop_rtp_forward 請求，其格式如下：

{"request" : "stop_rtp_forward","room" : <unique numeric ID of the room the publisher is in>,"publisher_id" : <unique numeric ID of the publisher to update>,"stream_id" : <unique numeric ID of the RTP forwarder> }

請求成功，則返回 stop_rtp_forward 響應：

{"videoroom" : "stop_rtp_forward","room" : <unique numeric ID, same as request>,"publisher_id" : <unique numeric ID, same as request>,"stream_id" : <unique numeric ID, same as request> }

如果要獲取特定房間中所有轉發器的列表，可以使? listforwarders 請求，其格式如下：

{"request" : "listforwarders","room" : <unique numeric ID of the room>,"secret" : "<room secret; mandatory if configured>" }

請求成功，則返回forwarders響應，其中包括RTP轉發器列表：

{"videoroom" : "forwarders","room" : <unique numeric ID of the room>,"publishers" : [ // Array of publishers with RTP forwarders{ // Publisher #1"publisher_id" : <unique numeric ID of publisher #1>,"forwarders" : [ // Array of RTP forwarders{ // RTP forwarder #1"stream_id" : <unique numeric ID assigned to this RTP forwarder, if any>,"type" : "<audio|video|data>","host" : "<host this forwarder is streaming to>","port" : <port this forwarder is streaming to>,"local_rtcp_port" : <local port this forwarder is using to get RTCP feedback, if any>,"remote_rtcp_port" : <remote port this forwarder getting RTCP feedback from, if any>,"ssrc" : <SSRC this forwarder is using, if any>,"pt" : <payload type this forwarder is using, if any>,"substream" : <video substream this video forwarder is relaying, if any>,"srtp" : <true|false, whether the RTP stream is encrypted>},// Other forwarders for this publisher],},// Other publishers] }

在會議進?期間啟?或禁?錄制，您可以使? enable_recording 請求，該請求的格式如下：

{"request" : "enable_recording","room" : <unique numeric ID of the room>,"secret" : "<room secret; mandatory if configured>""record" : <true|false, whether participants in this room should be automatically recorded or not>, }

參與者通常也可以通過configure請求來更改??的錄制狀態：這樣做是為了獲得最?的靈活性，可能希望單獨記錄?些流，?不是全局或?動記錄?些內容，到特定?件。

就是說，如果希望確保在啟?全局錄制后參與者不能停?其錄制，或者在不應該錄制該會議室的情況下啟動它，那么您應該確保在創建會議室時使?lock_record屬性，將其設置為true。這樣，只有在提供了房間密碼的情況下，才能更改錄制狀態，從?確保只有管理員才能執?此操作。

最后，您可以使? leave 請求離開會議室。如果您是會議室中的活動發布者，這也將隱式取消你的發布。該leave請求如下所示

{"request" : "leave" }

如果成功，響應將如下所示：

{"videoroom" : "event","leaving" : "ok" }

其他參與者將收到”leave”事件，格式如下：

{"videoroom" : "event","room" : <room ID>,"leaving : <unique ID of the participant who left> }

如果是活躍的發布者，則其他?戶也將收到相應的 unpublish 事件，以通知他們該流不再可?。如果只是潛伏?不是發布者，則其他參與者將僅收到”leave”事件。

5. VideoRoom Subscribers

在 VideoRoom 中，訂閱者（Subscriber）不是參與者，但是他可以準確接收指定發布者的媒體數據。

通常發布者發布了媒體后，訂閱者可以獲取該流進?播放。當發布者取消發布后，訂閱者 handle 也會隨之被移除。除?給訂閱者正確的信息，不然訂閱者是不能單獨存在的。

1. join-加入房間

1. 請求body

{"request" : "join","ptype" : "subscriber","room" : <unique ID of the room to subscribe in>,"feed" : <unique ID of the publisher to subscribe to; mandatory>,"private_id" : <unique ID of the publisher that originated this request; optional, unless mandated by the room configuration>,"streams" : [{"feed" : <unique ID of publisher owning the stream to subscribe to>,"mid" : "<unique mid of the publisher stream to subscribe to; optional>"// Optionally, simulcast or SVC targets (defaults if missing)},// Other streams to subscribe to] }

如果發布者對房間中的媒體進?訂閱，則需要傳? private_id 。

2. 成功響應-attached（Offer）

訂閱者成功加?房間并訂閱指定 feed 成功后，Janus 會給予?個 attached 響應，并且在這個 event中攜帶 JSEP SDP offer，?于進?媒體協商。

{"videoroom" : "attached","room" : <room ID>,"streams" : [{"mindex" : <unique m-index of this stream>,"mid" : "<unique mid of this stream>","type" : "<type of this stream's media (audio|video|data)>","feed_id" : <unique ID of the publisher originating this stream>,"feed_mid" : "<unique mid of this publisher's stream>","feed_display" : "<display name of this publisher, if any>","send" : <true|false; whether we configured the stream to relay media>,"ready" : <true|false; whether this stream is ready to start sending media (will be false at the beginning)>},// Other streams in the subscription, if any] }

2. start-開始訂閱（Answer 對 attached 的訂閱者響應）

訂閱者接收到含有 attach 的 event 后，獲取??的 JSEP SDP offer 后，將其設置為遠程 SDP 后，然后發送 start 請求并攜帶 JSEP SDP answer。

1. 請求body

{"request" : "start" }

2. 成功響應-event

{"videoroom" : "event","started" : "ok" }

當訂閱者與Janus媒體協商完畢后，雙?就會建??條新的 WebRTC PeerConnection。在這之后，Streaming插件將會開始將媒體轉發到訂閱者端。

3. pause-暫停訂閱

1. 請求body

以通過 pause 和 start 請求對訂閱媒體進?臨時的暫停和恢復，此處的 start 不需要攜帶 JSEP SDP answer

{"request" : "pause" }

2. 成功響應-event

{"videoroom" : "event","paused" : "ok" }

?于恢復的 start 其?法和上?是?致的，注意他不?攜帶 JSEP 即可。

4. configure-配置

configure 請求允許動態修改訂閱者對于媒體訂閱的?些屬性，?如配置?頻和視頻的啟?與禁?，靈活設置訂閱內容。

1. 請求body

{"request" : "configure","mid" : <mid of the m-line to refer to for this configure request; optional>,"send" : <true|false, depending on whether the mindex media should be relayed or not; optional>,"substream" : <substream to receive (0-2), in case simulcasting is enabled; optional>,"temporal" : <temporal layers to receive (0-2), in case simulcasting is enabled; optional>,"fallback" : <How much time (in us, default 250000) without receiving packets will make us drop to the substream below>,"spatial_layer" : <spatial layer to receive (0-2), in case VP9-SVC is enabled; optional>,"temporal_layer" : <temporal layers to receive (0-2), in case VP9-SVC is enabled; optional>,"audio_level_average" : "<if provided, overrides the room audio_level_average for this user; optional>","audio_active_packets" : "<if provided, overrides the room audio_active_packets for this user; optional>","restart" : <trigger an ICE restart; optional> }

audio 、 video 和 data ：可以在媒體層（ media-level ）上進?暫停與恢復，對? pause 和start 直接作?所有?視頻流??，它更加靈活。

substream 和 temporal ： The substream and temporal properties, instead, only make sense when the mountpoint is configured with video simulcasting support, and as such the viewer is interested in receiving a specific substream or temporal layer, rather than any other of the available ones.

spatial_layer 和 temporal_layer ：The spatial_layer and temporal_layer have exactly the same meaning, but within the context of VP9-SVC publishers, and will have no effect on subscriptions associated to regular publishers.

5. switch-切換

switch 適?于已經與 Janus 成功建? PeerConnection 的訂閱者，通過這個請求完成訂閱的切換，就像看電視切換頻道?樣。這樣做的好處就是能復??條連接，在切換訂閱?標的時候不需要重新建?連接，消耗不必要的資源。

但是他也有以下的限制：

不能只換?視頻流的其中?個，要都換

兩個?標發布者必須使??樣的配置，?如?樣的編碼器、?樣的數據格式（不?樣的話會導致延遲甚?直接?屏沒聲?）

1. 請求body

{"request" : "switch","streams" : [{"feed" : <unique ID of the publisher the new source is from>,"mid" : "<unique mid of the source we want to switch to>","sub_mid" : "<unique mid of the stream we want to pipe the new source to>"},{// Other updates, if any}] }

2. 成功響應-event

{"videoroom" : "event","switched" : "ok","room" : <room ID>,"changes" : <number of successful changes (may be smaller than the size of the streams array provided in the request)>,"streams" : [// Current configuration of the subscription, same format as when subscribing// Will contain info on all streams, not only those that have been updated] }

6. leave-離開房間

leave 請求?于停?訂閱并銷毀相關的 PeerConnection，由于上下?是隱式的，所以不需要其他參數

1. 請求body

{"request" : "leave" }

2. 成功響應-event

{"videoroom" : "event","left" : "ok", }

總結

以上是生活随笔為你收集整理的Janus流媒体服务器信令分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。