Janus服务器《四》--事件处理机制

1、总述

   虽然我们可以使用Admin API来控制及和janus服务器进行交互，但是Admin API是基于poll机制的，这就意味我们必须自动发起请求去获得我们需要的信息。如果janus处理的请求的数量巨大则我们会遇到性能问题，这将导致我们不能实时的获取我们需要的信息。若要实时获得关于会话、句柄（handle）相关的信息的话我们就得使用event机制。
   event处理机制是janus的插件，基于插件特性故非常容易进行功能扩展。当开启event处理机制后，janus和其它一些插件会产生一些特定的实时事件。事件会被发送到所有订阅了该事件的event处理插件，然后每个event事件插件会根据需要自行处理该事件。

2、事件类型

3、事件的消息格式

   所有事件都按json消息的格式发布，有一个共有的头部和可定制化的消息主体（body）。

3.1、共有头部

  事件的共有都不包含一些所有事件共有的信息，如type和subtype，事件产生时的timestamp和一些ID。这些ID包括会话ID、句柄ID、opaque ID。
通用事件格式:

{
      "emitter" : "<string identifying the source of the event, if configured (optional)>",
      "type" : <numeric event type identifier>,
      "subtype" : <numeric event subtype identifier (specific to the event type; optional)>,
      "timestamp" : <time of when the event was generated>,
      "session_id" : <unique session identifier, if provided/available (optional)>,
      "handle_id" : <unique handle identifier, if provided/available (optional)>,
      "opaque_id" : "<user-provided opaque identifier, if provided/available (optional)>",
      "event" : {
           <event body, custom depending on event type>
      }
  }

例子：

一个新的会话被创建，包括其ID和时间戳
 {
        "emitter": "MyJanusInstance",
        "type": 1,
        "timestamp": 1582211094846980,
        "session_id": 3439056127855429,
        "event": {
            "name": "created",
            "transport": {
                "transport": "janus.transport.http",
                "id": "0x60400002c2d0"
            }
        }
    }

3.2、 事件类型

  事件类型有九种，如下表所示。

  代表事件类型的数字不是连续的，这是因为在实际使用中我们可以灵活的用掩码的方式让事件处理插件去仅仅订阅其中某些事件而不是所有事件。
  事件的type类型决定了事件通知jason消息的主体，不同类型的消息结构差异大，如JSEP事件与media事件的消息结构是有很大差异的。
  有一些事件的消息的结构也会有比较大的变化，例如WebRTC状态消息包括了ICE，DTLS，本地及远端候选地址等不同的通知，出于编写事件接受者处理程序的便利，我们还使用subtype来区分事件内部的子类型。subtype只在type类型为256（core）、16（WebRTC）、32（media）中使用。

   以下是给类型中子类型的数字定义。

4、参考

《1》、Event handlers documentation