SDP — bu nədir, sessiya təsvir formatı və WebRTC-də rolu

SDP (Session Description Protocol) nədir?

SDP — mətn formatında multimedia sessiyalarının parametrlərini təsvir etmək üçün nəzərdə tutulmuş tətbiq qatı protokoludur. IETF-nin MMUSIC (Multiparty Multimedia Session Control) işçi qrupu çərçivəsində hazırlanmış və ilk dəfə 1998-ci ildə RFC 2327-də standartlaşdırılmışdır. 2021-ci ildə əvvəlki versiyanı (RFC 4566) əvəz edən cari spesifikasiya RFC 8866 dərc edilmişdir.

SDP-nin əsas vəzifəsi sessiya iştirakçılarına əlaqə qurmaq üçün bütün lazımi məlumatları təqdim etməkdir: hansı media axınları ötürüləcək, hansı kodeklər dəstəklənir, hansı şəbəkə ünvanları və portları üzərindən ötürmə aparılacaq. SDP media məlumatlarının özünü ötürmür, yalnız əlaqənin necə təşkil edilməli olduğunu təsvir edir.

IETF RFC 8866-ya görə, SDP formatı hər biri bir hərfli tiplə başlayan, ardınca bərabərlik işarəsi və dəyər gələn sətirlər toplusundan ibarətdir. Məsələn, m=audio 5004 RTP/AVP 0 sətri sessiyanın 5004 portunda RTP/AVP nəqliyyat protokolu və PCMU kodeki (tip 0) ilə audio axını ehtiva etdiyini bildirir.

SDP-nin tarixi və standartlaşdırılması

SDP-nin ilk versiyası 1998-ci ilin aprelində RFC 2327-də MMUSIC qrupunun işinin nəticəsi olaraq dərc edilmişdir. Protokol ilkin olaraq Mbone (Multicast Backbone) çərçivəsində multicast sessiyalarını elan etmək üçün yaradılmışdır. VoIP və videokonfransların inkişafı ilə SDP tətbiq dairəsi genişlənmiş və 2006-cı ildə yenilənmiş spesifikasiya RFC 4566 dərc edilmişdir.

SDP-nin istifadəsində əsl sıçrayış 2011-ci ildə WebRTC-nin meydana çıxması ilə baş vermişdir. Google öz brauzer real-time ünsiyyət çərçivəsində media sessiyalarının təsviri üçün əsas mexanizm kimi SDP-ni inteqrasiya etmişdir. O vaxtdan bəri SDP brauzerlərdən tutmuş iOS və Android-də mobil tətbiqlərə qədər hər bir WebRTC tətbiqinin məcburi komponentinə çevrilmişdir.

2021-ci ildə IETF işçi qrupu RFC 4566-nı əvəz edən cari SDP spesifikasiyası RFC 8866-nı dərc etmişdir. Yenilənmiş versiya ICE (Interactive Connectivity Establishment) idarəsini, DTLS (Datagram Transport Layer Security) dəstəyini dəqiqləşdirmiş və qrup sessiyalarının təsvir imkanlarını genişləndirmişdir.

SDP-nin nəqliyyat protokollarından fərqi

SDP nəqliyyat protokollarından prinsipial olaraq fərqlənir, çünki məlumat ötürülməsində iştirak etmir. O, yalnız təsviri funksiya yerinə yetirir — multimedia faylının metadata məlumatlarına bənzər. RTP (Real-time Transport Protocol) audio və video paketləri ötürərkən, RTCP ötürmə keyfiyyətinə nəzarət edərkən, SDP yalnız hansı kodeklərin və portların istifadə ediləcəyini göstərir.

Veb inkişafdan bir bənzətmə: SDP səhifənin strukturunu təsvir edən HTML işarələmədir, RTP isə şəkillərin və mətnin özüdür. SDP olmadan sessiya iştirakçıları şəbəkə əlaqəsi artıq qurulmuş olsa belə, bir-birinə necə qoşulacaqlarını bilmirlər. NAT-keçid mexanizmi (ICE) də şəbəkə namizədləri haqqında məlumat ötürmək üçün SDP-yə etibar edir.

SDP strukturu necə qurulub

SDP strukturu hər biri type=value formatına uyğun gələn mətn sətirləri ardıcıllığı şəklində təşkil edilmişdir. Bir hərfli tip sətrin təyinatını müəyyən edir, dəyər isə müvafiq dəyəri ehtiva edir. Bütün sətirlər CRLF sətirsonu simvolu ilə ayrılır.

RFC 8866 standartı bir neçə məcburi və isteğe bağlı sahə müəyyən edir. Məcburi sahələrə protokol versiyası (v=), sessiya adı (s=), sessiyanın başlama və bitmə vaxtı (t=) daxildir. Qalan sahələr isteğe bağlıdır, lakin WebRTC sessiyaları üçün media təsvirləri (m=), atributlar (a=) və şəbəkə məlumatları (c=) da lazımdır.

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

Yuxarıdakı nümunədə WebRTC sessiyası üçün tipik SDP seqmenti göstərilmişdir. v=0 sətri protokol versiyasını göstərir. o= sahəsi sessiya sahibinin identifikatorunu və onun versiyasını ehtiva edir. s=- sətri sessiya adını təyin edir (defis boş ad deməkdir). t=0 0 sahəsi sessiyanın zamanla məhdudlaşdırılmadığını göstərir.

a=group:BUNDLE audio video sahəsi bir neçə media axınını bir nəqliyyat kanalında qruplaşdıran atributdur. BUNDLE mexanizmi audio və videonu bir əlaqə üzərindən ötürməklə şəbəkə resurslarına qənaət etməyə imkan verir. Bu, məhdud ötürmə qabiliyyəti olan mobil cihazlar üçün xüsusilə vacibdir.

SDP-nin məcburi sahələri

RFC 8866 spesifikasiyası məcburi və isteğe bağlı sahələr toplusunu müəyyən edir. Məcburi sahələrə v= (versiya), s= (sessiya adı) və t= (vaxt) daxildir. o= (sahib) sahəsi RFC-yə görə ciddi məcburi olmasa da, praktiki olaraq həmişə real tətbiqlərdə mövcuddur.

m= (media) sahəsi ən vaciblərindən biridir. O, konkret media axınını təsvir edir və media növünü (audio, video, text, application), portu, nəqliyyat protokolunu və dəstəklənən kodeklərin siyahısını ehtiva edir. WebRTC-də ən çox RTP/SAVPF (Secure Audio/Video Profile with Feedback) və ya UDP/TLS/RTP/SAVPF nəqliyyat protokolları ilə audio və video tiplərindən istifadə olunur.

a= (attribute) sahəsi ən çevik və genişləndirilə bilən sahədir. O, rtpmap (kodek nömrəsinin adla uyğunlaşdırılması), fmtp (kodek parametrləri), fingerprint (DTLS açarının izi), ice-ufrag və ice-pwd (ICE üçün etimadnamə) və bir çox digər atributları ehtiva edə bilər. Məhz atributlar vasitəsilə SDP müasir təhlükəsizlik mexanizmlərini və NAT-keçidi dəstəkləyir.

SDP WebRTC-də necə işləyir

WebRTC arxitekturasında SDP iki iştirakçı arasında media sessiyasının parametrlərini təsvir etmək və razılaşdırmaq üçün siqnal protokolu rolunu oynayır. SDP-nin özü bu təsvirlərin ötürülmə mexanizmini müəyyən etmir — bu vəzifəni tərtibatçının WebSocket, HTTP və ya digər protokol vasitəsilə müstəqil şəkildə həyata keçirdiyi siqnal kanalı həll edir.

Proses təşəbbüskarla (zəng edən) SDP təklifinin — Offer-in yaradılması ilə başlayır. Bunun üçün brauzer RTCPeerConnection obyektində createOffer() metodunu çağırır. Yaradılan SDP təsviri təşəbbüskar tərəfindən sessiyanın bütün parametrlərini ehtiva edir: dəstəklənən kodeklər, şəbəkə ünvanları, ICE namizədləri və təhlükəsizlik tələbləri.

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

// Android-də SDP Offer yaradın
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP sətrini uzaq iştirakçıya göndərin
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Offer yaradıldıqdan və setLocalDescription() vasitəsilə lokal təsvir qurulduqdan sonra təşəbbüskar SDP sətrini siqnal kanalı vasitəsilə uzaq iştirakçıya göndərir. Uzaq iştirakçı SDP Offer-i aldıqdan sonra SDP cavabı — Answer — yaradır və geri göndərir. Bu mübadilə siqnal mübadiləsi (signaling exchange) adlanır və peer-to-peer əlaqəsinin qurulmasından əvvəl məcburi mərhələdir.

W3C WebRTC Spesifikasiyasına görə, SDP mübadiləsi ICE namizədlərinin mübadiləsindən əvvəl baş verməlidir. Praktikada bir çox tətbiqlər ICE trickle mexanizmindən istifadə edərək ICE namizədlərini SDP ilə paralel göndərir. Bu, xüsusilə yüksək gecikməli mobil şəbəkələrdə əlaqə qurulma müddətini qısaldır.

ICE-in SDP-də rolu

ICE (Interactive Connectivity Establishment) — şəbəkə namizədləri haqqında məlumat ötürmək üçün SDP atributlarından istifadə edən mexanizmdir. ICE namizədləri mümkün əlaqə yollarını təsvir edir: host (lokal ünvan), srflx (STUN vasitəsilə əldə edilmiş NAT-dan sonrakı ünvan) və relay (TURN serverinin ünvanı).

SDP-də ICE namizədləri a=candidate: atributları, həmçinin ICE trafikinin autentifikasiyası üçün ice-ufrag və ice-pwd sahələri vasitəsilə ötürülür. Hər bir namizəd nəqliyyat protokolunu (UDP, TCP), IP ünvanını, portu və prioriteti ehtiva edir. Uğurlu əlaqə əlaqə yoxlamasından keçən ilk namizəd üzərindən qurulur. ICE restart mexanizmi şəbəkə dəyişikliyi zamanı əlaqəni yeniləməyə imkan verir.

Mobil tətbiqlər üçün ICE namizədləri xüsusilə vacibdir, çünki cihazlar tez-tez NAT və ya korporativ divarlar arxasında olur. ICE mexanizmi hətta mürəkkəb şəbəkə şəraitində işləyən yol tapmağa imkan verir, SDP isə bu məlumat üçün nəqliyyat konteyneri rolunu oynayır.

WebRTC-də SDP təhlükəsizliyi

SDP WebRTC-də məcburi olaraq təhlükəsizlik atributlarını, xüsusən DTLS izi (fingerprint) və SRTP parametrlərini ehtiva edir. a=fingerprint:sha-256 sahəsi media axınının autentifikasiyası və şifrələnməsi üçün istifadə olunan DTLS sertifikatının izini ehtiva edir. Bu atribut olmadan WebRTC əlaqəsi qurulmayacaq.

Əlavə təhlükəsizlik mexanizmlərinə DTLS əl sıxmasının rolunu təyin edən a=setup: atributu (active, passive, actpass) və server tərəfində sadələşdirilmiş ICE tətbiqi üçün a=ice-lite: daxildir. Bütün bu parametrlər SDP daxilində ötürülür və media məlumatlarının ötürülməsinə başlamazdan əvvəl hər iki tərəf tərəfindən yoxlanılır.

SDP növləri: Offer və Answer

WebRTC modelində iki növ SDP mesajı mövcuddur: Offer (təklif) və Answer (cavab). Offer əlaqə təşəbbüskarı tərəfindən yaradılır və arzu olunan media sessiyasının tam təsvirini ehtiva edir. Answer uzaq iştirakçı tərəfindən Offer-ə cavab olaraq yaradılır və təklifin qoyduğu məhdudiyyətlər nəzərə alınmaqla onun imkanlarını ehtiva edir.

Offer və Answer arasındakı əsas fərq atributların semantikasındadır. Offer təşəbbüskarın təklif edə biləcəyi bütün dəstəklənən kodekləri, nəqliyyat protokollarını və şəbəkə ünvanlarını sadalayır. Answer uzaq tərəf tərəfindən dəstəklənən bu imkanların alt çoxluğunu seçir. Məsələn, Offer opus, ISAC və PCMU təklif edərsə, Answer ən çox üstünlük verilən kodek kimi yalnız opus-u seçə bilər.

Mübadilə prosesi W3C WebRTC spesifikasiyası ilə tənzimlənir və RTCPeerConnection-un bir neçə vəziyyətini əhatə edir. Offer createOffer() vasitəsilə yaradıldıqdan və lokal təsvir kimi qurulduqdan sonra əlaqə have-local-offer vəziyyətinə keçir. Answer alındıqdan və setRemoteDescription() vasitəsilə uzaq təsvir kimi qurulduqdan sonra əlaqə stable — media ötürülməsinə hazır olan son vəziyyətə keçir.

Mobil SDK-larda SDP istifadəsi

WebRTC üçün mobil SDK-lar — Android üçün Google WebRTC və iOS üçün WebRTC.framework — Offer və Answer vasitəsilə SDP mübadiləsini tam dəstəkləyir. Android-də Offer yaratmaq üçün brauzer API-sinə bənzər createOffer() metodu ilə PeerConnection sinfindən istifadə olunur. Alınan SDP təsviri siqnal kanalı vasitəsilə sətir kimi ötürülür.

iOS-da SDP ilə iş WebRTC çərçivəsindən RTCSessionDescription sinfi vasitəsilə qurulur. İlkinləşdirmə zamanı tip (RTCSdpTypeOffer və ya RTCSdpTypeAnswer) və SDP sətri göstərilir. Platforma avtomatik olaraq SDP-ni təhlil edir və ötürülən parametrlərə uyğun olaraq əlaqəni konfiqurasiya edir.

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 sətri ilə birbaşa işləmək imkanı tərtibatçılara çeviklik verir: müəyyən kodeklər əlavə edib silməklə, ICE parametrlərini konfiqurasiya etməklə və ya fərdi atributlar əlavə etməklə SDP-ni göndərməzdən əvvəl dəyişdirmək olar. Android tətbiqləri üçün şəbəkənin aşağı ötürmə qabiliyyəti zamanı SDP-də videonu söndürmək tez-tez tələb olunur — bu, SDP təsvirindən müvafiq m= sətirlərinin silinməsi ilə edilir.

Mobil inkişafda SDP

Mobil inkişafda SDP əsasən WebRTC kontekstində — videozənglər, səsli söhbətlər və striminq üçün tətbiqlər yaratmaq üçün istifadə olunur. Android və iOS-da mobil tətbiqlər həm təşəbbüskar, həm də SDP mesajlarını alan rolunda çıxış edə bilər ki, bu da simmetrik peer-to-peer əlaqələri qurmağa imkan verir.

Mobil tətbiqlərin özəlliyi dəyişkən şəbəkə keyfiyyəti şəraitində SDP ilə işləmək zərurətidir. Wi-Fi və mobil internet arasında keçid zamanı, həmçinin ötürmə qabiliyyətinin dəyişməsi zamanı yeni SDP təsvirinin yaradılması tələb oluna bilər. Bunun üçün renegotiation mexanizmi — createOffer() və setLocalDescription() vasitəsilə təkrar SDP mübadiləsi istifadə olunur.

Google WebRTC komandasının məlumatına görə (2023), mobil cihazlar üçün SDP mübadiləsinin optimallaşdırılması şəbəkə dəyişikliyi zamanı ICE restart, aşağı bitreytli kodeklərə üstünlük (audio üçün opus, video üçün VP8) və lazımsız media axınlarının xaric edilməsi hesabına SDP sətrinin minimal ölçüsünü əhatə edir. Əsas üstünlük mobil şəbəkələrdə əlaqə qurulması zamanı gecikmənin azaldılmasıdır.

Mobil şəbəkələr üçün SDP optimallaşdırılması

Mobil cihazlarda SDP ilə işləyərkən əsas vəzifələrdən biri SDP təsvirinin ölçüsünü minimallaşdırmaqdır. Audio və video ilə tipik WebRTC sessiyası üçün tam SDP 2–5 KB yer tuta bilər ki, bu da yavaş şəbəkələr üçün əhəmiyyətlidir. Optimallaşdırma BUNDLE (axınların birləşdirilməsi), dəstəklənməyən kodeklərin silinməsi və ICE namizədlərinin sıxışdırılmasını əhatə edir.

Mobil cihazların əlavə problemi SDP-nin məhdud ömür müddətidir. Qeyri-sabit əlaqə şəraitində SDP uzaq iştirakçı onu emal edə bilməmişdən əvvəl köhnələ bilər. Həll yolu — Answer almaq üçün qısa vaxt aşımından istifadə və zəruri hallarda SDP-nin təkrar göndərilməsidir. ICE restart mexanizmi RTCPeerConnection-u tam yenidən yaratmadan əlaqəni yeniləməyə imkan verir. a=ice-lite atributu server tərəfində ICE tətbiqini sadələşdirir.

SDP ilə iş üçün məşhur kitabxanalar

Mobil tətbiq tərtibatçıları SDP ilə işi asanlaşdıran hazır kitabxanalara malikdirlər. libjingle_peerconnection (Google WebRTC) — Android üçün əsas kitabxana, SDP idarəsi üçün tam API təmin edir. iOS üçün oxşar funksionallıqla WebRTC.framework istifadə olunur. Hər iki kitabxana avtomatik olaraq SDP yaradır və təhlil edir, lakin zəruri hallarda xam SDP sətrinə giriş imkanı verir.

SDP üzərində daha incə nəzarət üçün üçüncü tərəf həlləri mövcuddur: SDP-nin təhlili və dəyişdirilməsi üçün sdp-transform (JavaScript və ya Node.js), ICE namizədləri ilə iş üçün NICENICE (Java) və SDP daxil olmaqla bütün siqnal mübadiləsini öz üzərinə götürən WebRTC infrastruktur təminatçılarından hazır SDK-lar.