SDP — що це таке, формат опису сесій та роль у WebRTC

Що таке SDP (Session Description Protocol)?

SDP — це протокол прикладного рівня, призначений для опису параметрів мультимедійних сесій у текстовому форматі. Він був розроблений в рамках робочої групи MMUSIC (Multiparty Multimedia Session Control) IETF і вперше стандартизований в RFC 2327 у 1998 році. У 2021 році вийшла актуальна специфікація RFC 8866, яка замінила попередню версію RFC 4566.

Основне завдання SDP — надати учасникам сесії всю необхідну інформацію для встановлення з'єднання: які медіа-потоки передаватимуться, які кодеки підтримуються, за якими мережевими адресами та портами йтиме передача. SDP не передає самі медіадані, а лише описує, як має бути організоване з'єднання.

За даними IETF RFC 8866, формат SDP складається з набору рядків, кожен з яких починається з однолітерного типу, за яким слідує знак рівності та значення. Наприклад, рядок m=audio 5004 RTP/AVP 0 означає, що сесія включає аудіопотік на порту 5004 з транспортним протоколом RTP/AVP та кодеком PCMU (тип 0).

Історія та стандартизація SDP

Перша версія SDP була опублікована в RFC 2327 у квітні 1998 року як результат роботи групи MMUSIC. Протокол спочатку створювався для анонсування multicast-сесій в рамках Mbone (Multicast Backbone). З розвитком VoIP та відеоконференцій сфера застосування SDP розширилася, і в 2006 році вийшла оновлена специфікація RFC 4566.

Справжній прорив у використанні SDP відбувся з появою WebRTC у 2011 році. Google інтегрувала SDP як основний механізм опису медіа-сесій у своєму фреймворку для браузерного real-time спілкування. З цього моменту SDP став обов'язковим компонентом будь-якої WebRTC-реалізації — від браузерів до мобільних додатків на iOS та Android.

У 2021 році робоча група IETF опублікувала RFC 8866 — актуальну специфікацію SDP, яка замінила RFC 4566. Оновлена версія уточнила обробку ICE (Interactive Connectivity Establishment), підтримку DTLS (Datagram Transport Layer Security) та розширила можливості опису групових сесій.

Відмінність SDP від транспортних протоколів

SDP принципово відрізняється від транспортних протоколів тим, що не бере участі в передачі даних. Він виконує виключно описову функцію — подібно до метаданих мультимедійного файлу. У той час як RTP (Real-time Transport Protocol) передає аудіо- та відеопакети, а RTCP контролює якість передачі, SDP лише вказує, які кодеки та порти використовувати.

Аналогія з веб-розробки: SDP — це HTML-розмітка, що описує структуру сторінки, а RTP — це самі зображення та текст. Без SDP учасники сесії не знають, як підключитися один до одного, навіть якщо мережеве з'єднання вже встановлено. Механізм NAT-траверсалу (ICE) також покладається на SDP для передачі інформації про мережеві кандидати.

Як влаштована структура SDP

Структура SDP організована у вигляді послідовності текстових рядків, кожен з яких слідує формату type=value. Однолітерний type визначає призначення рядка, а value містить відповідне значення. Всі рядки розділені символом переведення рядка CRLF.

Стандарт RFC 8866 визначає кілька обов'язкових та опціональних полів. Обов'язкові поля включають версію протоколу (v=), ім'я сесії (s=), час початку та закінчення сесії (t=). Інші поля — опціональні, але для WebRTC-сесій необхідні також описи медіа (m=), атрибутів (a=) та мережевої інформації (c=).

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

У наведеному прикладі показано типовий SDP-сегмент для WebRTC-сесії. Рядок v=0 вказує версію протоколу. Поле o= містить ідентифікатор власника сесії та її версію. Рядок s=- задає ім'я сесії (дефіс означає пусте ім'я). Поле t=0 0 вказує, що сесія не обмежена в часі.

Поле a=group:BUNDLE audio video — це атрибут, що групує кілька медіа-потоків в один транспортний канал. Механізм BUNDLE дозволяє економити мережеві ресурси, передаючи аудіо та відео через одне з'єднання. Це особливо важливо для мобільних пристроїв з обмеженою пропускною здатністю.

Обов'язкові поля SDP

Специфікація RFC 8866 визначає набір обов'язкових та опціональних полів. До обов'язкових належать v= (версія), s= (ім'я сесії) та t= (час). Поле o= (власник), хоча і не є суворо обов'язковим за RFC, практично завжди присутнє в реальних реалізаціях.

Поле m= (media) — одне з найважливіших. Воно описує конкретний медіа-потік і містить тип медіа (audio, video, text, application), порт, транспортний протокол та список підтримуваних кодеків. У WebRTC найчастіше використовуються типи audio та video з транспортними протоколами RTP/SAVPF (Secure Audio/Video Profile with Feedback) або UDP/TLS/RTP/SAVPF.

Поле a= (attribute) — найбільш гнучке та розширюване. Воно може містити rtpmap (зіставлення номера кодека з назвою), fmtp (параметри кодека), fingerprint (відбиток DTLS-ключа), ice-ufrag та ice-pwd (облікові дані для ICE) та безліч інших атрибутів. Саме через атрибути SDP забезпечує підтримку сучасних механізмів безпеки та NAT-траверсалу.

Як SDP працює в WebRTC

В архітектурі WebRTC SDP виконує роль сигнального протоколу для опису та узгодження параметрів медіа-сесії між двома учасниками. Сам SDP не визначає механізм передачі цих описів — це завдання вирішує сигнальний канал, який розробник реалізує самостійно через WebSocket, HTTP або інший протокол.

Процес починається з того, що ініціатор (caller) створює SDP-пропозицію — Offer. Для цього браузер викликає метод createOffer() на об'єкті RTCPeerConnection. Згенерований SDP-опис містить усі параметри сесії з боку ініціатора: підтримувані кодеки, мережеві адреси, ICE-кандидати та вимоги до безпеки.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Add media tracks before createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Create SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Після створення Offer та встановлення локального опису через setLocalDescription(), ініціатор надсилає SDP-рядок віддаленому учаснику через сигнальний канал. Віддалений учасник, отримавши SDP Offer, створює SDP-відповідь — Answer — і надсилає її назад. Цей обмін називається сигнальним обміном (signaling exchange) і є обов'язковим етапом перед встановленням peer-to-peer з'єднання.

За даними W3C WebRTC Specification, SDP-обмін має відбуватися до початку ICE-кандидатів. На практиці багато реалізацій надсилають ICE-кандидати паралельно з SDP, використовуючи механізм ICE trickle. Це скорочує час встановлення з'єднання, особливо для мобільних мереж з високими затримками.

Роль ICE в SDP

ICE (Interactive Connectivity Establishment) — це механізм, що використовує SDP-атрибути для передачі інформації про мережеві кандидати. ICE-кандидати описують можливі шляхи з'єднання: host (локальна адреса), srflx (адреса після NAT, отримана через STUN) та relay (адреса TURN-сервера).

В SDP ICE-кандидати передаються через атрибути a=candidate:, а також через поля ice-ufrag та ice-pwd для аутентифікації ICE-трафіку. Кожен кандидат включає транспортний протокол (UDP, TCP), IP-адресу, порт та пріоритет. Успішне з'єднання встановлюється за першим кандидатом, який проходить перевірку зв'язності. Механізм ICE restart дозволяє оновити з'єднання при зміні мережі.

Для мобільних додатків ICE-кандидати особливо важливі, оскільки пристрої часто знаходяться за NAT або корпоративними фаєрволами. Механізм ICE дозволяє знайти робочий шлях навіть у складних мережевих умовах, а SDP служить транспортним контейнером для цієї інформації.

Безпека SDP в WebRTC

SDP в WebRTC обов'язково включає атрибути безпеки, зокрема DTLS fingerprint та параметри SRTP. Поле a=fingerprint:sha-256 містить відбиток сертифіката DTLS, що використовується для аутентифікації та шифрування медіа-потоку. Без цього атрибута WebRTC-з'єднання не буде встановлено.

Додаткові механізми безпеки включають атрибут a=setup:, який визначає роль DTLS-рукопотискання (active, passive, actpass), та a=ice-lite: для спрощеної ICE-реалізації на стороні сервера. Всі ці параметри передаються всередині SDP і перевіряються обома сторонами до початку передачі медіаданих.

Типи SDP: Offer та Answer

У моделі WebRTC існує два типи SDP-повідомлень: Offer (пропозиція) та Answer (відповідь). Offer створюється ініціатором з'єднання і містить повний опис бажаної медіа-сесії. Answer створюється віддаленим учасником у відповідь на Offer і містить його можливості з урахуванням обмежень, накладених пропозицією.

Основна відмінність між Offer та Answer — у семантиці атрибутів. Offer перераховує всі підтримувані кодеки, транспортні протоколи та мережеві адреси, які може запропонувати ініціатор. Answer вибирає підмножину цих можливостей, яку підтримує віддалена сторона. Наприклад, якщо Offer пропонує opus, ISAC та PCMU, Answer може вибрати лише opus як найбільш бажаний кодек.

Процес обміну регулюється W3C WebRTC specification і включає кілька станів RTCPeerConnection. Після створення Offer через createOffer() та встановлення як локального опису, з'єднання переходить у стан have-local-offer. Після отримання Answer та встановлення її як віддаленого опису через setRemoteDescription(), з'єднання переходить у stable — фінальний стан, готовий до передачі медіа.

Використання SDP в мобільних SDK

Мобільні SDK для WebRTC — Google WebRTC для Android та WebRTC.framework для iOS — повністю підтримують SDP-обмін через Offer та Answer. На Android для створення Offer використовується клас PeerConnection з методом createOffer(), аналогічним браузерному API. Отриманий SDP-опис передається як рядок через сигнальний канал.

На iOS робота з SDP будується через клас RTCSessionDescription з фреймворку WebRTC. При ініціалізації вказуються тип (RTCSdpTypeOffer або RTCSdpTypeAnswer) та SDP-рядок. Платформа автоматично парсить SDP та налаштовує з'єднання згідно з переданими параметрами.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

Можливість напряму працювати з SDP-рядком дає розробникам гнучкість: можна модифікувати SDP перед відправкою, додаючи або видаляючи певні кодеки, налаштовуючи параметри ICE або додаючи користувацькі атрибути. Для Android додатків часто потрібно вимикати відео в SDP при низькій пропускній здатності мережі — це робиться видаленням відповідних m= рядків з SDP-опису.

SDP у мобільній розробці

У мобільній розробці SDP використовується переважно в контексті WebRTC — для створення додатків з відеодзвінками, голосовими чатами та стрімінгом. Мобільні додатки на Android та iOS можуть виступати як у ролі ініціатора, так і в ролі отримувача SDP-повідомлень, що дозволяє будувати симетричні peer-to-peer з'єднання.

Особливість мобільних додатків — необхідність працювати з SDP в умовах змінної якості мережі. При перемиканні між Wi-Fi та мобільним інтернетом, а також при зміні пропускної здатності може знадобитися генерація нового SDP-опису. Для цього використовується механізм renegotiation — повторний обмін SDP через createOffer() та setLocalDescription().

За даними Google WebRTC team (2023), оптимізація SDP-обміну для мобільних пристроїв включає використання ICE restart при зміні мережі, пріоритизацію кодеків з низьким бітрейтом (opus для аудіо, VP8 для відео) та мінімальний розмір SDP-рядка за рахунок виключення непотрібних медіа-потоків. Ключова перевага — зниження затримки при встановленні з'єднання в умовах мобільних мереж.

Оптимізація SDP для мобільних мереж

Одне з ключових завдань при роботі з SDP на мобільних пристроях — мінімізація розміру SDP-опису. Повний SDP для типової WebRTC-сесії з аудіо та відео може займати 2–5 КБ, що суттєво для повільних мереж. Оптимізація включає використання BUNDLE (об'єднання потоків), видалення непідтримуваних кодеків та стиснення ICE-кандидатів.

Додаткова проблема мобільних пристроїв — обмежений час життя SDP. В умовах нестабільного з'єднання SDP може застаріти до того, як віддалений учасник встигне його обробити. Рішення — використання коротких таймаутів на отримання Answer та повторне відправлення SDP при необхідності. Механізм ICE restart дозволяє оновити з'єднання без повного перестворення RTCPeerConnection. Атрибут a=ice-lite спрощує ICE-реалізацію на серверній стороні.

Популярні бібліотеки для роботи з SDP

Розробникам мобільних додатків доступні готові бібліотеки, що спрощують роботу з SDP. libjingle_peerconnection (Google WebRTC) — основна бібліотека для Android, що надає повний API для керування SDP. Для iOS використовується WebRTC.framework з аналогічним функціоналом. Обидві бібліотеки автоматично генерують та парсять SDP, але дають доступ до сирого SDP-рядка при необхідності.

Для більш тонкого контролю над SDP існують сторонні рішення: sdp-transform (JavaScript або Node.js) для парсингу та модифікації SDP, NICENICE (Java) для роботи з ICE-кандидатами та готові SDK від провайдерів WebRTC-інфраструктури, що беруть на себе весь сигнальний обмін, включаючи SDP.