时间戳

首页 > 解决方案 > 根据 RFC3264 在 sip 中提供/应答模型

model - 根据 RFC3264 在 sip 中提供/应答模型

问题描述

我很难理解 RFC3264 中的声明，它指定了 SIP 中使用的提供/应答模型。

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

因此，在回答中找到的每个流都会被分配一个匹配的流。这听起来像是一个副本，提议完全或部分被复制到答案中。据我了解，匹配流必须看起来像流的副本。更多引用：“答案包括在内”。所以描述了一个属性，它可以有一个单一的状态。RFC 中没有关于不匹配流的声明，也没有关于答案中缺少流的声明。

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

我想知道 1-state artifact 如何描述 2-state artifact。

标签： modelsiprfc

解决方案

“媒体流”是指一些媒体来源，如音频、视频或其他东西。答案已经提供了多个流，并且答案必须对每个流都有回复。“媒体流”的“基本”设置是“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”行拒绝接收视频流提议。不需要更多的行。

您还可以看到，这些行不是“副本”，而是实际上设置了该端点接受该媒体流的要求。唯一的“复制”是“m=xxx”顺序。

推荐阅读