Вступление
С этого момента я буду пробовать читать сообщения ответов.
Большинство строк такие же, как и в сообщениях предложения, потому что сообщения ответа составляются в соответствии с сообщением предложения.
- [Pion/WebRTC] Попробуйте прочитать сообщения предложения
Я думаю, что основное различие между предложениями и ответами — это добавление msid-semantic и ssrc.
Поэтому я попробую прочитать их.
msid-semantic
Строка «a=msid-semantic:~» добавлена в секцию уровня сессии.
Ответное сообщение SDP
v=0
o=- 8405074721153909150 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2
a=extmap-allow-mixed
a=msid-semantic: WMS tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S
Этот атрибут имеет групповой идентификатор(tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S) и групповую семантику(WMS:WebRTC Media Stream).
Значение идентификатора совпадает с MediaStream ID клиента, отправившего ответ.
Согласно приведенному ниже документу, этот атрибут предназначен для использования «a=msid:~» для WebRTC Media Stream.
- SDP для WebRTC — SlideShare
Но этот атрибут упоминается только в старых черновиках.
Поэтому я думаю, что этот атрибут может изменить формат или быть удален в будущем.
- Идентификация медиапотока WebRTC в протоколе описания сессии (draft-ietf-mmusic-msid-05)
Кроме того, формат идентификатора группы варьируется от клиента к клиенту.
Firefox
a=msid-semantic: WMS *
microsoft/MixedReality-WebRTC(https://github.com/microsoft/MixedReality-WebRTC)
a=msid-semantic: WMS
ssrc(Источник синхронизации)
Строки «a=ssrc-group:~» и «a=ssrc:~» добавлены в секции описания медиа (Видео, Аудио).
Ответное сообщение SDP
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 102 121 127 120 125 107 108 109 123 118 116
...
a=msid:tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S e246d6fc-71e2-4eaa-9e44-0a6e1793fd12
...
a=ssrc-group:FID 3413810401 2077638419
a=ssrc:3413810401 cname:nGUZl+/ZMBsWAlSN
a=ssrc:3413810401 msid:tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S e246d6fc-71e2-4eaa-9e44-0a6e1793fd12
a=ssrc:2077638419 cname:nGUZl+/ZMBsWAlSN
a=ssrc:2077638419 msid:tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S e246d6fc-71e2-4eaa-9e44-0a6e1793fd12
m=audio 9 UDP/TLS/RTP/SAVPF 111 9 0 8
...
a=msid:tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S 9c775cf1-6300-4535-8e38-73760a8a3f37
...
a=ssrc:1964009319 cname:nGUZl+/ZMBsWAlSN
a=ssrc:1964009319 msid:tJtqHKSvpmU907ayq0TVoHEXZKasH43rfz0S 9c775cf1-6300-4535-8e38-73760a8a3f37
...
«ssrc» служит для идентификации каждого медиаисточника.
В данном примере каждый «ssrc» ассоциирует «cname», «msid» и «appdata».
В сеансе RTP, после обновления медиаисточника, «ssrc» будет изменен.
Чтобы избежать потери медиаисточника в RTP-сессии, «cname» требуется, когда SDP имеет строки «a=ssrc».
По крайней мере, если SDP сделан в Chrome (Chromium), «msid» — это то же самое, что MediaStream ID в JavaScript, а «appdata» — то же самое, что MediaStreamTrack.
Поскольку видеопоток посылает пакеты с повторной передачей, этот образец имеет два «ssrc» для видео, поэтому «ssrc-group» ассоциирует их.
- RFC5576 — Атрибуты медиа в протоколе описания сеанса (SDP), специфичные для источника.
- RFC8830 — Идентификация медиапотока WebRTC в протоколе описания сеанса
- RFC3550 — RTP: транспортный протокол для приложений реального времени
- RFC4588 — Формат полезной нагрузки обратной передачи RTP
- Сигнализация — WebRTC для любопытных
- RFC3551 — Профиль RTP для аудио- и видеоконференций с минимальным управлением
- RFC8829 — Протокол установления сеанса JavaScript (JSEP)