SDP — nedir, oturum tanımlama biçimi ve WebRTC'deki rolü

SDP (Session Description Protocol) Nedir?

SDP, multimedya oturum parametrelerini metin biçiminde tanımlamak için tasarlanmış bir uygulama katmanı protokolüdür. IETF'nin MMUSIC (Multiparty Multimedia Session Control) çalışma grubu bünyesinde geliştirilmiş ve ilk olarak 1998'de RFC 2327'de standartlaştırılmıştır. 2021'de, önceki sürüm RFC 4566'nın yerini alan güncel spesifikasyon RFC 8866 yayımlanmıştır.

SDP'nin temel görevi, oturum katılımcılarına bağlantı kurmak için gerekli tüm bilgileri sağlamaktır: hangi medya akışlarının iletileceği, hangi codec'lerin desteklendiği ve iletimin hangi ağ adresleri ve bağlantı noktaları üzerinden gerçekleşeceği. SDP, medya verilerinin kendisini iletmez, yalnızca bağlantının nasıl organize edilmesi gerektiğini tanımlar.

IETF RFC 8866'ya göre, SDP biçimi her biri tek harfli bir türle başlayan, ardından eşittir işareti ve bir değer gelen bir dizi satırdan oluşur. Örneğin, m=audio 5004 RTP/AVP 0 satırı, oturumun 5004 bağlantı noktasında RTP/AVP taşıma protokolü ve PCMU codec (tür 0) ile bir ses akışı içerdiği anlamına gelir.

SDP'nin Tarihi ve Standartlaştırılması

SDP'nin ilk sürümü, Nisan 1998'de MMUSIC grubunun çalışmasının bir sonucu olarak RFC 2327'de yayımlanmıştır. Protokol başlangıçta Mbone (Multicast Backbone) kapsamında çoklu yayın oturumlarını duyurmak için oluşturulmuştur. VoIP ve görüntülü konferansın gelişmesiyle SDP'nin uygulama alanı genişlemiş ve 2006'da güncellenen spesifikasyon RFC 4566 yayımlanmıştır.

SDP kullanımında gerçek bir atılım, 2011'de WebRTC'nin ortaya çıkışıyla gerçekleşmiştir. Google, tarayıcı tabanlı gerçek zamanlı iletişim çerçevesinde medya oturumlarını tanımlamak için ana mekanizma olarak SDP'yi entegre etmiştir. O zamandan beri SDP, tarayıcılardan iOS ve Android'deki mobil uygulamalara kadar her WebRTC uygulamasının zorunlu bir bileşeni haline gelmiştir.

2021'de IETF çalışma grubu, RFC 4566'nın yerini alan güncel SDP spesifikasyonu RFC 8866'yı yayımlamıştır. Güncellenen sürüm, ICE (Interactive Connectivity Establishment) işlemeyi netleştirmiş, DTLS (Datagram Transport Layer Security) desteğini güçlendirmiş ve grup oturumlarını tanımlama yeteneklerini genişletmiştir.

SDP ve Taşıma Protokolleri Arasındaki Fark

SDP, veri iletimine katılmaması bakımından taşıma protokollerinden temel olarak farklıdır. Tamamen tanımlayıcı bir işlev görür — multimedya dosyası meta verilerine benzer. RTP (Real-time Transport Protocol) ses ve video paketlerini iletirken ve RTCP iletim kalitesini kontrol ederken, SDP yalnızca hangi codec'lerin ve bağlantı noktalarının kullanılacağını belirtir.

Web geliştirmeden bir benzetme: SDP, sayfa yapısını tanımlayan HTML işaretlemesi gibidir, RTP ise gerçek resimler ve metindir. SDP olmadan, ağ bağlantısı zaten kurulmuş olsa bile oturum katılımcıları birbirlerine nasıl bağlanacaklarını bilemezler. NAT geçişi mekanizması (ICE) da ağ adayları hakkında bilgi iletmek için SDP'ye dayanır.

SDP'nin Yapısı Nasıldır

SDP yapısı, her biri type=value biçimini izleyen bir dizi metin satırı olarak organize edilmiştir. Tek harfli tür, satırın amacını tanımlar ve değer, ilgili değeri içerir. Tüm satırlar bir CRLF karakteriyle ayrılır.

RFC 8866 standardı, birkaç zorunlu ve isteğe bağlı alan tanımlar. Zorunlu alanlar protokol sürümünü (v=), oturum adını (s=) ve oturum başlangıç ve bitiş zamanını (t=) içerir. Kalan alanlar isteğe bağlıdır, ancak WebRTC oturumları için medya tanımları (m=), nitelikler (a=) ve ağ bilgileri (c=) de gereklidir.

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

Yukarıdaki örnek, bir WebRTC oturumu için tipik bir SDP bölümünü göstermektedir. v=0 satırı protokol sürümünü belirtir. o= alanı, oturum sahibinin tanımlayıcısını ve sürümünü içerir. s=- satırı oturum adını belirtir (tire boş ad anlamına gelir). t=0 0 alanı, oturumun zamanla sınırlı olmadığını gösterir.

a=group:BUNDLE audio video alanı, birden çok medya akışını tek bir taşıma kanalında gruplayan bir niteliktir. BUNDLE mekanizması, ses ve videoyu tek bir bağlantı üzerinden ileterek ağ kaynaklarından tasarruf sağlar. Bu, sınırlı bant genişliğine sahip mobil cihazlar için özellikle önemlidir.

Zorunlu SDP Alanları

RFC 8866 spesifikasyonu, bir dizi zorunlu ve isteğe bağlı alan tanımlar. Zorunlu alanlar v= (sürüm), s= (oturum adı) ve t= (zaman) içerir. o= (sahip) alanı, RFC'ye göre kesin olarak zorunlu olmasa da, gerçek uygulamalarda neredeyse her zaman bulunur.

m= (media) alanı en önemlilerinden biridir. Belirli bir medya akışını tanımlar ve medya türünü (audio, video, text, application), bağlantı noktasını, taşıma protokolünü ve desteklenen codec'lerin listesini içerir. WebRTC'de en yaygın kullanılan türler audio ve video'dur ve taşıma protokolleri RTP/SAVPF (Secure Audio/Video Profile with Feedback) veya UDP/TLS/RTP/SAVPF'dir.

a= (attribute) alanı en esnek ve genişletilebilir olanıdır. rtpmap (codec numarasını ada eşleme), fmtp (codec parametreleri), fingerprint (DTLS anahtar parmak izi), ice-ufrag ve ice-pwd (ICE kimlik bilgileri) ve diğer birçok niteliği içerebilir. SDP, nitelikler aracılığıyla modern güvenlik mekanizmalarını ve NAT geçişini destekler.

SDP WebRTC'de Nasıl Çalışır

WebRTC mimarisinde SDP, iki katılımcı arasında medya oturum parametrelerini tanımlamak ve müzakere etmek için bir sinyalleşme protokolü olarak işlev görür. SDP'nin kendisi bu tanımları iletme mekanizmasını tanımlamaz — bu görev, geliştiricinin WebSocket, HTTP veya başka bir protokol aracılığıyla bağımsız olarak uyguladığı sinyalleşme kanalı tarafından yönetilir.

Süreç, başlatıcının (arayan) bir SDP Offer oluşturmasıyla başlar. Bunun için tarayıcı, RTCPeerConnection nesnesinde createOffer() yöntemini çağırır. Oluşturulan SDP tanımı, başlatıcı tarafındaki tüm oturum parametrelerini içerir: desteklenen codec'ler, ağ adresleri, ICE adayları ve güvenlik gereksinimleri.

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

// createOffer'dan önce medya parçaları ekle
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP Offer oluştur
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Sinyalleşme kanalı aracılığıyla uzak eşe SDP gönder
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Offer oluşturulduktan ve setLocalDescription() aracılığıyla yerel tanım ayarlandıktan sonra, başlatıcı SDP dizesini sinyalleşme kanalı aracılığıyla uzak katılımcıya gönderir. Uzak katılımcı, SDP Offer'ı aldıktan sonra bir SDP Answer oluşturur ve geri gönderir. Bu alışverişe sinyalleşme değişimi denir ve eşler arası bağlantı kurulmadan önce zorunlu bir adımdır.

W3C WebRTC spesifikasyonuna göre, SDP değişimi ICE adayları başlamadan önce gerçekleşmelidir. Pratikte, birçok uygulama ICE trickle mekanizmasını kullanarak SDP ile paralel olarak ICE adayları gönderir. Bu, özellikle yüksek gecikmeli mobil ağlar için bağlantı kurma süresini kısaltır.

ICE'in SDP'deki Rolü

ICE (Interactive Connectivity Establishment), ağ adayları hakkında bilgi iletmek için SDP niteliklerini kullanan bir mekanizmadır. ICE adayları olası bağlantı yollarını tanımlar: host (yerel adres), srflx (NAT'tan sonraki adres, STUN aracılığıyla elde edilir) ve relay (TURN sunucu adresi).

SDP'de, ICE adayları a=candidate: nitelikleri aracılığıyla ve ayrıca ICE trafiği kimlik doğrulaması için ice-ufrag ve ice-pwd alanları aracılığıyla iletilir. Her aday, taşıma protokolünü (UDP, TCP), IP adresini, bağlantı noktasını ve önceliği içerir. Başarılı bir bağlantı, bağlantı denetimlerini geçen ilk aday aracılığıyla kurulur. ICE restart mekanizması, ağ değiştiğinde bağlantının güncellenmesine olanak tanır.

Mobil uygulamalar için ICE adayları özellikle önemlidir çünkü cihazlar genellikle NAT veya kurumsal güvenlik duvarlarının arkasındadır. ICE mekanizması, karmaşık ağ koşullarında bile çalışan bir yol bulmayı sağlar ve SDP bu bilgiler için taşıma kapsayıcısı olarak işlev görür.

WebRTC'de SDP Güvenliği

WebRTC'deki SDP, zorunlu olarak güvenlik niteliklerini, özellikle DTLS parmak izini ve SRTP parametrelerini içerir. a=fingerprint:sha-256 alanı, medya akışının kimlik doğrulaması ve şifrelenmesi için kullanılan DTLS sertifikasının parmak izini içerir. Bu nitelik olmadan WebRTC bağlantısı kurulmaz.

Ek güvenlik mekanizmaları, DTLS el sıkışma rolünü (active, passive, actpass) tanımlayan a=setup: niteliğini ve sunucu tarafında basitleştirilmiş ICE uygulaması için a=ice-lite: niteliğini içerir. Tüm bu parametreler SDP içinde iletilir ve medya verileri iletilmeye başlamadan önce her iki taraf tarafından doğrulanır.

SDP Türleri: Offer ve Answer

WebRTC modelinde iki tür SDP mesajı vardır: Offer (teklif) ve Answer (yanıt). Offer, bağlantıyı başlatan tarafından oluşturulur ve istenen medya oturumunun tam tanımını içerir. Answer, uzak katılımcı tarafından Offer'a yanıt olarak oluşturulur ve teklifin getirdiği kısıtlamaları dikkate alarak kendi yeteneklerini içerir.

Offer ve Answer arasındaki temel fark, niteliklerin anlamında yatar. Offer, başlatıcının önerebileceği tüm desteklenen codec'leri, taşıma protokollerini ve ağ adreslerini listeler. Answer, uzak tarafın desteklediği bu yeteneklerin bir alt kümesini seçer. Örneğin, Offer opus, ISAC ve PCMU öneriyorsa, Answer en çok tercih edilen codec olarak yalnızca opus'u seçebilir.

Değişim süreci W3C WebRTC spesifikasyonu tarafından düzenlenir ve RTCPeerConnection'ın birkaç durumunu içerir. createOffer() aracılığıyla Offer oluşturulup yerel tanım olarak ayarlandıktan sonra bağlantı have-local-offer durumuna girer. Answer alınıp setRemoteDescription() aracılığıyla uzak tanım olarak ayarlandıktan sonra bağlantı, medya iletimi için hazır olan nihai durum olan stable durumuna girer.

SDP'nin Mobil SDK'larda Kullanımı

WebRTC için mobil SDK'lar — Android için Google WebRTC ve iOS için WebRTC.framework — Offer ve Answer aracılığıyla SDP değişimini tam olarak destekler. Android'de, tarayıcı API'sine benzer şekilde, PeerConnection sınıfı createOffer() yöntemiyle bir Offer oluşturmak için kullanılır. Ortaya çıkan SDP tanımı, sinyalleşme kanalı aracılığıyla bir dize olarak iletilir.

iOS'te, SDP ile çalışma WebRTC çerçevesindeki RTCSessionDescription sınıfı aracılığıyla yapılır. Başlatma sırasında, tür (RTCSdpTypeOffer veya RTCSdpTypeAnswer) ve SDP dizesi belirtilir. Platform otomatik olarak SDP'yi ayrıştırır ve iletilen parametrelere göre bağlantıyı yapılandırır.

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

// Android'de SDP Offer oluştur
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Uzak eşe SDP dizesi gönder
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

SDP dizesiyle doğrudan çalışma yeteneği, geliştiricilere esneklik sağlar: göndermeden önce SDP'yi değiştirebilir, belirli codec'leri ekleyip kaldırabilir, ICE parametrelerini yapılandırabilir veya özel nitelikler ekleyebilirler. Android uygulamalarında, ağ bant genişliği düşük olduğunda SDP'de videoyu devre dışı bırakmak genellikle gereklidir — bu, SDP tanımından ilgili m= satırlarının kaldırılmasıyla yapılır.

Mobil Geliştirmede SDP

Mobil geliştirmede SDP, esas olarak WebRTC bağlamında kullanılır — görüntülü arama, sesli sohbet ve akış uygulamaları oluşturmak için. Android ve iOS'taki mobil uygulamalar, SDP mesajlarının hem başlatıcısı hem de alıcısı olarak hareket edebilir ve simetrik eşler arası bağlantılara olanak tanır.

Mobil uygulamaların bir özelliği, değişken ağ kalitesi koşullarında SDP ile çalışma gerekliliğidir. Wi-Fi ve mobil internet arasında geçiş yaparken ve bant genişliği değiştiğinde yeni bir SDP tanımı oluşturulması gerekebilir. Bu, yeniden müzakere mekanizması kullanılarak yapılır — createOffer() ve setLocalDescription() aracılığıyla tekrarlanan SDP değişimi.

Google WebRTC ekibine (2023) göre, mobil cihazlar için SDP değişimini optimize etmek, ağ değişiklikleri sırasında ICE restart kullanımını, düşük bit hızlı codec'leri (ses için opus, video için VP8) önceliklendirmeyi ve gereksiz medya akışlarını hariç tutarak SDP dize boyutunu en aza indirmeyi içerir. Temel avantaj, mobil ağ koşullarında bir bağlantı kurarken gecikmenin azaltılmasıdır.

SDP'nin Mobil Ağlar İçin Optimizasyonu

Mobil cihazlarda SDP ile çalışırken temel görevlerden biri, SDP tanım boyutunu en aza indirmektir. Ses ve video içeren tipik bir WebRTC oturumu için tam SDP 2–5 KB yer kaplayabilir ve bu, yavaş ağlar için önemlidir. Optimizasyon, BUNDLE (akış çoğullama) kullanımını, desteklenmeyen codec'lerin kaldırılmasını ve ICE adaylarının sıkıştırılmasını içerir.

Mobil cihazlar için ek bir sorun, SDP'nin sınırlı ömrüdür. Kararsız bağlantı koşullarında, SDP, uzak katılımcı onu işlemeden önce güncelliğini yitirebilir. Çözüm, Answer almak için kısa zaman aşımları kullanmak ve gerekirse SDP'yi yeniden göndermektir. ICE restart mekanizması, RTCPeerConnection'ı tamamen yeniden oluşturmadan bağlantıyı güncellemeye olanak tanır. a=ice-lite niteliği, sunucu tarafındaki ICE uygulamasını basitleştirir.

SDP ile Çalışmak İçin Popüler Kütüphaneler

Mobil uygulama geliştiricileri, SDP ile çalışmayı basitleştiren hazır kütüphanelere erişebilir. libjingle_peerconnection (Google WebRTC), Android için ana kütüphanedir ve SDP yönetimi için eksiksiz bir API sağlar. iOS için, benzer işlevselliğe sahip WebRTC.framework kullanılır. Her iki kütüphane de otomatik olarak SDP oluşturur ve ayrıştırır, ancak gerektiğinde ham SDP dizesine erişim sağlar.

SDP üzerinde daha ince kontrol için üçüncü taraf çözümler mevcuttur: SDP'yi ayrıştırmak ve değiştirmek için sdp-transform (JavaScript veya Node.js), ICE adaylarıyla çalışmak için NICENICE (Java) ve SDP dahil tüm sinyalleşme değişimini yöneten WebRTC altyapı sağlayıcılarından hazır SDK'lar.