SDP — ano ito, format ng paglalarawan ng session at papel sa WebRTC

Ano ang SDP (Session Description Protocol)?

SDP — ay isang application layer protocol na nilalayong ilarawan ang mga parameter ng multimedia session sa text format. Ito ay binuo sa loob ng MMUSIC (Multiparty Multimedia Session Control) working group ng IETF at unang na-standardize sa RFC 2327 noong 1998. Noong 2021, nailathala ang kasalukuyang specification na RFC 8866, na pumalit sa nakaraang bersyon na RFC 4566.

Ang pangunahing gawain ng SDP ay bigyan ang mga kalahok ng session ng lahat ng kinakailangang impormasyon para magtatag ng koneksyon: anong mga media stream ang ipapadala, anong codec ang sinusuportahan, sa anong mga network address at port magaganap ang pagpapadala. Hindi nagpapadala ang SDP ng aktwal na media data, kundi inilalarawan lamang kung paano dapat organisahin ang koneksyon.

Ayon sa IETF RFC 8866, ang format ng SDP ay binubuo ng isang set ng mga linya, bawat isa ay nagsisimula sa isang letrang uri, na sinusundan ng equal sign at isang halaga. Halimbawa, ang linyang m=audio 5004 RTP/AVP 0 ay nangangahulugan na ang session ay may kasamang audio stream sa port 5004 na may transport protocol na RTP/AVP at codec na PCMU (uri 0).

Kasaysayan at standardisasyon ng SDP

Ang unang bersyon ng SDP ay nailathala sa RFC 2327 noong Abril 1998 bilang resulta ng gawain ng grupong MMUSIC. Ang protocol ay orihinal na ginawa para sa pag-aanunsyo ng mga multicast session sa loob ng Mbone (Multicast Backbone). Sa pag-unlad ng VoIP at video conferencing, lumawak ang saklaw ng aplikasyon ng SDP, at noong 2006 nailathala ang na-update na specification na RFC 4566.

Ang tunay na pambihirang tagumpay sa paggamit ng SDP ay naganap sa pagdating ng WebRTC noong 2011. Isinama ng Google ang SDP bilang pangunahing mekanismo para sa paglalarawan ng media session sa framework nito para sa real-time na komunikasyon sa browser. Simula noon, naging mandatoryong bahagi ang SDP ng bawat implementasyon ng WebRTC — mula sa mga browser hanggang sa mga mobile application sa iOS at Android.

Noong 2021, inilathala ng IETF working group ang RFC 8866 — ang kasalukuyang specification ng SDP na pumalit sa RFC 4566. Pinalinaw ng na-update na bersyon ang paghawak ng ICE (Interactive Connectivity Establishment), suporta para sa DTLS (Datagram Transport Layer Security), at pinalawak ang mga kakayahan sa paglalarawan ng group session.

Pagkakaiba ng SDP sa mga transport protocol

SDP ay pangunahing naiiba sa mga transport protocol dahil hindi ito nakikilahok sa pagpapadala ng data. Ito ay gumaganap lamang ng isang deskriptibong function — katulad ng metadata ng isang multimedia file. Habang ang RTP (Real-time Transport Protocol) ay nagpapadala ng audio at video packet, at kinokontrol ng RTCP ang kalidad ng transmission, ang SDP ay nagpapahiwatig lamang kung aling mga codec at port ang gagamitin.

Isang analogy mula sa web development: Ang SDP ay ang HTML markup na naglalarawan ng istraktura ng page, at ang RTP ay ang mga larawan at teksto mismo. Kung wala ang SDP, hindi alam ng mga kalahok ng session kung paano magkonekta sa isa't isa, kahit na naitatag na ang network connection. Ang mekanismong NAT-traversal (ICE) ay umaasa rin sa SDP para sa pagpapadala ng impormasyon tungkol sa mga network candidate.

Paano nakaayos ang istraktura ng SDP

Ang istraktura ng SDP ay organisado bilang isang pagkakasunod-sunod ng mga text line, bawat isa ay sumusunod sa format na type=value. Ang isang letrang uri ay tumutukoy sa layunin ng linya, at ang halaga ay naglalaman ng kaukulang halaga. Lahat ng linya ay pinaghihiwalay ng CRLF newline character.

Ang pamantayang RFC 8866 ay tumutukoy ng ilang mandatory at opsyonal na field. Kasama sa mandatory field ang protocol version (v=), session name (s=), session start at end time (t=). Ang ibang field ay opsyonal, ngunit para sa mga WebRTC session, kailangan din ang mga media description (m=), attribute (a=), at network information (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

Sa halimbawa sa itaas, ipinapakita ang isang tipikal na SDP segment para sa isang WebRTC session. Ang linyang v=0 ay nagpapahiwatig ng protocol version. Ang field na o= ay naglalaman ng identifier ng may-ari ng session at ang bersyon nito. Ang linyang s=- ay nagtatakda ng session name (ang gitling ay nangangahulugang walang laman na pangalan). Ang field na t=0 0 ay nagpapahiwatig na ang session ay hindi limitado sa oras.

Ang field na a=group:BUNDLE audio video ay isang attribute na nag-grupo ng maraming media stream sa isang transport channel. Ang mekanismong BUNDLE ay nagbibigay-daan sa pagtitipid ng mga network resource sa pamamagitan ng pagpapadala ng audio at video sa pamamagitan ng isang koneksyon. Ito ay lalong mahalaga para sa mga mobile device na may limitadong bandwidth.

Mandatory field ng SDP

Ang specification na RFC 8866 ay tumutukoy ng isang set ng mandatory at opsyonal na field. Kasama sa mandatory field ang v= (version), s= (session name) at t= (time). Ang field na o= (owner), bagama't hindi mahigpit na mandatory ayon sa RFC, ay halos palaging naroroon sa mga tunay na implementasyon.

Ang field na m= (media) ay isa sa pinakamahalaga. Inilalarawan nito ang isang partikular na media stream at naglalaman ng uri ng media (audio, video, text, application), port, transport protocol, at listahan ng mga suportadong codec. Sa WebRTC, ang mga pinakamadalas na ginagamit na uri ay audio at video na may transport protocol na RTP/SAVPF (Secure Audio/Video Profile with Feedback) o UDP/TLS/RTP/SAVPF.

Ang field na a= (attribute) ay ang pinaka-flexible at napapalawak. Maaari itong maglaman ng rtpmap (pagmamapa ng numero ng codec sa pangalan), fmtp (parameter ng codec), fingerprint (fingerprint ng DTLS key), ice-ufrag at ice-pwd (mga kredensyal ng ICE) at marami pang ibang attribute. Sa pamamagitan ng mga attribute, sinusuportahan ng SDP ang mga modernong mekanismo ng seguridad at NAT-traversal.

Paano gumagana ang SDP sa WebRTC

Sa arkitektura ng WebRTC, ang SDP ay gumaganap bilang signaling protocol para sa paglalarawan at pagsasaayos ng mga parameter ng media session sa pagitan ng dalawang kalahok. Ang SDP mismo ay hindi tumutukoy ng mekanismo para sa pagpapadala ng mga paglalarawang ito — ang gawaing ito ay nalulutas ng signaling channel na independiyenteng ipinapatupad ng developer sa pamamagitan ng WebSocket, HTTP, o ibang protocol.

Ang proseso ay nagsisimula sa paglikha ng SDP offer — Offer ng initiator (tumatawag). Para dito, tinatawag ng browser ang method na createOffer() sa RTCPeerConnection object. Ang nabuong SDP description ay naglalaman ng lahat ng parameter ng session mula sa panig ng initiator: mga suportadong codec, network address, ICE candidate, at mga kinakailangan sa seguridad.

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

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

// Ipadala ang SDP string sa malayong kapareha
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Pagkatapos ng paggawa ng Offer at pagtatakda ng lokal na paglalarawan sa pamamagitan ng setLocalDescription(), ipinapadala ng initiator ang SDP string sa malayong kalahok sa pamamagitan ng signaling channel. Ang malayong kalahok, pagkatanggap ng SDP Offer, ay lumikha ng SDP response — Answer — at ipapadala ito pabalik. Ang palitang ito ay tinatawag na signaling exchange at ito ay isang mandatoryong hakbang bago magtatag ng peer-to-peer na koneksyon.

Ayon sa W3C WebRTC Specification, ang SDP exchange ay dapat maganap bago magsimula ang pagpapalitan ng ICE candidate. Sa praktika, maraming implementasyon ang nagpapadala ng mga ICE candidate nang parallel sa SDP, gamit ang mekanismong ICE trickle. Ito ay nagpapaikli sa oras ng pagtatag ng koneksyon, lalo na para sa mga mobile network na may mataas na latency.

Ang papel ng ICE sa SDP

ICE (Interactive Connectivity Establishment) — ay isang mekanismo na gumagamit ng mga attribute ng SDP para magpadala ng impormasyon tungkol sa mga network candidate. Ang mga ICE candidate ay naglalarawan ng mga posibleng path ng koneksyon: host (lokal na address), srflx (address pagkatapos ng NAT, nakuha sa pamamagitan ng STUN) at relay (address ng TURN server).

Sa SDP, ang mga ICE candidate ay ipinapadala sa pamamagitan ng mga attribute na a=candidate:, pati na rin sa pamamagitan ng mga field na ice-ufrag at ice-pwd para sa authentication ng ICE traffic. Ang bawat candidate ay may kasamang transport protocol (UDP, TCP), IP address, port, at priority. Ang matagumpay na koneksyon ay itinatag sa pamamagitan ng unang candidate na pumasa sa connectivity test. Ang mekanismong ICE restart ay nagbibigay-daan sa pag-update ng koneksyon kapag nagbago ang network.

Para sa mga mobile application, ang mga ICE candidate ay lalong mahalaga dahil ang mga device ay madalas na nasa likod ng NAT o corporate firewall. Ang mekanismong ICE ay nagbibigay-daan sa paghahanap ng gumaganang path kahit sa mga kumplikadong kondisyon ng network, at SDP ay nagsisilbing transport container para sa impormasyong ito.

Seguridad ng SDP sa WebRTC

SDP sa WebRTC ay may kasamang mandatoryong security attribute, partikular ang DTLS fingerprint at SRTP parameters. Ang field na a=fingerprint:sha-256 ay naglalaman ng fingerprint ng DTLS certificate na ginamit para sa authentication at encryption ng media stream. Kung wala ang attribute na ito, hindi mabubuo ang WebRTC connection.

Ang mga karagdagang mekanismo ng seguridad ay kinabibilangan ng attribute na a=setup:, na tumutukoy sa papel ng DTLS handshake (active, passive, actpass), at a=ice-lite: para sa pinasimpleng ICE implementation sa server side. Lahat ng parameter na ito ay ipinapadala sa loob ng SDP at sinusuri ng magkabilang panig bago magsimula ang pagpapadala ng media data.

Mga Uri ng SDP: Offer at Answer

Sa modelo ng WebRTC, mayroong dalawang uri ng SDP message: Offer (alok) at Answer (sagot). Ang Offer ay ginawa ng initiator ng koneksyon at naglalaman ng kumpletong paglalarawan ng nais na media session. Ang Answer ay ginawa ng malayong kalahok bilang tugon sa Offer at naglalaman ng kanyang mga kakayahan na isinasaalang-alang ang mga limitasyon na ipinataw ng alok.

Ang pangunahing pagkakaiba sa pagitan ng Offer at Answer ay nasa semantika ng mga attribute. Ang Offer ay naglilista ng lahat ng suportadong codec, transport protocol, at network address na maaaring ihandog ng initiator. Ang Answer ay pumipili ng subset ng mga kakayahang ito na sinusuportahan ng malayong partido. Halimbawa, kung ang Offer ay nag-aalok ng opus, ISAC at PCMU, ang Answer ay maaaring pumili lamang ng opus bilang pinakapaboritong codec.

Ang proseso ng pagpapalitan ay pinamamahalaan ng W3C WebRTC specification at may kasamang ilang estado ng RTCPeerConnection. Pagkatapos ng paggawa ng Offer sa pamamagitan ng createOffer() at pagtatakda nito bilang lokal na paglalarawan, ang koneksyon ay pumapasok sa estado na have-local-offer. Pagkatanggap ng Answer at pagtatakda nito bilang malayong paglalarawan sa pamamagitan ng setRemoteDescription(), ang koneksyon ay pumapasok sa stable — ang huling estado na handa para sa media transmission.

Paggamit ng SDP sa mobile SDK

Ang mga mobile SDK para sa WebRTC — Google WebRTC para sa Android at WebRTC.framework para sa iOS — ay ganap na sumusuporta sa SDP exchange sa pamamagitan ng Offer at Answer. Sa Android, para gumawa ng Offer, ginagamit ang PeerConnection class na may createOffer() method, katulad ng browser API. Ang nakuhang SDP description ay ipinapadala bilang string sa pamamagitan ng signaling channel.

Sa iOS, ang pagtatrabaho sa SDP ay ginagawa sa pamamagitan ng RTCSessionDescription class mula sa WebRTC framework. Sa initialization, tinutukoy ang uri (RTCSdpTypeOffer o RTCSdpTypeAnswer) at SDP string. Awtomatikong nami-parse ng platform ang SDP at kino-configure ang koneksyon ayon sa mga ipinadalang parameter.

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())

Ang kakayahang direktang magtrabaho sa SDP string ay nagbibigay ng flexibility sa mga developer: maaari nilang baguhin ang SDP bago ipadala, magdagdag o mag-alis ng mga partikular na codec, i-configure ang ICE parameters, o magdagdag ng custom na attribute. Para sa mga Android application, madalas na kinakailangan na i-disable ang video sa SDP kapag mababa ang network bandwidth — ito ay ginagawa sa pamamagitan ng pag-alis ng kaukulang m= lines mula sa SDP description.

SDP sa mobile development

Sa mobile development, ang SDP ay pangunahing ginagamit sa konteksto ng WebRTC — para sa paggawa ng mga application na may video call, voice chat, at streaming. Ang mga mobile application sa Android at iOS ay maaaring kumilos bilang initiator o receiver ng mga SDP message, na nagbibigay-daan sa pagbuo ng simetriko peer-to-peer na koneksyon.

Ang kakaiba ng mga mobile application ay ang pangangailangan na magtrabaho sa SDP sa mga kondisyon ng nag-iiba-ibang kalidad ng network. Sa paglipat sa pagitan ng Wi-Fi at mobile internet, pati na rin sa pagbabago ng bandwidth, maaaring kailanganin ang pagbuo ng bagong SDP description. Para dito, ginagamit ang mekanismong renegotiation — paulit-ulit na SDP exchange sa pamamagitan ng createOffer() at setLocalDescription().

Ayon sa Google WebRTC team (2023), ang optimization ng SDP exchange para sa mga mobile device ay kinabibilangan ng paggamit ng ICE restart sa pagbabago ng network, prioritization ng mga codec na may mababang bitrate (opus para sa audio, VP8 para sa video), at minimal na laki ng SDP string sa pamamagitan ng pagbubukod ng mga hindi kinakailangang media stream. Ang pangunahing bentahe ay ang nabawasang latency sa pagtatag ng koneksyon sa mga mobile network.

Optimization ng SDP para sa mga mobile network

Isa sa mga pangunahing gawain sa pagtatrabaho sa SDP sa mga mobile device ay ang pag-minimize ng laki ng SDP description. Ang buong SDP para sa isang tipikal na WebRTC session na may audio at video ay maaaring sumakop ng 2–5 KB, na makabuluhan para sa mabagal na network. Ang optimization ay kinabibilangan ng paggamit ng BUNDLE (pagsasama-sama ng streams), pag-alis ng hindi suportadong codec, at compression ng ICE candidate.

Ang karagdagang problema ng mga mobile device ay ang limitadong buhay ng SDP. Sa mga kondisyon ng hindi matatag na koneksyon, ang SDP ay maaaring mag-expire bago ito maproseso ng malayong kalahok. Ang solusyon ay ang paggamit ng maikling timeout para sa pagtanggap ng Answer at muling pagpapadala ng SDP kung kinakailangan. Ang mekanismong ICE restart ay nagbibigay-daan sa pag-update ng koneksyon nang hindi ganap na muling ginagawa ang RTCPeerConnection. Ang attribute na a=ice-lite ay nagpapasimple ng ICE implementation sa server side.

Mga sikat na library para sa pagtatrabaho sa SDP

Ang mga developer ng mobile application ay may access sa mga handa nang library na nagpapadali sa pagtatrabaho sa SDP. libjingle_peerconnection (Google WebRTC) — ang pangunahing library para sa Android, na nagbibigay ng kumpletong API para sa SDP management. Para sa iOS, ginagamit ang WebRTC.framework na may katulad na functionality. Ang parehong library ay awtomatikong gumagawa at nagpa-parse ng SDP, ngunit nagbibigay ng access sa raw SDP string kung kinakailangan.

Para sa mas pinong kontrol sa SDP, may mga third-party na solusyon: sdp-transform (JavaScript o Node.js) para sa pag-parse at pagbabago ng SDP, NICENICE (Java) para sa pagtatrabaho sa mga ICE candidate, at mga handa nang SDK mula sa mga provider ng WebRTC infrastructure na humahawak sa buong signaling exchange, kasama ang SDP.