Ответ 1
Я долго искал ответ на ваш вопрос. Сначала я нашел это на сайте w3.org WebRTC:
В этом документе определяется набор API-интерфейсов ECMAScript в WebIDL, чтобы разрешить отправку и получение мультимедиа от другого браузера или устройства, реализующего соответствующий набор протоколов реального времени. Эта спецификация разрабатывается в сочетании со спецификацией протокола, разработанной группой IETF RTCWEB и спецификацией API, чтобы получить доступ к локальным мультимедийным устройствам, разработанным Целевой группой по сбору данных.
Затем на сайте "Медиа-транспорт и использование RTP" я нашел следующие данные:
5.2.4. Идентификация медиапотока:
Конечные точки WebRTC, которые реализуют расширение согласования пакета SDP, будут использовать атрибут "mid" структуры группировки SDP для идентификации медиапотоков. Такие конечные точки ДОЛЖНЫ реализовать расширение заголовка RTP MID, описанное в [ID.ietf-mmusic-sdp-bundle-negotiation].
Это расширение заголовка использует общую структуру расширения заголовка [RFC5285], и поэтому ее необходимо обсудить до ее использования.
12.2.1. Идентификация источника мультимедиа:
Каждый поток пакетов RTP идентифицируется уникальным идентификатором источника синхронизации (SSRC). Идентификатор SSRC переносится в каждом из RTP-пакетов, содержащих поток RTP-пакетов, а также используется для идентификации этого потока в соответствующих отчетах RTCP. SSRC выбирается, как описано в разделе 4.8. Первый этап в демультиплексировании RTP и RTCP-пакетов, полученных в одном потоке транспортного уровня в конечной точке WebRTC, заключается в разделении потоков пакетов RTP на основе их значения SSRC; как только это будет сделано, дополнительные шаги демультиплексирования могут определять, как и где визуализировать медиа.
RTP позволяет микшеру или другому среднему блоку RTP-уровня комбинировать закодированные потоки из нескольких источников мультимедиа для формирования нового закодированного потока из нового медиа-источника (микшера). Пакеты RTP в этом новом потоке RTP-пакетов могут включать в себя список Contributing Source (CSRC), указывающий, какие исходные SSRC способствовали объединенному потоку источника.
Как описано в разделе 4.1, реализации должны поддерживать прием пакетов данных RTP, содержащих списки CSRC и RTCP, которые относятся к источникам, присутствующим в списке CSRC. Список CSRC может изменяться поэтапно, в зависимости от выполняемой операции смешивания.
Знание того, какие медиа-ресурсы внесли в конкретный пакет RTP, может быть важным, если пользовательский интерфейс указывает, какие участники активны в сеансе. Изменения в списке CSRC, включенные в пакеты, должны быть представлены в приложении WebRTC с использованием некоторого API, если приложение должно отслеживать изменения в участии в сеансе. Желательно сопоставлять значения CSRC обратно в идентификаторы WebRTC MediaStream, поскольку они пересекают этот API, чтобы не подвергать пространство имен SSRC/CSRC приложениям WebRTC.
Если в сеансе используется расширение уровня аудиосигнала микшер-клиент [RFC6465] (см. Раздел 5.2.3), информация в списке CSRC дополняется информацией уровня звука для каждого источника-источника. Желательно предоставить эту информацию в приложение WebRTC с использованием некоторого API после сопоставления значений CSRC с идентификаторами WebRTC MediaStream, чтобы он мог отображаться в пользовательском интерфейсе.
Perkins, et al. Истекает 18 сентября 2016 года [Страница 35]
Интернет-проект RTP для WebRTC Март 2016
Все транспорты для WebRTC перечислены на этом сайте.
Все документы группы IETF RTCWEB вы можете найти на сайте "Постоянная связь в WEB-браузерах (rtcweb)".
Для дополнительной информации:
- Media Capture (со ссылками на все документы)
- API MediaStream (все методы, которые используются в этом API)
- Транспортный протокол реального времени (RTP)
- Протокол описания сеанса (SDP)
Мой вывод:
- Протокол описания сеанса (SDP)
- Транспортный протокол реального времени (RTP) (может быть тоже)