Offer/answer sip 中的模型根据 RFC3264

Question

我很难理解 RFC3264 中的陈述，它指定了 SIP 中使用的 offer/answer 模型。

第 2 页第 1 段第 1 章The answer has a matching media stream for each stream in the offer, indicating whether the stream is accepted or not..

因此，在 answer 中找到的每个流都会被分配一个匹配的流。这听起来像是一个副本，offer 完全或部分被复制到 answer 中。在我的理解中，匹配流必须看起来像流的副本。进一步引用："answer has that included"。所以描述了一个属性可以有一个单一的状态。 RFC 中没有一个关于不匹配流的声明，也没有关于答案中缺少流的声明。

另一方面，如果流被接受或不被接受，则会得到指示。这里我们有 2 态工件。

我想知道 1 态工件如何描述 2 态工件。

Answer 1

"media stream" 表示某些媒体源，例如音频、视频或其他内容。答案已经提供了多个流，并且答案必须对每个流都有一个回复。 "media stream" 的 "basic" 设置是 "m=" 行。

您可以在 RFC 的示例中看到这一点，例如：

10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000


   The callee, Bob, does not want to receive or send the first video
   stream, so he returns the SDP below as the answer:

   v=0
   o=bob 2890844730 2890844730 IN IP4 host.example.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 49920 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 0 RTP/AVP 31
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

您可以看到该优惠提供了三个流，1 个音频和 2 个视频，您可以从 "m=" 行中读取。

您还可以看到答案有三行 "m="（顺序相同）。由于“0”部分，拒绝接收视频流的 "m=video 0 RTP/AVP 31" 行。不需要更多行。

您还可以看到，这些行不是 "copies"，而是实际设置端点接受该媒体流的要求。唯一的 "copy" 是 "m=xxx" 订单。

Offer/answer sip 中的模型根据 RFC3264

Offer/answer model in sip according to RFC3264

model

sip

rfc