전체 SDP에는 세션 설명이 하나만 있을 수 있지만 미디어 설명은 여러 개 있을 수 있습니다. 일반적으로 SDP에는 오디오 미디어 설명과 비디오 미디어 설명이라는 두 가지 미디어 설명이 포함됩니다. 세션 설명이 전체 SDP에 대한 제약 조건으로 작용하는 것을 제외하면 미디어 설명 간의 제약 조건은 서로 영향을 미치지 않습니다.

2. SDP 내용 및 유형

SDP 사양에서는 SDP의 구조를 정의하는 것 외에도 SDP의 내용도 규정합니다. 사양에서는 모든 설명이 동작 단위로 이루어져야 하며 설명 형식은 다음과 같습니다.

<type> = <value>

그 중 <type>은 단일 문자로 구성된 설명 대상을 나타내고, <value>는 <type>에 대한 해석 또는 제약을 나타낸다. 세션과 미디어 모두 고유한 <type>을 가지고 있습니다.

세션에 포함된 <type>에는 v(프로토콜 버전, 프로토콜 버전), o(소유자/생성자 및 세션 식별자, 세션 생성자), s(세션 이름, 세션 이름), t(세션이 활성화된 시간, 세션 기간)이 포함됩니다. ).
media에 포함되는 <type>은 주로 m(media, media)입니다.
위에서 소개한 <type> 외에도 public인 <type>도 있는데, 이러한 유형은 c(연결 정보, 네트워크 정보), a(속성, 속성)wait와 같이 세션과 미디어 모두에 나타날 수 있습니다. .

//会话描述
v=0
o=- 3409821183230872764 2 IN IP4 127.0.0.1
…
//媒体描述
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 …
…
a=rtpmap :111 opus /48000/2
a=rtpmap :103 ISAC /16000
a=rtpmap :104 ISAC /32000
…

2. WebRTC의 SDP 구조

실시간 오디오 및 비디오 통신을 달성하기 위해 WebRTC는 표준 SDP를 크게 조정했습니다. WebRTC의 SDP는 표준 SDP의 구조를 깨지 않으며 세션 설명과 미디어 설명이라는 두 부분도 포함합니다. 차이점은 자체 요구 사항을 충족하기 위해 미디어 설명의 콘텐츠를 크게 늘렸다는 것입니다.

기능에 따라 WebRTC에서 SDP의 미디어 설명 콘텐츠는 미디어 정보, 네트워크 설명, 보안 설명 및 서비스 품질 설명의 네 가지 범주로 나눌 수 있습니다.

1. 미디어 정보 설명

(1) SDP의 미디어 정보 형식

SDP의 미디어 정보의 특정 형식:

m=<media> <port>/<numbers> <transport> <fmt> …

<미디어>는 오디오, 비디오 등의 미디어 유형을 나타냅니다. 오디오 미디어 정보에 비해 비디오 미디어 정보는 더 복잡합니다.
<포트>/<번호>는 미디어에서 사용하는 포트 번호를 나타냅니다. WebRTC의 경우 SDP에 설명된 네트워크 정보를 사용하지 않으므로 이 포트 번호는 의미가 없습니다.
<transport>는 UDP, TCP 등 사용된 전송 프로토콜을 나타냅니다.
<fmt>는 미디어 데이터 유형을 나타내며, 일반적으로 PayloadType의 목록이며, 그 구체적인 의미는 "a=rtpmap:" 속성을 사용하여 더 자세히 설명할 필요가 있습니다.

WebRTC의 SDP에서 "a=rtpmap" 및 "a=fmtp" 속성은 어디에서나 볼 수 있습니다. 오디오 미디어든 비디오 미디어든 미디어를 더 자세히 설명하는 데 사용됩니다.

i. "a=rtpmap" 속성

rtpmap(rtp 맵)은 PayloadType 및 해당 매개변수에서 사용되는 코덱을 설명하는 데 사용됩니다. 해당 형식은 RFC4566에 정의되어 있습니다.

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]

ii. "a=fmtp" 속성

fmtp(형식 매개변수)는 미디어 데이터 형식을 지정하는 데 사용됩니다. "a=fmtp" 속성의 형식은 RFC4566의 섹션 6에도 rtpmap으로 정의되어 있습니다.

a=fmtp:<format> <format specific parameters>

(2) SSRC 및 CNAME

미디어 설명에는 오디오 미디어 정보, 비디오 미디어 정보 외에 SSRC(Synchronization Source)라는 중요한 콘텐츠도 포함됩니다. SSRC는 미디어 소스의 고유 식별자이며 각 미디어 스트림에는 이를 식별하는 고유한 SSRC가 있습니다.

Cname(표준 이름)은 일반적으로 별칭이라고 하며 도메인 이름 확인에 사용할 수 있습니다. 특정 도메인 이름에 대한 별칭을 만들고 싶을 때 사용할 수 있습니다. 예를 들어, 라이브 푸시/풀 스트리밍에서 특정 클라우드 공급자의 푸시 주소 push.xxx.yun.xxx.com을 자신의 주소 push.advancedu.com으로 바꾸려면 cname을 사용하면 됩니다. SDP에서 cname의 역할은 도메인 이름 확인의 역할과 동일합니다. 즉, 미디어 스트림에 대한 별칭을 제공합니다. 동일한 비디오 미디어 설명의 두 SSRC 뒤에는 동일한 cname이 옵니다. 이는 두 SSRC가 동일한 미디어 스트림에 속함을 나타냅니다.

(3) 예를 들어보자

...
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=rtpmap :111 opus /48000/2
a=rtcp -fb:111 transport -cc
a=fmtp :111 minptime =10; useinbandfec =1
a=rtpmap :103 ISAC /16000
a=rtpmap :104 ISAC /32000
a=rtpmap :9 G722 /8000
...
a=ssrc -group:FID 1531262201 2412323032
// 视频流的SSRC
a=ssrc :1531262201 cname:Hmks0 +2 NwywExB+s
…
// 丢包重传流的SSRC
a=ssrc :2412323032 cname:Hmks0 +2 NwywExB+s

1. 전송은 UDP/TLS/RTP/SAVFP이며, 하위 계층에서 사용되는 전송 프로토콜을 나타냅니다.

하위 계층은 전송 중에 UDP를 사용하고, DTLS 프로토콜은 UDP 위에서 인증서를 교환하는 데 사용됩니다. 인증서가 교환된 후 미디어 데이터는 RTP(RTP는 UDP에서 실행됨)를 통해 전송되어 전송의 신뢰성을 보장합니다. 오디오 및 비디오 데이터) )는 RTP 패킷의 Body 부분을 암호화하는 SRTP의 보안을 담당합니다. 또한, 혼잡 제어를 위해 전송 중 전송 정보에 대한 실시간 피드백(SAVPF)을 제공하기 위해 RTCP 피드백 메커니즘이 사용된다.

2. fmtlist의 값은 111부터 126까지의 숫자 문자열이며, 각 숫자는 PayloadType을 나타내며, 다른 PayloadType은 미디어 데이터가 다른 코덱 또는 코덱 매개변수를 사용함을 나타냅니다. 미디어 설명에는 "m=" 줄을 통해 명확하게 설명할 수 없고 "a=rtpmap"을 통해 추가로 설명해야 하는 세부정보가 여전히 많이 있습니다.

3. Payload Type 값이 111인 인코더는 Opus, 클럭 주파수(샘플링 레이트)는 48000, 오디오 채널 수는 2입니다. 마찬가지로 PayloadType 값이 103인 인코더는 ISAC이고 샘플링 속도는 16000이며, PayloadType 값이 104인 인코더도 ISAC이지만 샘플링 속도는 32000이 되고, PayloadType 값이 9인 인코더는 G722입니다. 샘플링 레이트는 8000인데...

4. a=fmtp :111 minptime =10; useinbandfec =1: PayloadType 값이 111인 데이터(Opus 데이터): 10ms 길이의 오디오 데이터는 프레임이고 데이터는 FEC(Forward Error Correction, Forward Error Correction)입니다. 인코딩되었습니다. 그 중 "usein bandfec=1"은 Opus용 WebRTC에서 추가한 fmtp 값입니다.

5. ssrc-group은 두 SSRC가 연관되어 있음을 나타내며, 후자의 SSRC(2412323032)는 이전 SSRC(1531262201)의 재전송 스트림이다. 즉, 1531262201은 실제로 비디오 스트림을 나타내는 SSRC이고, 2412323032는 비디오 스트림(1531262201)이 손실되었을 때 사용되는 SSRC이므로 동일한 미디어 설명에 두 개의 SSRC가 있습니다. 따라서 동일한 동영상 설명에 두 개의 SSRC가 있더라도 해당 동영상을 식별하는 SSRC는 여전히 하나만 있습니다.

6. SSRC 1531262201의 cname은 SSRC 2412323032의 cname과 정확히 동일합니다. 이는 두 SSRC가 동일한 미디어 스트림에 속함을 나타냅니다.

(4) 플랜B와 유니파이드플랜

현재 WebRTC의 SDP에는 PlanB와 UnifiedPlan이라는 두 가지 사양이 포함되어 있습니다. PlanB는 표준 SDP에서 발전한 것이며 UnifiedPlan은 PlanB를 대체하는 새로운 SDP 사양입니다.

PlanB 사양에는 오디오 미디어 설명(m=audio...)과 비디오 미디어 설명(m=video...)이라는 두 가지 미디어 설명만 있습니다. 여러 개의 비디오를 전송하려면 비디오 미디어 설명에서 SSRC로 구분해야 합니다.
UnifiedPlan에는 여러 개의 미디어 설명이 있을 수 있으므로 위의 다중 채널 비디오 상황에서는 여러 개의 비디오 미디어 설명(여러 줄 "m=video...")으로 분할될 수 있습니다.

2. 네트워크 설명

WebRTC는 일반적으로 UDP(사용자 데이터그램 프로토콜)를 사용하여 데이터를 전송합니다. UDP 위에 WebRTC는 RTP(실시간 전송 프로토콜)를 사용하여 오디오 및 비디오 데이터를 전송합니다. RTP 패킷은 헤더(Header)와 페이로드(Payload)의 두 부분으로 구성됩니다. 헤더에는 일련번호, 타임스탬프, 페이로드 유형 등과 같은 일부 메타데이터 정보가 포함되어 있습니다. 페이로드는 오디오 또는 비디오의 실제 데이터입니다.
이 UDP 기반 전송 방식은 더 낮은 대기 시간과 더 나은 실시간 성능을 제공할 수 있으며 음성 및 영상 통화, 실시간 스트리밍 미디어와 같은 실시간 통신 애플리케이션에 적합합니다.

RTP 메시지의 헤더(Header)에는 일반 헤더와 확장 헤더가 포함되며, 확장 헤더는 SDP에 저장된다. 예: "a=extmap", extmap은 확장 맵의 약어, 즉 RTP 헤더 확장 매핑 테이블입니다.

3. 보안 설명

WebRTC를 사용하는 오디오 및 비디오 통신 제품에는 세 가지 수준의 보호, 즉 애플리케이션 수준 보호, 신호 수준 보호 및 데이터 수준 보호가 있습니다.

(1) 애플리케이션 수준 보호

음성 및 영상 통신 제품을 사용할 때 일반적으로 사용자는 먼저 등록한 후 사용자 이름/비밀번호를 통해 응용 시스템에 로그인해야 합니다. 이 보호 수준을 애플리케이션 수준 보호라고 부르지 만 이 보호 수준은 WebRTC 범위에 속하지 않습니다 .

(2) 시그널링 레벨 보호

첫 번째 보호 수준을 통과한 후 사용자는 WebRTC 시그널링 서버의 주소를 획득하고 시그널링 서버를 통해 미디어 협상을 수행할 수 있습니다. 미디어 협상이 성공한 후 통신 중인 두 당사자는 서로의 SDP에서 서로의 사용자 이름/비밀번호, 즉 ice-ufrag 및 ice-pwd 정보를 얻을 수 있습니다. 이 두 정보의 기능은 사용자의 적법성을 확인하는 것입니다.전체 프로세스는 다음과 같습니다: 통신의 두 당사자는 STUN 바인딩 요청(ice-ufrag 및 ice-pwd 포함)을 서로에게 보냅니다. 상대방은 요청을 받으면 요청을 확인합니다. 포함된 ice-ufrag 및 ice-pwd가 자체 SDP의 내용과 일치하는지 여부가 일치하면 사용자가 합법적인 사용자임을 의미하고, 그렇지 않으면 불법 사용자라는 것입니다.

(3) 데이터 수준 보호

두 번째 보호 수준이 통과된 후 통신의 두 당사자는 DTLS 프로토콜을 사용하여 서로 인증서를 교환하며 인증서에 저장된 가장 중요한 정보는 공개 키입니다. 예를 들어, ClientA가 ClientB에게 미디어 데이터를 보낼 때 ClientA는 ClientB의 공개 키로 데이터를 암호화해야 하며, 암호화된 데이터는 SRTP로 패키징되어 ClientB로 전송됩니다. 수신 측(ClientB)은 자신의 개인 키를 사용해야 합니다. 암호화된 데이터를 암호화하는 키입니다.

(4) 예를 들어보자

…
m= …
…
a=ice -ufrag:kSq+
a=ice -pwd:MRW8liIi4S8OCRlM+SftfJWF
…
a=fingerprint:sha -256 DB:43:34:45:52:D3:78:A3:92:6E:BB:FB:83:2E:7F:22:49:5B:A7:73:D4:E1:52:1C:67:7F:7F:EA:95:F1:05:50
a=setup:actpass
…

a=ice-ufrag와 a=ice-pwd

ice-ufrag는 사용자 이름(사용자 이름)을 의미하고, ice-pwd는 비밀번호(비밀번호)를 의미하며, ice-ufrag 및 ice-pwd는 WebRTC 클라이언트가 유효한지 확인하는 데 사용됩니다.

a=지문

암호화 인증서의 유효성을 확인하는 데 사용됩니다. 통신 당사자가 DTLS 프로토콜을 통해 인증서를 교환하기 전에 각 끝은 먼저 자신의 인증서에 대한 지문을 생성한 다음 해당 지문을 SDP에 넣고 신호를 통해 상대방과 교환합니다. DTLS 프로토콜을 통해 인증서를 교환한 후 양측은 획득한 인증서에 대한 지문을 다시 생성합니다. 그런 다음 생성된 지문과 SDP에 있는 지문을 비교하여 두 개가 일치하면 전송 중에 인증서가 변조되지 않았음을 의미하므로 안심하고 사용할 수 있으며, 그렇지 않으면 인증서가 변조되었음을 의미합니다. , 현재 연결 생성이 실패합니다.

a=설정

DTLS 프로토콜을 사용하여 인증서를 교환할 때 WebRTC 끝점의 역할을 나타내는 데 사용됩니다. 각각 능동형, 수동형, 액트패스입니다.

active는 터미널의 역할이 클라이언트임을 나타냅니다.
Passive는 터미널의 역할이 서버임을 나타냅니다.
actpass(Active와 Passive의 조합)는 단말이 클라이언트이자 서버가 될 수 있으며 최종 역할은 상대방의 역할에 따라 결정됨을 나타냅니다.

일반적으로 방에 처음 참가하는 터미널은 기본적으로 actpass이고, 나중에 참가하는 터미널은 활성화됩니다. 따라서 "a=setup" 속성값을 통해 DTLS 프로토콜을 사용할 때 통신 당사자 중 어느 쪽이 클라이언트이고, 어느 쪽이 서버인지 알 수 있다.

4. 서비스 품질 설명

미디어 설명의 서비스 품질 설명은 "a=rtcp-fb" 속성으로 설명됩니다. WebRTC에서 rtcp-fb(rtcp 피드백)는 두 가지 의미를 가지고 있습니다: 하나는 RTCP 메시지의 피드백 정보 전용 메시지 유형을 의미하고, 다른 하나는 SDP에서 사용되는 "a=rtcp-fb" 속성을 의미하며, 이를 사용할 수 있습니다. WebRTC 터미널이 지원하는 rtcp 피드백 메시지를 설정합니다.

3. SDP의 완전한 예

1 // ===============================================
2 // SDP 会话描述
3 // ===============================================
4 // 版本信息
5 v=0
6 // 会话的创建者
7 o=- 8567802084787497323 2 IN IP4 127.0.0.1
8 // 会话名
9 s=-
10 // 会话时长
11 t=0 0
12 // 音视频传输采用多路复用方式， 通过同一个通道传输
13 // 这样可以减少对ICE 资源的消耗
14 a=group:BUNDLE 0 1
15 //WMS(WebRTC Media Stream)
16 // 因为上面的BUNDLE 使得音视频可以复用传输通道
17 // 所以WebRTC 定义一个媒体流来对音视频进行统一描述
18 // 媒体流中可以包含多路轨（ 音频轨、视频轨… … )
19 // 每个轨对应一个SSRC
20 a=msid -semantic: WM S 3eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
21 // ===============================================
22 // 音视频媒体描述
23 // ===============================================
24 // 音频媒体描述
25 // 端口9 忽略， 端口设置为0 表示不传输音频
26 m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
27 // 网络描述, 忽略!WebRTC 不使用该属性
28 c=IN IP4 0.0.0.0
29 // 忽略!WebRTC 不使用该属性
30 a=rtcp:9 IN IP4 0.0.0.0
31 // 用于ICE 有效用户的验证
32 // ufrag 表示用户名( 随机值)
33 a=ice -ufrag:r8+X
34 // 密码
35 a=ice -pwd:MdLpm2pegfysJ/VMCCGtZRpF
36 // 收信candidate 方式
37 a=ice -options:trickle
38 // 证书指纹， 用于验证DTLS 证书有效性
39 a=fingerprint:sha -256 53:08:1A:66:24: C7 :45:31:0A:EA:9E:59:97: A9 :15:3A:EC :60:1F:85:85:5B:B8:EC:D4 :77:78:9A:46:09:03:2A
40 // 用于指定DTLS 用户角色
41 a=setup:actpass
42 // BUNDLE 使用， 0 表示音频
43 a=mid:0
44 // 音频传输时RTP 支持的扩展头
45 // 发送端是否音频level 扩展， 可参考RFC6464
46 a=extmap :1 urn:ietf:params:rtp -hdrext:ssrc -audio -level
47 //NTP 时间扩展头
48 a=extmap :2 http://www.webrtc.org/experiments/rtp -hdrext/abs -send -time
49 //transport -CC 的扩展头
50 a=extmap :3 http://www.ietf.org/id/draft -holmer -rmcat -transport -wide -cc -extensions -01
51 // 与RTCP 中的SDES(Source Description) 相关的扩展头
52 // 通过RTCP 的SDES 传输mid
53 a=extmap :4 urn:ietf:params:rtp -hdrext:sdes:mid
54 // 通过RTCP 的SDES 传输rtp -stream -id
55 a=extmap :5 urn:ietf:params:rtp -hdrext:sdes:rtp -stream -id
56 // 通过RTCP 的SDES 传输重传时的rtp -stream -id
57 a=extmap :6 urn:ietf:params:rtp -hdrext:sdes:repaired -rtp -stream -id
58 // 音频数据传输方向
59 // sendrecv 既可以接收音频， 又可以发送音频
60 a=sendrecv
61 // 记录音频与媒体流的关系
62 a=msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt 67eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
63 //RTCP 与RTP 复用传输通道
64 a=rtcp -mux
65 //PT=111 代表音频编码器opus/ 采样率48000/ 双通道
66 a=rtpmap :111 opus /48000/2
67 // 使用Opus 时， 支持RTCP 中的Transport -CC 反馈报文
68 a=rtcp -fb:111 Transport -cc
69 // 使用Opus 时， 每个视频帧的最小间隔为10ms , 使用带内频率
70 a=fmtp :111 minptime =10; useinbandfec =1
71 //PT=103 代表音频编码器ISAC/ 采样率16000
72 a=rtpmap :103 ISAC /16000
73 //PT=104 代表音频编码器ISAC/ 采样率32000
74 a=rtpmap :104 ISAC /32000
75 //PT=9 代表音频编码器G722/ 采样率8000
76 a=rtpmap :9 G722 /8000
77 //PT=0 未压缩音频数据PCMU/ 采样率8000
78 a=rtpmap :0 P C M U/8000
79 //PT=8 未压缩音频数据PCMA/ 采样率8000
80 a=rtpmap :8 P C M A/8000
81 //PT=106 舒适噪声(Comfort Noise , CN)/ 采样率32000
82 a=rtpmap :106 CN /32000
83 //PT=106 舒适噪声/ 采样率16000
84 a=rtpmap :105 CN /16000
85 //PT=106 舒适噪声/ 采样率8000
86 a=rtpmap :13 CN /8000
87 //PT=110 SIP DTMF 电话按键/ 采样率48000
88 a=rtpmap :110 telephone -event /48000
89 //PT=112 SIP DTMF 电话按键/ 采样率32000
90 a=rtpmap :112 telephone -event /32000
91 //PT=113 SIP DTMF 电话按键/ 采样率16000
92 a=rtpmap :113 telephone -event /16000
93 //PT=116 SIP DTMF 电话按键/ 采样率8000
94 a=rtpmap :126 telephone -event /8000
95 // 源933825788 的别名
96 a=ssrc :933825788 cname:Tf3LnJwwJc0lgnxC
97 // 记录源SSRC 与音频轨和媒体流的关系
98 a=ssrc :933825788 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt 67eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
99 // 记录源SSRC :933825788 属于哪个媒体流
100 a=ssrc :933825788 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
101 // 记录源SSRC :933825788 属于哪个音频轨
102 a=ssrc :933825788 label :67 eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
103 // ===============================================
104 // 视频媒体描述
105 // ===============================================
106 // 视频媒体描述
107 m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107
108 109 124 119 123 108 // 网络描述, 忽略!WebRTC 不使用该属性
109 c=IN IP4 0.0.0.0
110 忽略!WebRTC 不使用该属性
111 a=rtcp:9 IN IP4 0.0.0.0
112 // 与音频一样， 用于验证用户的有效性
113 // 如果音视频复用传输通道， 只用其中一个即可
114 a=ice -ufrag:r8+X
115 a=ice -pwd:MdLpm2pegfysJ/VMCCGtZRpF
116 // 与音频一样， 设置收集Candidate 的方式
117 a=ice -options:trickle
118 // 证书指纹， 用于验证DTLS 证书有效性
119 a=fingerprint:sha -256 53:08:1A:66:24: C7 :45:31:0A:EA:9E:59:97: A9 :15:3A:EC :60:1F:85:85:5B:B8:EC:D4 :77:78:9A:46:09:03:2A
120 // 用于指定DTLS 用户角色
121 a=setup:actpass
122 // media id 1
123 a=mid:1
124 // 视频传输时RTP 支持的扩展头
125 // toffset(TransportTime Offset)
126 //RTP 包中的timestamp 与实际发送时的偏差
127 a=extmap :14 urn:ietf:params:rtp -hdrext:toffset
128 a=extmap :2 http://www.webrtc.org/experiments/rtp -hdrext/abs -send -time
129 // 视频旋转角度的扩展头
130 a=extmap :13 urn:3gpp:video -orientation
131 //Transport -CC 扩展头
132 a=extmap :3 http://www.ietf.org/id/draft -holmer -rmcat -transport -wide -cc -extensions -01
133 // 发送端控制接收端渲染视频的延时时间
134 a=extmap :12 http://www.webrtc.org/experiments/rtp -hdrext/playout -delay
135 // 指定视频的内容， 它有两种值： 未指定和屏幕共享
136 a=extmap :11 http://www.webrtc.org/experiments/rtp -hdrext/video -content -type
137 // 该扩展仅在每个视频帧最后一个包中出现
138 // 其存放6 个时间戳， 分别为：
139 //1. 编码开始时间
140 //2. 编码完成时间
141 //3. 打包完成时间
142 //4. 离开pacer 的最后一个包的时间
143 //5. 预留时间1
144 //6. 预留时间2
145 a=extmap :7 http://www.webrtc.org/experiments/rtp -hdrext/video -timing
146 a=extmap :8 http://www.webrtc.org/experiments/rtp -hdrext/color -space
147 // 携带mid 的扩展头
148 a=extmap :4 urn:ietf:params:rtp -hdrext:sdes:mid
149 // 携带rtp -stream -id 的扩展头
150 a=extmap :5 urn:ietf:params:rtp -hdrext:sdes:rtp -stream -id
151 // 重传时携带的rtp -stream -id 的扩展头
152 a=extmap :6 urn:ietf:params:rtp -hdrext:sdes:repaired -rtp -stream -id
153 // 视频数据传输方向
154 // sendrecv ， 既可以发送， 又可以接收视频数据
155 a=sendrecv
156 // media stream id
157 a=msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
158 //RTCP 与RTP 复用端口
159 a=rtcp -mux
160 // 减少RTCP 尺寸
161 a=rtcp -rsize
162 //PT=96 代表音频编码器VP8/ 采样率为90000
163 a=rtpmap :96 VP8 /90000
164 //PT=96 支持RTCP 协议中的Goog -REMB 反馈
165 a=rtcp -fb:96 goog -remb
166 //PT=96 支持RTCP 协议中的Transport -CC 反馈
167 a=rtcp -fb:96 transport -cc
168 //PT=96 支持RTCP 协议中的fir 反馈
169 a=rtcp -fb:96 ccm fir
170 //PT=96 支持RTCP 中的nack 反馈
171 a=rtcp -fb:96 nack
172 //PT=96 支持RTCP 中的pli 反馈
173 a=rtcp -fb:96 nack pli
174 //PT=97 代表重传数据/ 采样率为90000
175 a=rtpmap :97 rtx /90000
176 //PT=97 与96 是绑定关系， 说明97 是96 的重传数据
177 a=fmtp :97 apt =96
178 //PT=98 代表音频编码器VP9/ 采样率为90000
179 a=rtpmap :98 VP9 /90000
180 //PT=98 支持RTCP 中的Goog -REMB 反馈
181 a=rtcp -fb:98 goog -remb
182 //PT=98 支持RTCP 中的Transport -CC 反馈
183 a=rtcp -fb:98 transport -cc
184 //PT=98 支持RTCP 中的fir 反馈
185 a=rtcp -fb:98 ccm fir
186 //PT=98 支持RTCP 中的nack 反馈
187 a=rtcp -fb:98 nack
188 //PT=98 支持RTCP 中的pli 反馈
189 a=rtcp -fb:98 nack pli
190 // 使用VP9 时， 视频帧的profile id 为0
191 //VP9 一共有4 种profile 1,2,3,4
192 //0 表示支持8bit 位深
193 // 和YUV4 :2:0 格式
194 a=fmtp :98 profile -id=0
195 //PT=99 代表重传数据/ 采样率90000
196 a=rtpmap :99 rtx /90000
197 //PT=99 与98 是绑定关系， 因此99 是98 的重传数据
198 a=fmtp :99 apt =98
199 //PT=100 代表音频编码器VP9/ 采样率90000
200 a=rtpmap :100 VP9 /90000
201 //PT=100 支持RTCP 中的Goog -REMB 反馈
202 a=rtcp -fb:100 goog -remb
203 //PT=100 支持RTCP 中的Transport -CC 反馈
204 a=rtcp -fb:100 transport -cc
205 //PT=100 支持RTCP 中的fir 反馈
206 a=rtcp -fb:100 ccm fir
207 //PT=100 支持RTCP 中的nack 反馈
208 a=rtcp -fb:100 nack
209 //PT=100 支持RTCP 中的pli 反馈
210 a=rtcp -fb:100 nack pli
211 // 使用VP9 时， 视频帧的profile id 为2
212 //VP9 一共有4 种profile 1,2,3,4
213 //2 表示支持10bit 、12bit 位深
214 // 和YUV4 :2:0 格式
215 a=fmtp :100 profile -id=2
216 //PT=101 代表重传数据/ 采样率为90000
217 a=rtpmap :101 rtx /90000
218 //PT=101 与100 是绑定关系， 因此101 是100 的重传数据
219 a=fmtp :101 apt =100
220 //PT=102 代表音频编码器H264/ 采样率为90000
221 a=rtpmap :102 H264 /90000
222 //PT=102 支持RTCP 中的Goog -REMB 反馈
223 a=rtcp -fb:102 goog -remb
224 //PT=102 支持RTCP 中的Transport -CC 反馈
225 a=rtcp -fb:102 transport -cc
226 //PT=102 支持RTCP 中的fir 反馈
227 a=rtcp -fb:102 ccm fir
228 //PT=102 支持RTCP 中的nack 反馈
229 a=rtcp -fb:102 nack
230 //PT=102 支持RTCP 中的pli 反馈
231 a=rtcp -fb:102 nack pli
232 a=fmtp :102 level -asymmetry -allowed =1; packetization -mode =1; profile -level -id =42001f
233 //PT=121 代表重传数据/ 采样率为90000
234 a=rtpmap :121 rtx /90000
235 //PT=121 与102 是绑定关系， 因此121 是102 的重传数据
236 a=fmtp :121 apt =102
237 //PT=127 代表音频编码器H264/ 采样率为90000
238 a=rtpmap :127 H264 /90000
239 //PT=127 支持RTCP 中的Goog -REMB 反馈
240 a=rtcp -fb:127 goog -remb
241 //PT=127 支持RTCP 中的Transport -CC 反馈
242 a=rtcp -fb:127 transport -cc
243 //PT=127 支持RTCP 中的fir 反馈
244 a=rtcp -fb:127 ccm fir
245 //PT=127 支持RTCP 中的nack 反馈
246 a=rtcp -fb:127 nack
247 //PT=127 支持RTCP 中的pli 反馈
248 a=rtcp -fb:127 nack pli
249 a=fmtp :127 level -asymmetry -allowed =1; packetization -mode =0; profile -level -id =42001f
250 //PT=120 代表重传数据/ 采样率为90000
251 a=rtpmap :120 rtx /90000
252 //PT=127 与120 是绑定关系， 因此127 是120 的重传数据
253 a=fmtp :120 apt =127
254 //PT=125 代表音频编码器H264/ 采样率为90000
255 a=rtpmap :125 H264 /90000
256 //PT=125 支持RTCP 中的Goog -REMB 反馈
257 a=rtcp -fb:125 goog -remb
258 //PT=125 支持RTCP 中的Transport -CC 反馈
259 a=rtcp -fb:125 transport -cc
260 //PT=127 支持RTCP 中的fir 反馈
261 a=rtcp -fb:125 ccm fir
262 //PT=127 支持RTCP 中的nack 反馈
263 a=rtcp -fb:125 nack
264 //PT=127 支持RTCP 中的pli 反馈
265 a=rtcp -fb:125 nack pli
266 a=fmtp :125 level -asymmetry -allowed =1; packetization -mode =1; profile -level -id=42 e01f
267 //PT=107 代表重传数据/ 采样率为90000
268 a=rtpmap :107 rtx /90000
269 //PT=107 与125 是绑定关系， 因此177 是125 的重传数据
270 a=fmtp :107 apt =125
271 //PT=108 代表音频编码器H264/ 采样率为90000
272 a=rtpmap :108 H264 /90000
273 //PT=108 支持RTCP 中的Goog -REMB 反馈
274 a=rtcp -fb:108 goog -remb
275 //PT=108 支持RTCP 中的Transport -CC 反馈
276 a=rtcp -fb:108 transport -cc
277 //PT=108 支持RTCP 中的fir 反馈
278 a=rtcp -fb:108 ccm fir
279 //PT=108 支持RTCP 中的nack 反馈
280 a=rtcp -fb:108 nack
281 //PT=108 支持RTCP 中的pli 反馈
282 a=rtcp -fb:108 nack pli
283 a=fmtp :108 level -asymmetry -allowed =1; packetization -mode =0; profile -level -id=42 e01f
284 //PT=109 代表重传数据/ 采样率为90000
285 a=rtpmap :109 rtx /90000
286 //PT=109 与108 是绑定关系， 因此109 是108 的重传数据
287 a=fmtp :109 apt =108
288 //PT=124 代表视频使用red fec 技术/ 采样率为90000
289 a=rtpmap :124 red /90000
290 //PT=119 代表重传数据/ 采样率为90000
291 a=rtpmap :119 rtx /90000
292 //PT =1119 与124 是绑定关系， 因此119 是124 的重传数据
293 a=fmtp :119 apt =124
294 //PT=123 代表视频使用ulp fec 技术/ 采样率为90000
295 a=rtpmap :123 ulpfec /90000
296 //ssrc -group 表示几个源之间的关系
297 // 其格式为a=ssrc -group:<semantics > <ssrc -id > … 参考RFC5576
298 //FID(Flow ID), 表示这几个源都是数据流
299 // 其中， 1101026881 是正常的视频流
300 // 而后面的ssrc =35931176 是前面的ssrc 的重传流
301 a=ssrc -group:FID 1101026881 35931176
302 // 源1101026881 的别名为Tf3LnJwwJc0lgnxC
303 a=ssrc :1101026881 cname:Tf3LnJwwJc0lgnxC
304 // 下面的描述行指明了源1101026881 与媒体流ID(Media Stream ID) 和轨的关系
305 // 在一个媒体流中可以有多路轨(track), 每个轨对应一个ssrc
306 a=ssrc :1101026881 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
307 // 下面描述行指明了源1101026881 所属的媒体流的label(Media Stream lable)
308 a=ssrc :1101026881 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
309 // 下面描述行指明了源1101026881 对应的媒体轨， 同时它也是视频设备的label
310 a=ssrc :1101026881 label:f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
311 // 源35931176 的别名为Tf3LnJwwJc0lgnxC
312 a=ssrc :35931176 cname:Tf3LnJwwJc0lgnxC
313 // 下面的信息与源1101026881 的信息相同， 不做解释
314 a=ssrc :35931176 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
315 a=ssrc :35931176 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
316 a=ssrc :35931176 label:f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003

4. ORTC

SDP는 너무 "오래되었습니다". 이 프로토콜은 WebRTC와 같은 "새로운" 프로젝트에 도입되어서는 안 되었고 많은 사람들이 이에 대해 동일한 의구심을 제기해왔기 때문에 마이크로소프트가 이끄는 ORTC 조직은 SDP를 대체할 솔루션을 제안했습니다.

ORTC(Object Real-Time Communication)는 WebRTC 기반 애플리케이션 개발을 위한 매우 강력한 API를 제공합니다. 기본 계층에서는 더 이상 SDP를 사용하지 않으며 더 이상 Offer/Answer 메커니즘이 필요하지 않습니다. 대신 원본 SDP의 내용은 다음과 같습니다. Sender, Receiver, Transport 객체에 배치되어 있으며, 해당 객체를 통해 이전 작업이 완료됩니다.

WebRTC | SDP 세부정보

1. SDP 표준사양

1. SDP 구조