WebRTC学习笔记五SDP（SessionDescript

　　SDP里面内容虽然很多，但是条理很清楚。SDP值为字符串，通过换行符生成一行一行的SDP报文，所有行可分为三类：全局行、音频行、视频行vVersion，版本，版本，应等于0oOrigin，源，包含一个唯一ID，用于重新协商sSessionName，会话名称，应等于tTiming，时间，应等于00mMediaDescription，媒体描述，下面有详细说明aAttribute，属性，一个自由文本字段，这是WebRTC中最常见的行cConnectionData，连接数据，应等于INIP40。0。0。0一、全局行
　　v0
　　sdp版本号，一直为0，rfc4566规定
　　o70176245868360677562INIP4127。0。0。1ousernamesessidsessversionnettypeunicastaddress
　　各字段含义如下：username：发起者的用户名，不允许存在空格，如果应用不支持用户名，则为。sessid：会话id，由应用自行定义，规范的建议是NTP（NetworkTimeProtocol）时间戳。sessversion：会话版本，用途由应用自行定义，只要会话数据发生变化时（比如编码），sessversion随着递增就行。同样的，规范的建议是NTP时间戳。nettype：网络类型，比如IN表示Internet。addrtype：地址类型，比如IP4、IV6unicastaddress：域名，或者IP地址。
　　s
　　会话名，没有的话使用代替
　　t00
　　它给出了开始和结束时间。当它们被设置为0时，意味着会话不受特定时间限制，换句话说，它在任何时候都是永久有效的。
　　agroup：BUNDLEaudiovideo
　　BUNDLE分组建立了SDP中包含的几个媒体线之间的关系，通常是音频和视频。在WebRTC中，它用于在相同的RTP会话中复用多个媒体流。在这种情况下，浏览器提供多路复用音频和视频，但另一方也必须支持和接受。如果没有这一行，音视频，数据就会分别单独用一个udp端口来发送
　　amsidsemantic：WMSh1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
　　WMS是WebRTCMediaStream简称，这一行定义了本客户端支持同时传输多个流，一个流可以包括多个track，一般定义了这个，后面assrc这一行就会有msid，mslabel等属性二、视频行2。1媒体描述
　　mvideo60372UDPTLSRTPSAVPF10010111611796
　　mvideo说明本会话包含音频，60372代表视频使用端口60372来传输，但是在webrtc中一现在一般不使用，如果设置为0，代表不传输音频，UDPTLSRTPSAVPF是表示用户来传输视频支持的协议，udp，tls，rtp代表使用udp来传输rtp包，并使用tls加密SAVPF代表使用srtcp的反馈机制来控制通信过程，后台10010111611796表示本会话视频支持的编码。mmediaportprotofmt。。。
　　其中：media：媒体类型。包括video、audio、text、application、message等。port：传输媒体流的端口，具体含义取决于使用的网络类型（在c中声明）和使用的协议（proto，在m中声明）。proto：传输协议，具体含义取决于c中定义的地址类型，比如c是IP4，那么这里的传输协议运行在IP4之上。比如：UDP：传输层协议是UDP。RTPAVP：针对视频、音频的RTP协议，跑在UDP之上。RTPSAVP：针对视频、音频的SRTP协议，跑在UDP之上。fmt：媒体格式的描述，可能有多个。根据proto的不同，fmt的含义也不同。比如proto为RTPSAVP时，fmt表示RTPpayload的类型。如果有多个，表示在这次会话中，多种payload类型可能会用到，且第一个为默认的payload类型。举例，下面表示媒体类型是视频，采用SRTP传输流媒体数据，且RTP包的类型可能是122、102。。。119，默认是122。mvideo9UDPTLSRTPSAVPF122102100101124120123119
　　对于RTPSAVP，需要注意的是，payloadtype又分两种类型：静态类型：参考RTPAVPaudioandvideopayloadtypes。动态类型：在afmtp：里进行定义。（a为附加属性，见后面小节）
　　举例，下面的SDP中：对于audio，111是动态类型，表示opus480002。对于video，122是动态类型，表示H26490000。maudio9UDPTLSRTPSAVPF111103104908126artpmap：111opus480002mvideo9UDPTLSRTPSAVPF122102100101124120123119artpmap：122H26490000
　　【腾讯文档】FFmpegWebRTCRTMPRTSPHLSRTP播放器音视频流媒体高级开发资料领取
　　FFmpegWebRTCRTMPRTSPHLSRTP鎾斁鍣闊宠棰戞祦濯掍綋楂樼骇寮鍙璧勬枡棰嗗彇2。2连接数据（c）
　　cINIP4217。130。243。155cnettypeconnectionaddress
　　每个SDP至少需要包含一个会话级别的c字段，或者在每个媒体描述后面各包含一个c字段。（媒体描述后的c会覆盖会话级别的c）nettype：网络类型，比如IN，表示Internet。addrtype：地址类型，比如IP4、IP6。connectionaddress：如果是广播，则为广播地址组；如果是单播，则为单播地址；
　　举例01：cINIP4224。2。36。42127
　　举例02：cINIP4host。anywhere。com2。3属性（a）
　　artcp：64891INIP4217。130。243。155a：value
　　属性（attribute）是扩展SDP的主要手段，分为会话级属性和媒体级属性：
　　（a）会话级属性：添加在第一个媒体描述之前，传达的信息适用于整个会议而不是单个媒体。agroup：BUNDLEaudiovideo通过mid标识符把多个媒体属性连接起来；amsidsemantic：WMSma表示是webrtc媒体流（WebrtcMediaStreams）；
　　（b）媒体级属性：媒体描述中添加有关媒体流的信息。amid：audio上述BUNDLE中用到的媒体标识；amsid：mata连接不同的媒体描述，使用相同的MediaStreams；asendonly表示媒体发送端，其他类型：recvonly，sendrecv，inactive；artcp：9INIP40。0。0。0用来传输rtcp地地址和端口；artcpmux表示rtp，rtcp包使用同一个端口来传输；aicexxx：xxxice协商过程中的安全验证信息；afingerprint：xxx表示dtls协商过程中需要的认证信息；asetup：actpass表示本客户端在dtls协商过程中，可以做客户端也可以做服务端；artpmap：111opus480002负载类型111，编码格式opus，48000是时钟，2是通道数；artcpfb：111nack支持丢包重传；artcpfb：111nackpli支持关键帧丢包重传；artcpfb：111transportcc表示opus编码支持使用rtcp来控制拥塞；afmtp：111minptime10；useinbandfec1；maxplaybackrate16000对opus编码可选的补充说明，minptime代表最小打包时长是10ms，useinbandfec1代表使用opus编码内置fec特性；assrc：1370113029cname：NMediaAudiocname用来标识一个数据源，ssrc当发生冲突时可能会发生变化，但是cname不会发生变化，也会出现在rtcp包中SDEC中，用于音视频同步；acandidate：11udp2013266431x。x。x。x43342typhostgeneration0表示候选人的传输地址，查看详情。2。1ICE候选者
　　acandidate：14672500271udp2122260223192。168。0。19656143typhostgeneration02。2ICE参数
　　aiceufrag：Oyef7uvBlwafI3hTaicepwd：T0teqPLNQQOf5WlsP2p162。3DTLS参数
　　afingerprint：sha25649：66：12：17：0D：1C：91：AE：57：4C：C6：36：DD：D5：97：D2：7D：62：C9：9A：7F：B9：A3：F4：70：03：E7：43：91：73：23：5Easetup：actpass2。4Codec参数
　　artpmap：100VP890000
　　这条线表示VP8与有效载荷类型100对齐。这意味着此会话中包含VP8视频帧的RTP数据包的有效载荷类型字段的值将为100。现在VP8是视频的MTI编解码器，未来可能会发生变化。
　　artcpfb：100ccmfir
　　指明使用全内帧请求（FullIntraframeRequest，FIR）
　　artcpfb：100nack
　　此行请求使用RFC4585中指示的否定ACK（nack）。这允许另一端知道数据包丢失。
　　artcpfb：100nackpli
　　此行表明支持PLINACKRTCP消息。这允许在视频包丢失时向另一端点请求新的VP8关键帧。
　　artcpfb：100googremb
　　它定义了RTCP消息对ReceiverEstimatedMaximumBitrate的使用。前缀goog意味着仍然只能由Google和非标准实现。
　　artpmap：101VP990000
　　Chrome支持版本48的VP9。您可以在WebM项目站点了解此视频编解码器的功能。默认情况下，它在VP8之后显示为SDP中的第二个选项。
　　artcpfb：101ccmfirartcpfb：101nackartcpfb：101nackpliartcpfb：101googrembartpmap：116red90000
　　该行请求使用RFC2198，其定义有效载荷格式以编码冗余媒体数据。在WebRTC中，这用于封装有效载荷VP8（视频有效载荷本身）和FEC（ForwardErrorCorrection）。
　　artpmap：117ulpfec90000
　　此行请求使用ULPFEC（在RFC5109中定义）。FEC（前向纠错）允许通过基于原始分组发送冗余信息来纠正数据传输中的某种错误。当丢包（在RTCPRR数据包中报告）时使用FEC。
　　artpmap：96rtx90000
　　参数rtx和apt在RFC4588中定义。该RFC定义了RTP有效载荷格式，仅用于执行另一方尚未接收的分组的重传。无法使用原始有效负载重新发送数据包，因为它会破坏RTP和RTCP机制，因此它们会在具有不同有效负载的重新传输流中重新传输。90000指的是重传流的时钟速率，其与原始VP8流相同，原始VP8流与其他视频协议90000相同。
　　afmtp：96apt100
　　该行表示具有有效载荷96的RTP分组将传输那些已经在该SDP（VP8）中对有效载荷100进行了编码的编解码器的rtx消息。2。5SSRC参数
　　assrcgroup：FID2231627014632943048
　　此行声明SSRC632943048是RFC5576中指定的2231627014的rtx修复流程
　　assrc：2231627014cname：4TOk42mSjXCkVIa6assrc：2231627014msid：lgsCFqt9kN2fVKw5wg3NKqGdATQoltEwOdMSdaed9400d0dd4db3b949422499e96e2dassrc：2231627014mslabel：lgsCFqt9kN2fVKw5wg3NKqGdATQoltEwOdMSassrc：2231627014label：daed9400d0dd4db3b949422499e96e2d
　　注：未特别说明，则与audio一致三、音频行
　　maudio9UDPTLSRTPSAVPF11110310490810610513126
　　maudio说明本会话包含音频，9代表音频使用端口9来传输，但是在webrtc中一现在一般不使用，如果设置为0，代表不传输音频，UDPTLSRTPSAVPF是表示用户来传输音频支持的协议，udp，tls，rtp代表使用udp来传输rtp包，并使用tls加密SAVPF代表使用srtcp的反馈机制来控制通信过程，后台11110310490810610513126表示本会话音频支持的编码。
　　cINIP40。0。0。0
　　这一行表示你要用来接收或者发送音频使用的IP地址，webrtc使用ice传输，不使用这个地址
　　artcp：9INIP40。0。0。0
　　明确指定传输RTCP的IP和端口，而不是从基础媒体端口派生的。请注意，与SRTP的端口相同，因为支持RTCPMultiplex。webrtc中不使用。
　　amid：audio
　　在前面BUNDLE这一行中用到的媒体标识。如果我们有不同的媒体，我们每个都应该有不同的标识符。
　　aextmap：1urn：ietf：params：rtphdrext：ssrcaudiolevel
　　此行定义将在RTP标头中使用的扩展，以便接收器可以正确解码并提取元数据。
　　asendrecv
　　上一行指出我是双向通信，另外几种类型是recvonly，sendonly，inactive。
　　artcpmux
　　指出rtp，rtcp包使用同一个端口来传输3。1ICE候选者
　　acandidate：14672500271udp2122260223192。168。0。19646243typhostgeneration0
　　acandidate：14672500272udp2122260222192。168。0。19656280typhostgeneration0
　　UDP上RTP的主机候选者在此ICE行中，我们的浏览器为其主机候选者浏览器正在计算机上监听的接口或接口的IP。浏览器可以在该IP上接收发送SRTP和SRTCP，以防远程对等端的候选者具有IP可见性。例如，如果另一台计算机位于同一LAN上，则将使用主机候选项。协议（udp）2122260223之后的数字是候选者的优先级。请注意，宿主候选者的优先级高于其他候选者，因为使用宿主候选者在资源使用方面更有效。第一行（component1）用于RTP，第二行（component2）用于RTCP。请注意，浏览器不知道另一端是否支持rtcpmux，因此它必须在要约中包含RTCP端口。
　　acandidate：4356530191tcp1845501695192。168。0。1960typhosttcptypeactivegeneration0
　　acandidate：4356530192tcp1845501695192。168。0。1960typhosttcptypeactivegeneration0
　　TCP上RTP的主机候选者这些线路与之前的两条ICE线路相同，但是对于TCP流量。请注意，优先级较低即1845501695较大因为TCP不是实时媒体传输的最佳选择。
　　acandidate：18538876741udp151828044747。61。61。6136768typsrflxraddr192。168。0。196rport36768generation0
　　acandidate：18538876742udp151828044747。61。61。6136768typsrflxraddr192。168。0。196rport36768generation0
　　UDP上RTP的自反性候选者（reflexivecandidates）这里我们有服务器反身候选人。请注意，它们的优先级低于主机候选者。这些候选人是由STUN服务器发现的。
　　acandidate：7509918562udp25108222237。30。30。3051472typrelayraddr47。61。61。61rport54763generation0
　　acandidate：7509918561udp25108223237。30。30。3058779typrelayraddr47。61。61。61rport54761generation0
　　UDP上RTP的中继候选者（Relaycandidates）接下来我们有中继候选。这些候选者是从TURN服务器获得的，必须在创建对等连接时进行配置。请注意，此处的优先级低于主机和反射候选者（25108222更高），因此仅当主机和反射候选者之间没有IP连接时才使用中继。3。2ICE参数
　　aiceufrag：khLS
　　aicepwd：cxLzteJaJBou3DspNaPsJhlQ
　　以上两行是ice协商过程中的安全验证信息3。3DTLS参数
　　afingerprint：sha256FA：14：42：3B：C7：97：1B：E8：AE：0C2：71：03：05：05：16：8F：B9：C7：98：E9：60：43：4B：5B：2C：28：EE：5C：8F3：17
　　此指纹是DTLSSRTP协商中使用的证书的哈希函数的结果。此行在信令（应该是可信的）和DTLS中使用的证书之间创建绑定，如果指纹不匹配，则应拒绝会话。
　　asetup：actpass
　　代表本客户端在dtls协商过程中，可以做客户端也可以做服务端3。4Codec参数
　　artpmap：111opus480002
　　Opus是WebRTC的MTI音频编解码器之一。它具有可变比特率（6kbps510kbps），并且不受任何版税限制，因此可以在任何浏览器中自由实现。Opus支持开始变得普遍，它已成为大多数WebRTC应用程序的关键。
　　afmtp：111minptime10；useinbandfec1
　　此行包括Chrome支持的音频Opus编解码器的可选有效载荷格式特定参数。minipitime10指定分组化时间的最低值（ptime：由单个分组传输的音频的毫秒数）。useinbandfec1指定解码器能够利用Opus带内FEC（前向错误连接）。
　　artpmap：103ISAC16000
　　ISAC（互联网语音音频编解码器）是用于高质量会议的宽带语音编解码器。16000表示ISAC将以16kbps的速度使用。
　　artpmap：104ISAC32000
　　32000表示ISAC将以32kbps的速度使用。
　　artpmap：9G7228000
　　G722是一款工作频率为48，56和64kbits的宽带音频编解码器，与G。711等窄带语音编码器相比，由于507000Hz的语音带宽更宽，因此可提供更高的语音质量。
　　artpmap：0PCMU8000
　　artpmap：8PCMA8000
　　这是使用不同压扩法则的经典电信64kbps脉冲编码调制（PCM）编解码器。0和8分别是PCMU和PCMA的静态有效载荷类型。从技术上讲，这些线路不存在，因为这些信息可以通过媒体线中的编解码器列表PCMU或PCMA来推断。
　　artpmap：106CN32000
　　artpmap：105CN16000
　　artpmap：13CN8000
　　上面的动态RTP有效载荷类型（除了有效载荷类型13，它是静态的）表示舒适噪声（ComfortNoise，CN）将用于速率为48000，32000，16000和8000kbitss的编解码器。
　　artpmap：126telephoneevent8000
　　此行表示浏览器支持RFC4733，允许它在RTP内发送DTMF，而不是通常的数字化正弦波，而是作为特殊有效载荷（在这种情况下，RTP数据包中有效载荷126）。该DTMF机制确保DTMF将独立于音频编解码器和信令协议进行传输。
　　amaxptime：60
　　maxptime指定可以封装在每个数据包中的最大媒体数量，以毫秒为单位表示。数据包的大小可能会对音频和BW的质量产生副作用。可以在SDP中修改此值。3。5SSRC参数
　　assrc：3570614608cname：4TOk42mSjXCkVIa6
　　cname源属性将媒体源与其Canonical端点标识符相关联，即使在发现冲突时ssrc标识符发生更改，该标准端点标识符也将保持RTP媒体流的常量。这是媒体发送方将在其RTCPSDES数据包中放置的值。
　　assrc：3570614608msid：lgsCFqt9kN2fVKw5wg3NKqGdATQoltEwOdMS35429d94563746869ecd7d0622261ce8
　　该线用于使用SDP信令通知SSRC的RTP概念与媒体流媒体流轨道的WebRTC概念之间的关联。第一个参数对应于媒体流（mediastream）的id，第二个参数对应于媒体流轨道的if。这些ID在WebRTCAPI中处理。第一个数字是SSRC标识符，它将包含在RTP数据包的SSRC字段中。
　　assrc：3570614608mslabel：lgsCFqt9kN2fVKw5wg3NKqGdATQoltEwOdMS
　　label属性指的是MediaStream对象的id。不推荐使用该参数，并将msid替换为该参数。标签是为了向后兼容而保留。
　　assrc：3570614608label：35429d94563746869ecd7d0622261ce8
　　label属性也被msid弃用，并在使用SDP的任意网络应用程序的上下文中携带指向RTP媒体流的指针。此标签与WebRTCAPI中的MediaStreamTrackID相对应，该ID包含在msid行中。四、WebRTC实例
　　下面例子来自腾讯云WebRTC服务的远端offer。sdp版本号为0v0ousernamesessidsessversionnettypeunicastaddress用户名为空，会话id是8100750360520823155，会话版本是2（后面如果有类似改变编码的操作，sessversion加1），地址类型为IP4，地址为127。0。0。1（这里可以忽略）o75956558019786804532INIP4112。90。139。105会话名为空s会话的起始时间，都为0表示没有限制t00aicelite音频、视频的传输的传输采取多路复用，通过同一个RTP通道传输音频、视频，可以参考https：tools。ietf。orghtmldraftietfmmusicsdpbundlenegotiation54agroup：BUNDLE01WMS是WebRTCMediaStram的缩写，这里给MediaStream定义了一个唯一的标识符。一个MediaStream可以有多个track（videotrack、audiotrack），这些track就是通过这个唯一标识符关联起来的，具体见下面的媒体行（m）以及它对应的附加属性（assrc：）可以参考这里http：tools。ietf。orghtmldraftietfmmusicmsidamsidsemantic：WMS5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPVmmediaportprotofmt。。。本次会话有音频，端口为9（可忽略，端口9为DiscardProtocol专用），采用UDP传输加密的RTP包，并使用基于SRTCP的音视频反馈机制来提升传输质量，111、103、104等是audio可能采用的编码（参见前面m的说明）maudio9UDPTLSRTPSAVPF111103104908126音频发送者的IP4地址，WebRTC采用ICE，这里的0。0。0。0可直接忽略cINIP40。0。0。0RTCP采用的端口、IP地址（可忽略）artcp：9INIP40。0。0。0iceufrag、icepwd分别为ICE协商用到的认证信息aiceufrag：58142170598604946aicepwd：71696ad0528c4adb02bb40e1DTLS协商过程的指纹信息afingerprint：sha2567F：98：08：AC：17：6A：34：DB：CF：3B：EC：93：ED：57：3F：5A：9E：1F：4A：F3：DB：D5：BF：66：EE：17：58：E0：57：EC：1B：19当前客户端在DTLS协商过程中，既可以作为客户端，也可以作为服务端，具体可参考RFC4572asetup：actpass当前媒体行的标识符（在agroup：BUNDLE01这行里面用到，这里0表示audio）amid：0RTP允许扩展首部，这里表示采用了RFC6464定义的针对audio的扩展首部，用来调节音量，比如在大型会议中，有多个音频流，就可以用这个来调整音频混流的策略这里没有vad1，表示不启用这个音量控制aextmap：1urn：ietf：params：rtphdrext：ssrcaudiolevel表示既可以发送音频，也可以接收音频asendrecv表示启用多路复用，RTP、RTCP共用同个通道artcpmux下面几行都是对audio媒体行的补充说明（针对111），包括rtpmap、rtcpfb、fmtprtpmap：编解码器为opus，采样率是48000，2声道artpmap：111opus480002rtcpfb：基于RTCP的反馈控制机制，可以参考https：tools。ietf。orghtmlrfc5124、https：webrtc。orgexperimentsrtphdrexttransportwidecc02artcpfb：111transportccartcpfb：111nack最小的音频打包时间afmtp：111minptime20跟前面的rtpmap类似artpmap：126telephoneevent8000ssrc用来对媒体进行描述，格式为assrc：ssrcid：value，具体可参考RFC5576cname用来唯一标识媒体的数据源assrc：16864608cname：YZcxBwerFFm6GH69msid后面带两个id，第一个是MediaStream的id，第二个是audiotrack的id（跟后面的mslabel、label对应）assrc：16864608msid：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV128f4fa081dd4c3abbcd22e71e29d178assrc：16864608mslabel：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPVassrc：16864608label：128f4fa081dd4c3abbcd22e71e29d178跟audio类似，不赘述mvideo9UDPTLSRTPSAVPF122102125107124120123119cINIP40。0。0。0artcp：9INIP40。0。0。0aiceufrag：58142170598604946aicepwd：71696ad0528c4adb02bb40e1afingerprint：sha2567F：98：08：AC：17：6A：34：DB：CF：3B：EC：93：ED：57：3F：5A：9E：1F：4A：F3：DB：D5：BF：66：EE：17：58：E0：57：EC：1B：19asetup：actpassamid：1aextmap：2urn：ietf：params：rtphdrext：toffsetaextmap：3http：www。webrtc。orgexperimentsrtphdrextabssendtimeaextmap：4urn：3gpp：videoorientationaextmap：5http：www。ietf。orgiddraftholmerrmcattransportwideccextensions01aextmap：6http：www。webrtc。orgexperimentsrtphdrextplayoutdelayasendrecvartcpmuxartcprsizeartpmap：122H26490000artcpfb：122ccmfirartcpfb：122nackartcpfb：122nackpliartcpfb：122googrembartcpfb：122transportccafmtp：122levelasymmetryallowed1；packetizationmode1；profilelevelid42001fartpmap：102rtx90000afmtp：102apt122artpmap：125H26490000artcpfb：125ccmfirartcpfb：125nackartcpfb：125nackpliartcpfb：125googrembartcpfb：125transportccafmtp：125levelasymmetryallowed1；packetizationmode1；profilelevelid42e01fartpmap：107rtx90000afmtp：107apt125artpmap：124H26490000artcpfb：124ccmfirartcpfb：124nackartcpfb：124nackpliartcpfb：124googrembartcpfb：124transportccafmtp：124levelasymmetryallowed1；packetizationmode1；profilelevelid4d0032artpmap：120rtx90000afmtp：120apt124artpmap：123H26490000artcpfb：123ccmfirartcpfb：123nackartcpfb：123nackpliartcpfb：123googrembartcpfb：123transportccafmtp：123levelasymmetryallowed1；packetizationmode1；profilelevelid640032artpmap：119rtx90000afmtp：119apt123assrcgroup：FID3371880950483271assrc：33718809cname：ovaCctnHP9Asci9cassrc：33718809msid：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV1d7fc30098894f949f35c0bcc77a260dassrc：33718809mslabel：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPVassrc：33718809label：1d7fc30098894f949f35c0bcc77a260dassrc：50483271cname：ovaCctnHP9Asci9cassrc：50483271msid：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV1d7fc30098894f949f35c0bcc77a260dassrc：50483271mslabel：5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPVassrc：50483271label：1d7fc30098894f949f35c0bcc77a260d五、Uncaught（inpromise）DOMException：Answertriedtosetrecvwhenofferdidnotsetsend
　　chrome中可以播放，firefox报错
　　搜索一下，参考https：stackoverflow。comquestions35166456
　　RFC3264：Ifamediastreamislistedasrecvonlyintheoffer，theanswerMUSTbemarkedassendonlyorinactiveintheanswer。
　　这里可以参考SDP模型介绍，获取更详细的知识1。情态动词术语解释MUST必须、一定要；MUSTNOT禁止；REQUIRED需要；SHALL、SHOULD应该；SHALLNOT、SHOULDNOT不应该；RECOMMENDED推荐；MAY可以
　　以上情态动词术语可参考RFC2119〔3〕，这些动词要求我们在产品实现时，需要遵守或灵活变更约束。2。初始协商的Offer请求
　　实体A实体B，实体首先发起Offer请求，内容如2节所示，对于作何一个媒体流媒体通道，这时实体A必须：如果媒体流方向标为recvonlysendrecv，即arecvonly或asendrecv，则A必须（MUST）准备好在这个IP和端口上接收实体B发来的媒体流；如果媒体流方向标为sendonlyinactive，即arecvonly或asendrecv，则A不需要进行准备。3。Answer响应
　　实体B收到A的请求offer后，根据自身支持的媒体类型和编码策略，回复响应。如果实体B回复的响应中的媒体流数量和顺序必须（MUST）和请求offer一致，以便实体A进行甄别和决策。即m行的数量和顺序必须一致，B不能（MUSTNOT）擅自增加或删除媒体流。如果B不支持某个媒体流，可以在对应的端口置0，但不能不带这个m行描述。对于某种媒体，实体B必须（MUST）从请求offer中选出A支持且自己也支持的该媒体的编码标识集，并且可以（MAY）附带自己支持的其它类型编码。对于响应消息中各个媒体的方向：如果请求某媒体流的方向为sendonly，那么响应中对应媒体的方向必须为recvonly；如果请求某媒体流的方向为recvonly，那么响应中对应媒体的方向必须为sendonly；如果请求某媒体流的方向为sendrecv，那么响应中对应媒体的方向可以为sendrecvsendonlyrecvonlyinactive中的一种；如果请求某媒体流的方向为inactive，那么响应中对应媒体的方向必须为inactive；响应answer里提供IP和端口，指示Offerer本端期望用于接收媒体流的IP和端口，一旦响应发出之后，Offerer必须（MUST）准备好在这个IP和端口上接收实体A发来的媒体流。如果请求offer中带了ptime（媒体流打包间隔）的a行或带宽的a行，则响应answer也应该（SHOULD）相应的携带。实体BOfferer应该（SHOULD）使用实体A比较期望的编码生成媒体流发送。一般来说对于m行，如mvideo0RTPAVP3134，排充越靠前的编码表示该实体越希望以这个编码作为载体，这里示例31（H261），34（H263）中H261为A更期望使用的编码类型。同理，当实体A收到响应answer后也是这样理解的。4。实体收到响应后的处理
　　当实体A收到B回复的响应后，可以（MAY）开始发送媒体流，如果媒体流方向为sendonlysendrecv，必须（MUST）使用answer列举的媒体类型编码生成媒体发送；应该（SHOULD）使用answer中的ptime和bandwidth来打包发送媒体流；可以（MAY）立即停止监听端口，该端口为offer支持answer不支持的媒体所使用的端口。5。修改媒体流（会话）
　　修改媒体流的offeranswer操作必须基于之前协商的媒体形式（音频、视频等），不能（MUSTNOT）对已有媒体流进行删减。
　　（a）删除媒体流如果实体认定新的会话不支持之前媒商的某个媒体，新的offer只须对这种媒体所在m行的端口置0，但不能不描述这种媒体，即不带对应m行。当answerer收到响应之后，处理同初始协商一样。
　　（b）增加媒体流如果实体打算新增媒体流，在offer里只须加上描述即可或者占用之前端口被置0的媒体流，即用新的媒体描述m行替换旧的。当answerer收到offer请求后，发现有新增媒体描述，或者过于端口被置0的媒体行被新的媒体描述替换，即知道当前为新增媒体流，处理同初始协商。
　　（c）修改媒体流修改媒体注主要是针对初始协商结果，如果有变更即进入修改流程处理，可能的变更包括IP地址、端口，媒体格式（编码），媒体类型（音、视频），媒体属性（ptime，bandwidth，媒体流方向变更等）。6。解决问题：
　　查看请求offer发送的Sdp，发现在没有设置的情况下，全是默认的recvonly。maudio。。。。。。arecvonly。。。mvideo。。。arecvonly
　　而服务器返回的maudio。。。。。。arecvonly。。。mvideo。。。asendrecv
　　参照上述要求，可以将请求offer设置成sendrecv即可解决firefox中的报错this。pc。addTransceiver（video，｛direction：sendrecv｝）；this。pc。addTransceiver（audio，｛direction：sendrecv｝）；7。Transceivers
　　Transceiversareforsendingandreceiving
　　TransceiversisaWebRTCspecificconceptthatyouwillseeintheAPI。Whatitisdoingisexposingthe‘MediaDescription’totheJavaScriptAPI。EachMediaDescriptionbecomesaTransceiver。EverytimeyoucreateaTransceiveranewMediaDescriptionisaddedtothelocalSessionDescription。
　　EachMediaDescriptioninWebRTCwillhaveadirectionattribute。ThisallowsaWebRTCAgenttodeclare‘Iamgoingtosendyouthiscodec，butIamnotwillingtoacceptanythingback’。Therearefourvalidvalues：sendrecvsendrecvinactive