Question

我很难理解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状态伪像。

我不知道1状态伪像如何描述2状态伪像。

Answer 1

“媒体流”是指某些媒体来源，例如音频，视频或其他内容。答案具有多个流，并且答案必须对每个流都有答复。 “媒体流”的“基本”设置是“ 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

您可以看到，该报价包含三个流，可以从“ m =”行中读取1个音频和2个视频。

您还可以看到答案有三行“ m =”（按相同顺序）。由于“ 0”部分，拒绝接受的视频流报价中的“ m = video 0 RTP / AVP 31”行。不需要其他行。

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

根据RFC3264的Sip提供/答案模型

1 个答案: