研究 RTPEngine publish

subscribe 现在基本明白了

但说实在的，不太懂 pubish，可能是 publish 和 subscribe 配合使用，实现 N-to-N media forwarding 功能

先看看手册是怎样讲的：

# publish 类似于 Offer 消息，但用于 Offer/Answer 场景之外。由 SDP 描述的媒体直接发布到 rtpengine，随后其他对端可以订阅已发布的媒体以接收副本。 该消息必须包含键 `sdp`，其应描述仅发送（sendonly）的媒体；以及键 `call-id` 和 `from-tag`，用于标识发布者。Offer 所支持的大多数其他键和选项也适用于 Publish。 响应消息将在 `sdp` 中包含一个 Answer SDP，但与 Offer 不同的是，这不是对接收到的 SDP 的重写版本，而是由 rtpengine 本地生成的仅接收（recvonly）Answer SDP。每个媒体分段仅列出一个编解码器，默认情况下，这将是从已发布媒体中选出的第一个受支持的编解码器。这可以通过上述编解码器选项（特别是 `accept` 选项）来影响。 `accept` 选项中给出的编解码器列表被视为编解码器偏好列表，列表中第一个编解码器是最优先接受的，以此类推。允许列出不支持转码的编解码器。如果 Offer 中不存在 `accept` 列表里的任何编解码器，则选择第一个支持转码的编解码器。如果不存在这样的编解码器，则拒绝该 Offer。可以在 `accept` 列表中给出特殊字符串 `any` 来影响此行为：如果列出了 `any`，则接受 Offer 中的第一个编解码器，即使它不支持转码。 # subscribe_request 此消息用于请求订阅（即接收媒体副本）一个或多个现有的通话参与者，这些参与者必须已通过 Offer/Answer 机制或 Publish 机制创建。 可以选择单个通话参与者，方式与阻止 DTMF 下描述的方式相同。可以选择多个通话参与者：要么使用 `all` 关键字（此时将选择所有通过 Offer/Answer 机制创建的通话参与者），要么在 `from-tags` 列表中提供标签（from-tags）列表。 然后，此消息会创建一个新的通话参与者，该参与者对应此次订阅。这个新的通话参与者将由一个新生成的唯一标签来标识，或者由 `to-tag` 键中给出的标签来标识。如果要为新创建的订阅设置标签，可以通过 `set-label` 进行设置。 响应消息将在 `sdp` 中包含一个仅发送（sendonly）的 Offer SDP，默认情况下，该 SDP 将镜像所订阅通话参与者的 SDP。如果同时订阅了多个通话参与者，则该 SDP 将包含多个媒体分段，这些分段由所有选定通话参与者的媒体分段组合而成。此 Offer SDP 可以使用与 Offer 消息中相同的标志进行操作，包括操作编解码器的选项。响应消息还将包含 `from-tags`（对应于被订阅的通话参与者）和 `to-tag`（对应于订阅，可能是生成的，也可能是从接收到的消息中获取的）。 如果对一个已存在的 `to-tag` 发起订阅请求，则在创建新订阅之前，该 `to-tag` 对应的所有现有订阅都将被删除。 # subscribe_answer 此消息预期在对订阅请求消息的响应之后接收。该消息应包含与订阅请求响应相同的 `to-tag`，以及 `sdp` 中的 Answer SDP。 默认情况下，Answer SDP 必须接受 Offer SDP（在订阅请求的响应中给出）中呈现的所有编解码器。如果并非所有编解码器都被接受，则订阅应答将被拒绝。通过在消息中包含 `allow transcoding` 标志可以改变此行为。如果存在此标志，则只要至少存在一个有效的编解码器，Answer SDP 就会被接受，并且媒体将根据需要进行转码。如果某些编解码器是在订阅请求消息中添加用于转码的，此规则同样适用，这意味着如果要允许任何转码，则必须在订阅应答中包含 `allow transcoding`。 响应消息将简单地指示成功或失败。如果成功，媒体转发将开始指向 Answer SDP 中给出的端点。

找到2个链接：

https://github.com/sipwise/rtpengine/issues/1851

https://groups.google.com/g/rtpengine/c/ttErJ5QPfTY/m/eeWnSnqyAwAJ