SDP — bu nima, sessiya tavsifi formati va WebRTCdagi roli

SDP (Session Description Protocol) nima?

SDP — multimedia seanslari parametrlarini matn formatida tavsiflash uchun mo'ljallangan amaliy qatlam protokolidir. U IETFning MMUSIC (Multiparty Multimedia Session Control) ishchi guruhi doirasida ishlab chiqilgan va birinchi marta 1998 yilda RFC 2327 da standartlashtirilgan. 2021 yilda avvalgi versiya RFC 4566 ni almashtirgan joriy spetsifikatsiya RFC 8866 nashr etilgan.

SDPning asosiy vazifasi seans ishtirokchilariga ulanishni o'rnatish uchun barcha kerakli ma'lumotlarni taqdim etishdir: qaysi media oqimlari uzatiladi, qaysi kodeklar qo'llab-quvvatlanadi, qaysi tarmoq manzillari va portlari orqali uzatish amalga oshiriladi. SDP media ma'lumotlarining o'zini uzatmaydi, balki faqat ulanish qanday tashkil etilishi kerakligini tavsiflaydi.

IETF RFC 8866 ga ko'ra, SDP formati har biri bir harfli tur bilan boshlanadigan, undan keyin tenglik belgisi va qiymat keladigan qatorlar to'plamidan iborat. Masalan, m=audio 5004 RTP/AVP 0 qatori seans 5004 portida RTP/AVP transport protokoli va PCMU kodeki (tur 0) bilan audio oqimini o'z ichiga olganligini bildiradi.

SDPning tarixi va standartlashtirilishi

SDPning birinchi versiyasi 1998 yil aprelda RFC 2327 da MMUSIC guruhi ishining natijasi sifatida nashr etilgan. Protokol dastlab Mbone (Multicast Backbone) doirasida multicast seanslarini e'lon qilish uchun yaratilgan. VoIP va videokonferensiyalarning rivojlanishi bilan SDP qo'llanish doirasi kengaydi va 2006 yilda yangilangan spetsifikatsiya RFC 4566 nashr etildi.

SDPdan foydalanishdagi haqiqiy yutuq 2011 yilda WebRTC ning paydo bo'lishi bilan sodir bo'ldi. Google o'z brauzer real-vaqt muloqot tizimida media seanslarini tavsiflashning asosiy mexanizmi sifatida SDPni integratsiya qildi. Shu paytdan boshlab SDP brauzerlardan tortib iOS va Androiddagi mobil ilovalargacha bo'lgan har bir WebRTC implementatsiyasining majburiy komponentiga aylandi.

2021 yilda IETF ishchi guruhi RFC 4566 ni almashtirgan joriy SDP spetsifikatsiyasi RFC 8866 ni nashr etdi. Yangilangan versiya ICE (Interactive Connectivity Establishment) ni boshqarishni, DTLS (Datagram Transport Layer Security) ni qo'llab-quvvatlashni aniqlashtirdi va guruh seanslarini tavsiflash imkoniyatlarini kengaytirdi.

SDPning transport protokollaridan farqi

SDP transport protokollaridan tubdan farq qiladi, chunki u ma'lumotlarni uzatishda ishtirok etmaydi. U faqat tavsiflovchi funktsiyani bajaradi — multimedia faylining metama'lumotlariga o'xshab. RTP (Real-time Transport Protocol) audio va video paketlarni uzatganda, RTCP uzatish sifatini nazorat qilganda, SDP faqat qaysi kodeklar va portlardan foydalanish kerakligini ko'rsatadi.

Veb-ishlanmadan olingan o'xshatish: SDP sahifa tuzilmasini tavsiflovchi HTML belgilashdir, RTP esa rasm va matnning o'zidir. SDP bo'lmasa, seans ishtirokchilari tarmoq ulanishi allaqachon o'rnatilgan bo'lsa ham, bir-biriga qanday ulanishni bilmaydilar. NAT-kechish mexanizmi (ICE) ham tarmoq nomzodlari haqida ma'lumot uzatish uchun SDPga tayanadi.

SDP tuzilmasi qanday tashkil etilgan

SDP tuzilmasi har biri type=value formatiga amal qiladigan matn qatorlari ketma-ketligi sifatida tashkil etilgan. Bir harfli tur qatorning maqsadini aniqlaydi, qiymat esa tegishli qiymatni o'z ichiga oladi. Barcha qatorlar CRLF yangi qator belgisi bilan ajratiladi.

RFC 8866 standarti bir nechta majburiy va ixtiyoriy maydonlarni belgilaydi. Majburiy maydonlar protokol versiyasi (v=), seans nomi (s=), seansning boshlanish va tugash vaqtini (t=) o'z ichiga oladi. Qolgan maydonlar ixtiyoriy, ammo WebRTC seanslari uchun media tavsiflari (m=), atributlar (a=) va tarmoq ma'lumotlari (c=) ham zarur.

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

Yuqoridagi misolda WebRTC seansi uchun odatdagi SDP segmenti ko'rsatilgan. v=0 qatori protokol versiyasini ko'rsatadi. o= maydoni seans egasining identifikatorini va uning versiyasini o'z ichiga oladi. s=- qatori seans nomini belgilaydi (defis bo'sh nom degani). t=0 0 maydoni seans vaqt bilan cheklanmaganligini ko'rsatadi.

a=group:BUNDLE audio video maydoni bir nechta media oqimlarini bitta transport kanalida guruhlaydigan atributdir. BUNDLE mexanizmi audio va videoni bitta ulanish orqali uzatish orqali tarmoq resurslarini tejash imkonini beradi. Bu, ayniqsa, cheklangan o'tkazish qobiliyatiga ega mobil qurilmalar uchun muhimdir.

SDPning majburiy maydonlari

RFC 8866 spetsifikatsiyasi majburiy va ixtiyoriy maydonlar to'plamini belgilaydi. Majburiy maydonlarga v= (versiya), s= (seans nomi) va t= (vaqt) kiradi. o= (egasi) maydoni RFCga ko'ra qat'iy majburiy bo'lmasa ham, amalda har doim real implementatsiyalarda mavjud.

m= (media) maydoni eng muhimlaridan biridir. U ma'lum bir media oqimini tavsiflaydi va media turini (audio, video, text, application), portni, transport protokolini va qo'llab-quvvatlanadigan kodeklar ro'yxatini o'z ichiga oladi. WebRTCda eng ko'p RTP/SAVPF (Secure Audio/Video Profile with Feedback) yoki UDP/TLS/RTP/SAVPF transport protokollari bilan audio va video turlaridan foydalaniladi.

a= (attribute) maydoni eng moslashuvchan va kengaytiriladigan maydondir. U rtpmap (kodek raqamini nom bilan moslashtirish), fmtp (kodek parametrlari), fingerprint (DTLS kalitining izi), ice-ufrag va ice-pwd (ICE uchun autentifikatsiya ma'lumotlari) va boshqa ko'plab atributlarni o'z ichiga olishi mumkin. Aynan atributlar orqali SDP zamonaviy xavfsizlik mexanizmlari va NAT-kechishni qo'llab-quvvatlaydi.

SDP WebRTCda qanday ishlaydi

WebRTC arxitekturasida SDP ikki ishtirokchi o'rtasida media seansi parametrlarini tavsiflash va kelishish uchun signal protokoli rolini o'ynaydi. SDPning o'zi bu tavsiflarni uzatish mexanizmini aniqlamaydi — bu vazifani ishlab chiquvchi WebSocket, HTTP yoki boshqa protokol orqali mustaqil ravishda amalga oshiradigan signal kanali hal qiladi.

Jarayon tashabbuskor (qo'ng'iroq qiluvchi) tomonidan SDP taklifi — Offer yaratish bilan boshlanadi. Buning uchun brauzer RTCPeerConnection obyektida createOffer() metodini chaqiradi. Yaratilgan SDP tavsifi tashabbuskor tomondan seansning barcha parametrlarini o'z ichiga oladi: qo'llab-quvvatlanadigan kodeklar, tarmoq manzillari, ICE nomzodlari va xavfsizlik talablari.

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

// Androidda SDP Offer yarating
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP qatorini uzoq ishtirokchiga yuboring
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Offer yaratilgandan va setLocalDescription() orqali lokal tavsif o'rnatilgandan so'ng, tashabbuskor SDP qatorini signal kanali orqali uzoq ishtirokchiga yuboradi. Uzoq ishtirokchi SDP Offer ni olgandan so'ng, SDP javobi — Answer yaratadi va uni qaytarib yuboradi. Bu almashinuv signal almashinuvi (signaling exchange) deb ataladi va peer-to-peer ulanishini o'rnatishdan oldin majburiy bosqichdir.

W3C WebRTC Spetsifikatsiyasiga ko'ra, SDP almashinuvi ICE nomzodlari almashinuvidan oldin bo'lishi kerak. Amalda, ko'plab implementatsiyalar ICE trickle mexanizmidan foydalanib, ICE nomzodlarini SDP bilan parallel ravishda yuboradi. Bu, ayniqsa, yuqori kechikishli mobil tarmoqlarda ulanishni o'rnatish vaqtini qisqartiradi.

ICEni SDPdagi roli

ICE (Interactive Connectivity Establishment) — tarmoq nomzodlari haqida ma'lumot uzatish uchun SDP atributlaridan foydalanadigan mexanizmdir. ICE nomzodlari mumkin bo'lgan ulanish yo'llarini tavsiflaydi: host (lokal manzil), srflx (STUN orqali olingan NATdan keyingi manzil) va relay (TURN serverining manzili).

SDPda ICE nomzodlari a=candidate: atributlari, shuningdek, ICE trafigini autentifikatsiya qilish uchun ice-ufrag va ice-pwd maydonlari orqali uzatiladi. Har bir nomzod transport protokolini (UDP, TCP), IP manzilini, portni va ustuvorlikni o'z ichiga oladi. Muvaffaqiyatli ulanish ulanish testidan o'tgan birinchi nomzod orqali o'rnatiladi. ICE restart mexanizmi tarmoq o'zgarganda ulanishni yangilash imkonini beradi.

Mobil ilovalar uchun ICE nomzodlari ayniqsa muhim, chunki qurilmalar ko'pincha NAT yoki korporativ xavfsizlik devorlari ortida joylashgan. ICE mexanizmi hatto murakkab tarmoq sharoitlarida ham ishlaydigan yo'lni topish imkonini beradi, SDP esa bu ma'lumotlar uchun transport konteyneri vazifasini bajaradi.

WebRTCda SDP xavfsizligi

SDP WebRTCda majburiy ravishda xavfsizlik atributlarini, xususan DTLS izi (fingerprint) va SRTP parametrlarini o'z ichiga oladi. a=fingerprint:sha-256 maydoni media oqimini autentifikatsiya qilish va shifrlash uchun ishlatiladigan DTLS sertifikatining izini o'z ichiga oladi. Ushbu atributsiz WebRTC ulanishi o'rnatilmaydi.

Qo'shimcha xavfsizlik mexanizmlariga DTLS qo'l siqishning rolini belgilaydigan a=setup: atributi (active, passive, actpass) va server tomonida soddalashtirilgan ICE implementatsiyasi uchun a=ice-lite: kiradi. Barcha bu parametrlar SDP ichida uzatiladi va media ma'lumotlarini uzatish boshlanishidan oldin har ikki tomon tomonidan tekshiriladi.

SDP turlari: Offer va Answer

WebRTC modelida ikkita turdagi SDP xabarlari mavjud: Offer (taklif) va Answer (javob). Offer ulanish tashabbuskori tomonidan yaratiladi va istalgan media seansining to'liq tavsifini o'z ichiga oladi. Answer uzoq ishtirokchi tomonidan Offer ga javoban yaratiladi va taklif tomonidan qo'yilgan cheklovlarni hisobga olgan holda uning imkoniyatlarini o'z ichiga oladi.

Offer va Answer o'rtasidagi asosiy farq atributlar semantikasidadir. Offer tashabbuskor taklif qilishi mumkin bo'lgan barcha qo'llab-quvvatlanadigan kodeklar, transport protokollari va tarmoq manzillarini sanab o'tadi. Answer uzoq tomon tomonidan qo'llab-quvvatlanadigan ushbu imkoniyatlarning pastki to'plamini tanlaydi. Masalan, Offer opus, ISAC va PCMU taklif qilsa, Answer eng maqbul kodek sifatida faqat opusni tanlashi mumkin.

Almashinuv jarayoni W3C WebRTC spetsifikatsiyasi bilan tartibga solinadi va RTCPeerConnectionning bir nechta holatlarini o'z ichiga oladi. Offer createOffer() orqali yaratilgandan va lokal tavsif sifatida o'rnatilgandan so'ng, ulanish have-local-offer holatiga o'tadi. Answer olingandan va setRemoteDescription() orqali uzoq tavsif sifatida o'rnatilgandan so'ng, ulanish stable — media uzatishga tayyor bo'lgan yakuniy holatga o'tadi.

Mobil SDKlarda SDPdan foydalanish

WebRTC uchun mobil SDKlar — Android uchun Google WebRTC va iOS uchun WebRTC.framework — Offer va Answer orqali SDP almashinuvini to'liq qo'llab-quvvatlaydi. Android da Offer yaratish uchun brauzer API siga o'xshash createOffer() metodi bilan PeerConnection sinfidan foydalaniladi. Olingan SDP tavsifi signal kanali orqali qator sifatida uzatiladi.

iOS da SDP bilan ishlash WebRTC frameworkidan RTCSessionDescription sinfi orqali amalga oshiriladi. Initializatsiya paytida tur (RTCSdpTypeOffer yoki RTCSdpTypeAnswer) va SDP qatori ko'rsatiladi. Platforma avtomatik ravishda SDPni tahlil qiladi va uzatilgan parametrlarga muvofiq ulanishni konfiguratsiya qiladi.

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 qatori bilan bevosita ishlash imkoniyati ishlab chiquvchilarga moslashuvchanlik beradi: ma'lum kodeklarni qo'shib yoki olib tashlab, ICE parametrlarini konfiguratsiya qilib yoki shaxsiy atributlar qo'shib, SDPni yuborishdan oldin o'zgartirish mumkin. Android ilovalari uchun tarmoqning past o'tkazish qobiliyati paytida SDPda videoni o'chirish tez-tez talab qilinadi — bu SDP tavsifidan tegishli m= qatorlarini olib tashlash orqali amalga oshiriladi.

Mobil ishlanmada SDP

Mobil ishlanmada SDP asosan WebRTC kontekstida — videoqo'ng'iroqlar, ovozli suhbatlar va striming uchun ilovalar yaratishda qo'llaniladi. Android va iOSdagi mobil ilovalar ham tashabbuskor, ham SDP xabarlarini qabul qiluvchi rolida harakat qilishi mumkin, bu esa simmetrik peer-to-peer ulanishlarini qurish imkonini beradi.

Mobil ilovalarning o'ziga xosligi o'zgaruvchan tarmoq sifati sharoitida SDP bilan ishlash zaruratidir. Wi-Fi va mobil internet o'rtasida o'tish paytida, shuningdek o'tkazish qobiliyatining o'zgarishi paytida yangi SDP tavsifini yaratish talab qilinishi mumkin. Buning uchun renegotiation mexanizmi — createOffer() va setLocalDescription() orqali takroriy SDP almashinuvi ishlatiladi.

Google WebRTC jamoasining ma'lumotlariga ko'ra (2023), mobil qurilmalar uchun SDP almashinuvini optimallashtirish tarmoq o'zgarishi paytida ICE restart, past bitrate li kodeklarga ustunlik berish (audio uchun opus, video uchun VP8) va keraksiz media oqimlarini chiqarib tashlash hisobiga SDP qatorining minimal hajmini o'z ichiga oladi. Asosiy afzallik mobil tarmoqlarda ulanishni o'rnatishdagi kechikishni kamaytirishdir.

Mobil tarmoqlar uchun SDPni optimallashtirish

Mobil qurilmalarda SDP bilan ishlashdagi asosiy vazifalardan biri SDP tavsifining hajmini minimallashtirishdir. Audio va video bilan odatdagi WebRTC seansi uchun to'liq SDP 2–5 KB ni egallashi mumkin, bu sekin tarmoqlar uchun muhimdir. Optimallashtirish BUNDLE (oqimlarni birlashtirish), qo'llab-quvvatlanmaydigan kodeklarni olib tashlash va ICE nomzodlarini siqishni o'z ichiga oladi.

Mobil qurilmalarning qo'shimcha muammosi SDPning cheklangan umr muddatidir. Beqaror ulanish sharoitida SDP uzoq ishtirokchi uni qayta ishlashga ulgurmasdan eskirishi mumkin. Yechim — Answer olish uchun qisqa vaqt chegarasidan foydalanish va kerak bo'lganda SDPni qayta yuborish. ICE restart mexanizmi RTCPeerConnectionni to'liq qayta yaratmasdan ulanishni yangilash imkonini beradi. a=ice-lite atributi server tomonida ICE implementatsiyasini soddalashtiradi.

SDP bilan ishlash uchun mashhur kutubxonalar

Mobil ilova ishlab chiquvchilari SDP bilan ishlashni osonlashtiradigan tayyor kutubxonalarga ega. libjingle_peerconnection (Google WebRTC) — Android uchun asosiy kutubxona, SDPni boshqarish uchun to'liq API ni ta'minlaydi. iOS uchun o'xshash funksionallik bilan WebRTC.framework ishlatiladi. Ikkala kutubxona avtomatik ravishda SDPni yaratadi va tahlil qiladi, ammo kerak bo'lganda xom SDP qatoriga kirish imkonini beradi.

SDP ustida nozikroq nazorat uchun uchinchi tomon yechimlari mavjud: SDPni tahlil qilish va o'zgartirish uchun sdp-transform (JavaScript yoki Node.js), ICE nomzodlari bilan ishlash uchun NICENICE (Java) va SDPni o'z ichiga olgan butun signal almashinuvini o'z zimmasiga oladigan WebRTC infratuzilmasi provayderlaridan tayyor SDKlar.