WebRTC通话原理(六)，2024年最新4年前端面试题

最新推荐文章于 2024-05-11 23:47:15 发布

2401_83974173

最新推荐文章于 2024-05-11 23:47:15 发布

阅读量775

点赞数 11

分类专栏： 2024年程序员学习文章标签： webrtc 前端

本文链接：https://blog.csdn.net/2401_83974173/article/details/137589919

版权

2024年程序员学习专栏收录该内容

262 篇文章 0 订阅

订阅专栏

//WebRTC Media Stream

a=msid-semantic: WMS

//m=audio说明本会话包含音频，9代表音频使用端口9来传输，但是在webrtc中现在一般不使用，如果设置为0，代表不传输音频

//使用UDP来传输RTP包，并使用TLS加密, SAVPF代表使用srtcp的反馈机制来控制通信过程

//111 103 104 9 0 8 106 105 13 110 112 113 126表示支持的编码，和后面的a=rtpmap对应

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126

//表示你要用来接收或者发送音频使用的IP地址, webrtc使用ICE传输，不使用这个地址, 关于ICE是什么后面2.5节会讲到

c=IN IP4 0.0.0.0

//用来传输rtcp的地址和端口，webrtc中不使用

a=rtcp:9 IN IP4 0.0.0.0

//ICE协商过程中的安全验证信息

a=ice-ufrag:ubhd

a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B

//支持trickle，即sdp里面只描述媒体信息, ICE候选项的信息另行通知

a=ice-options:trickle

//dtls协商过程中需要的认证信息

a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7

a=setup:active

//前面BUNDLE行中用到的媒体标识

a=mid:audio

//指出要在rtp头部中加入音量信息

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

//当前客户端只接受数据，不发送数据，recvonly,sendonly,inactive,sendrecv

a=recvonly

//rtp,rtcp包使用同一个端口来传输

a=rtcp-mux

//下面都是对m=audio这一行的媒体编码补充说明，指出了编码采用的编号、采样率、声道等

a=rtpmap:111 opus/48000/2

a=rtcp-fb:111 transport-cc

//对opus编码可选的补充说明，minptime代表最小打包时长是10ms，useinbandfec=1代表使用opus编码内置fec特性

a=fmtp:111 minptime=10;useinbandfec=1

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:106 CN/32000

a=rtpmap:105 CN/16000

a=rtpmap:13 CN/8000

a=rtpmap:110 telephone-event/48000

a=rtpmap:112 telephone-event/32000

a=rtpmap:113 telephone-event/16000

a=rtpmap:126 telephone-event/8000

//下面就是对Data Channel的描述，基本和上面的audio描述类似，使用DTLS加密，使用SCTP传输

m=application 9 DTLS/SCTP 5000

c=IN IP4 0.0.0.0

//可以是CT或AS，CT方式是设置整个会议的带宽，AS是设置单个会话的带宽。默认带宽是kbps

b=AS:30

a=ice-ufrag:ubhd

a=ice-pwd:l82NnsGm5i7pucQRchNdjA6B

a=ice-options:trickle

a=fingerprint:sha-256 CA:83:D0:0F:3B:27:4C:8F:F4:DB:34:58:AC:A6:5D:36:01:07:9F:2B:1D:95:29:AD:0C:F8:08:68:34:D8:62:A7

a=setup:active

//前面BUNDLE行中用到的媒体标识

a=mid:data

//使用端口5000，一个消息的大小是1024比特

a=sctpmap:5000 webrtc-datachannel 1024

以上就是一个SessionDescription的例子，虽然没有video的描述，但是video和audio的描述是十分类似的。 SDP中有关于IP和端口的描述，但是WebRTC技术并没有使用这些内容，那么双方是怎么建立“直接”连接的呢？建立起连接最关键的IP和端口是从哪里来的呢？这就需要ICE框架来完成这部分工作（参见后面的2.5节）。

注意：SDP由一行或多行UTF-8文本组成，每行以一个字符的类型开头，后跟等号（“ =”），然后是包含值或描述的结构化文本，其格式取决于类型。以给定字母开头的文本行通常称为“字母行”。例如，提供媒体描述的行的类型为“ m”，因此这些行称为“ m行”。

网络协商

彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路。需要做以下两个处理。

获取外网IP地址映射。
通过信令服务器(signal server)交换“网络信息”。

理想的网络情况是每个浏览器的电脑都是公网IP，可以直接进行点对点连接。如图所示。

在这里插入图片描述

实际情况是我们的电脑和电脑之间都是在某个局域网中并且有防火墙，需要NAT(Network Address Translation，网络地址转换)，如图所示。在这里插入图片描述

在解决WebRTC使用过程中的上述问题的时候，我们需要用到STUN和TURN。

NAT

NAT（Network Address Translation，网络地址转换）简单来说就是为了解决IPV4下的IP地址匮乏而出现的一种技术。举例就是通常我们处在一个路由器之下，而路由器分配给我们的地址通常为192.168.1.1 、192.168.1.2如果有n个设备，可能分配到192.168.1.n，而这个IP地址显然只是一个内网的IP地址，这样一个路由器的公网地址对应了n个内网的地址，通过这种使用少量的公有IP 地址代表较多的私有IP 地址的方式，将有助于减缓可用的IP地址空间的枯竭。如图所示。

在这里插入图片描述

NAT技术会保护内网地址的安全性，所以这就会引发个问题，就是当我采用P2P之中连接方式的时候，NAT会阻止外网地址的访问，这时我们就得采用NAT穿透了。于是我们就有了如下的思路：我们借助一个公网IP服务器，Peer-A与Peer-B都往公网IP/PORT发包,公网服务器就可以获知Peer-A与Peer-B的IP/PORT，又由于Peer-A与Peer-B主动给公网IP服务器发包，所以公网服务器可以穿透NAT-A与NAT-B并发送包给Peer-A与Peer-B。所以只要公网IP将Peer-B的IP/PORT发给Peer-A，Peer-A的IP/PORT发给Peer-B。这样下次Peer-A与Peer-B互相消息，就不会被NAT阻拦了。 WebRTC的NAT/防火墙穿越技术，就是基于上述的一个思路来实现的。在WebRTC中采用ICE框架来保证RTCPeerConnection能实现NAT穿越。