Bölüm 74: Gerçek Zamanlı Ses ve Görüntü

Güvenilirlikten. Kaybolan bir ses paketini yeniden istemek mümkün, ama yeniden gönderilen paket geldiğinde o sesin çalınması gereken an çoktan geçmiş oluyor. 7. bölümde bir cümleyle söylemiştim: geç gelen veri hiç gelmemiş sayılır. Bu bölüm o cümlenin mühendisliği.

Canlı görüşme, kitabın izlediği isteğin tam tersi. Sayfa bir bayt bile eksik gelse bozuktu ama birkaç saniye gecikmesi dert değildi. Görüşmede birkaç paketin kaybolması dert değil, yarım saniyelik gecikme ise konuşmayı bitiriyor.

Peki kaç milisaniye “çok” sayılıyor?

Gecikme bütçesi

Uluslararası Telekomünikasyon Birliği’nin G.114 tavsiyesi bu sorunun resmî cevabı. Tek yönlü gecikme 150 milisaniyenin altında kaldığında çoğu uygulama bundan belirgin biçimde etkilenmiyor. Genel ağ planlamasında 400 milisaniye aşılmaması gereken sınır. Çok etkileşimli işler ise 100 milisaniyenin altındaki gecikmelerden bile etkilenebiliyor.

Bu bütçe yalnızca ağa ait değil. Ağızdan kulağa giden yolun her aşaması ondan pay alıyor. Aşağıdaki dağılım bir örnek; sayılar kodeğe, cihaza ve yola göre değişiyor ama kalemler değişmiyor:

Ağın payı, kalemlerden yalnızca biri. 2. bölümde yayılım gecikmesinin ışık hızıyla sınırlı olduğunu görmüştün. Kıtalar arası bir görüşmede yalnızca o kalem 150 milisaniyeyi zorlayabiliyor; 64. bölümdeki jeostatik uydu hattında ise tek başına aşıyor.

Yirmi milisaniyelik ses nasıl pakete dönüşür?

54. bölümdeki telefon sesi saniyede 8.000 örnek, örnek başına 8 bit: 64 kbit/s. Bu sesi 20 milisaniyelik dilimlere bölüp her dilimi bir pakete koyalım.

• 20 ms’lik ses: 64.000 × 0,020 = 1.280 bit, yani 160 bayt.
• Üstüne başlıklar: RTP 12, UDP 8, IPv4 20 bayt. Toplam 200 bayt.
• Saniyede 50 paket gidiyor: 200 × 8 × 50 = 80 kbit/s.

Konuşmanın kendisi 64 kbit/s, taşıması 80 kbit/s. IP katmanında her beş bayttan biri başlık. Daha verimli bir kodek bu oranı büyütüyor. Geniş bantlı konuşma için sık kullanılan Opus 20 kbit/s civarında çalışınca 20 ms’lik ses yaklaşık 50 bayta sığıyor, başlık ise yine 40 bayt. Burada başlık, taşınan sesin neredeyse kendisi kadar.

Neden daha büyük paketler kullanılmıyor? Çünkü her ek milisaniye doğrudan gecikme. 60 ms’lik bir paket başlık payını üçte birine indirir ama gönderen, ilk sesi yollamadan önce 60 ms beklemek zorunda kalır. Daha küçük paket ise başlık payını büyütür. 20 ms, telefonculuğun bu iki bedel arasında uzun süredir kabul ettiği orta nokta.

Jitter: paketler aynı aralıkla gelmez

Gönderen her 20 milisaniyede bir paket gönderiyor. Paketler ise alıcıya 20 milisaniye arayla gelmiyor. Biri boş bir kuyruktan geçiyor, biri 40. bölümdeki dolu bir kuyrukta bekliyor. Gecikmedeki bu oynamaya jitter deniyor.

Alıcı paketleri geldikleri anda çalsaydı ses kesik kesik çıkardı. Bunun yerine her paketi gönderilme anından sabit bir süre sonra çalıyor. Aradaki bekleme payı oynatma tamponu. Tampondan uzun süren paket çalma anını kaçırıyor ve atılıyor; oynatıcı için o paket kaybolmuştan farksız.

Tampon uzadıkça geç kalan paket azalıyor ama konuşmanın gecikmesi artıyor. Bu yüzden iyi bir alıcı tamponun boyunu ağa göre ayarlıyor. Kurose ve Ross’un aktardığı klasik yöntemde alıcı ortalama gecikmeyi ve gecikmenin ortalamadan sapmasını yavaşça güncellenen iki ortalamayla izliyor. Çalma anını ortalamanın üstüne sapmanın birkaç katını ekleyerek seçiyor. Ayarı da iki konuşma arasındaki sessizliklerde değiştiriyor; sessizliği birkaç milisaniye uzatmayı kulak fark etmiyor, konuşmanın ortasındaki bir sıçramayı fark ediyor.

Jitter’ın kendisi de ölçülüyor ve karşı tarafa bildiriliyor. RTP’nin belirtimi alıcıya her paketle güncellenen tek bir formül veriyor. D, ardışık iki paketin geliş aralığı ile gönderiliş aralığı arasındaki fark:

J = J + ( |D| - J ) / 16

Her yeni ölçüm tahmini on altıda biri kadar kaydırıyor. Tek bir tuhaf paket sayıyı sarsmıyor, kalıcı bir değişim ise birkaç düzine paket içinde yerleşiyor.

Kaybı yeniden istemek yerine gizlemek

Kaybolan paketin yerine bir şey çalınmak zorunda. En basiti gizleme: bir önceki sesi tekrarlamak ya da iki komşu arasını doldurmak. Tek tük kayıplarda kulak bunu çoğu zaman fark etmiyor.

Daha güçlüsü, kaybı önceden hesaba katıp fazladan göndermek:

• Eşlik paketi. Her n pakete bir paket daha ekleniyor; içinde n paketin XOR’u var. Gruptan tek bir paket kaybolursa geri kalanlarla birlikte yeniden kurulabiliyor. Bedeli bant genişliğinde 1/n kadar artış ve alıcının grubun tamamını beklemesi.
• Düşük hızlı kopya. Her pakete bir önceki sesin daha düşük kaliteli bir kopyası iliştiriliyor. Paket kaybolursa bir sonrakinin içindeki kopya çalınıyor. Opus bu yöntemi kendi içinde yapabiliyor: kodlayıcı, önceki çerçevenin düşük hızlı bir kopyasını şimdikinin içine gömüyor.
• Serpiştirme. Ardışık küçük ses parçaları farklı paketlere dağıtılıyor. Bir paket kaybolunca uzun bir kesinti yerine birkaç çok kısa boşluk oluşuyor ve bunlar daha kolay gizleniyor.

Görüntü farklı davranıyor. 73. bölümde karelerin birbirine dayandığını görmüştün. Kaybolan bir parça, bir sonraki bağımsız kareye kadar bütün kareleri bozabiliyor. Bu yüzden görüntüde iki yol daha kullanılıyor. Gidiş-dönüş süresi kısaysa kaybolan paket yeniden isteniyor. Değilse alıcı gönderenden hemen yeni bir bağımsız kare istiyor.

RTP ve RTCP

Ses ve görüntü paketlerinin ortak zarfı RTP (Real-time Transport Protocol). 2003’te RFC 3550 olarak son biçimini aldı. Adında “taşıma” geçse de UDP’nin üstünde, uygulamanın içinde yaşıyor. Sabit başlığı 12 bayt:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+-+-+-------+-+-------------+-------------------------------+
|V=2|P|X|  CC   |M|     PT      |         sıra numarası         |
+---+-+-+-------+-+-------------+-------------------------------+
|                         zaman damgası                         |
+---------------------------------------------------------------+
|                    kaynak kimliği (SSRC)                      |
+---------------------------------------------------------------+

Alanların her biri yukarıdaki bir sorunu çözüyor:

• Yük türü (PT, 7 bit) paketin hangi kodekle kodlandığını söylüyor.
• Sıra numarası (16 bit) her pakette bir artıyor. Alıcı kaybı ve sıra bozulmasını buradan görüyor. Belirtim ilk değerin rastgele seçilmesini istiyor; şifreli akışlarda tahmin edilebilir bir başlangıç, saldırgana bilinen bir düz metin verirdi.
• Zaman damgası (32 bit) paketteki ilk örneğin alındığı anı, örnekleme saatinin biriminde söylüyor. 8 kHz’lik seste 20 ms’lik her paket bu sayıyı 160 artırıyor. Jitter hesabı ve çalma anı bu sayıdan çıkıyor.
• SSRC akışın kimliği. Rastgele seçiliyor; aynı oturumda birden çok kaynak varsa akışlar bununla ayrılıyor.

Yanındaki RTCP denetim trafiğini taşıyor. Alıcılar düzenli raporlarla kayıp oranını, jitter’ı ve gidiş-dönüş süresini hesaplamaya yetecek zamanları geri bildiriyor. Gönderen de göndericinin kendi saatiyle RTP zaman damgası arasındaki eşlemeyi yayımlıyor. Ses ve görüntü iki ayrı akış olarak geldiği hâlde dudak hareketinin sesle aynı anda oynaması bu eşleme sayesinde. Denetim trafiğinin kendisi de sınırlı: belirtim ona oturumun bant genişliğinin %5’ini ayırmayı ve raporlar arasında en az 5 saniye bırakmayı öneriyor.

RTP’nin kendisi şifreleme yapmıyor. SRTP (RFC 3711) yükü şifreliyor ve paketin değiştirilmediğini doğruluyor. Aşağıda göreceğin WebRTC’de şifresiz medya diye bir seçenek yok.

Çağrıyı kurmak: SIP ve SDP

Ses paketleri akmaya başlamadan önce iki tarafın buluşması, hangi kodeği ve hangi portu kullanacaklarında anlaşması gerekiyor. İnternet telefonunun bu işi yapan protokolü SIP (RFC 3261, 2002). Metin tabanlı ve 13. bölümdeki HTTP’ye çok benziyor: INVITE bir arama başlatıyor, 180 Ringing karşı tarafın çaldığını, 200 OK açıldığını söylüyor, ACK bunu onaylıyor, BYE kapatıyor. Adres de bir URL’ye benziyor: sip:ali@example.com.

Bir kural önemli: SIP yalnızca buluşturuyor. Ses paketleri çoğu zaman SIP sunucusuna hiç uğramadan iki uç arasında doğrudan akıyor.

Anlaşmanın içeriğini SDP taşıyor. Örnek bir teklif:

v=0
o=- 4611731400430051336 2 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 49170 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

m= satırı “49170 numaralı porttan ses göndereceğim, yük türü 0 ya da 8 olabilir” diyor. 0, Kuzey Amerika’nın μ-yasası kodlaması; 8, Türkiye’nin de kullandığı A-yasası. Karşı taraf bunlardan birini seçip kendi portunu yazdığı bir cevap gönderiyor.

c= satırındaki IP adresi bir sorunun kaynağı. Adres, paketin başlığında değil yükün içinde yazıyor. 46. bölümde bunun adres çeviricileri için neden dert olduğunu görmüştün: çevirici başlıktaki adresi değiştiriyor ama yükteki adres eski, özel ağın adresi olarak kalıyor. Ev router’larındaki SIP’e özel düzeltme modüllerinin kötü ünü buradan.

Tarayıcıdan tarayıcıya: WebRTC

Bugün görüntülü görüşmelerin çoğu tarayıcıda, eklentisiz yapılıyor. Bunu sağlayan WebRTC, Ocak 2021’de hem W3C tavsiyesi hem de bir dizi IETF standardı oldu. İki yarısı var: tarayıcının JavaScript arayüzünü W3C, telden geçen protokolleri IETF tanımlıyor.

Protokol tarafı kitabın birçok durağını bir araya getiriyor:

• Medya SRTP ile gidiyor. Anahtarlar, 11. bölümdeki el sıkışmanın UDP üstündeki kardeşi DTLS ile kuruluyor.
• İki tarayıcının birbirine ulaşması için ICE (RFC 8445) çalışıyor. Her taraf aday adreslerini topluyor: kendi yerel adresi, bir STUN sunucusuna sorarak öğrendiği çeviricinin dış adresi ve son çare olarak bir TURN sunucusundaki aktarma adresi. Adaylar karşılıklı sınanıyor ve çalışan en iyi çift seçiliyor. Bu 46. bölümdeki delik açmanın standartlaşmış hâli.
• Veri kanalları SCTP’yi DTLS’in içinde taşıyor; oyunlar ve dosya aktarımı bunu kullanıyor.

Standartta tanımlanmayan tek parça, iki tarayıcının adaylarını ve SDP’lerini birbirine nasıl ileteceği. Buna sinyalleşme deniyor ve her uygulama kendi yolunu seçiyor. Çoğu zaman sıradan bir sunucuya açılan bir WebSocket bağlantısı bu işi görüyor. 72. bölümdeki karma mimari tam da bu: tanıştırma merkezde, konuşma eşler arasında.

Chrome’da chrome://webrtc-internals adresini açık tutarak bir görüşme yaparsan bu bölümdeki her şeyi canlı görürsün: seçilen aday çifti, gidiş-dönüş süresi, jitter, kaybolan paket sayısı ve anlık bit hızı.

Telefonda ses: VoLTE

Cep telefonundaki sıradan bir arama da bugün çoğu zaman aynı parçalarla yapılıyor. 33. bölümdeki 4G şebekesinde ses için ayrı bir devre yok; ses IP paketleriyle taşınıyor. Adı VoLTE. Çağrıyı kuran protokol yine SIP, onu işleten şebeke çekirdeği bileşeninin adı IMS.

Farkı, şebekenin sesi taşıyan paketlere verdiği söz. 40. bölümde gördüğün servis sınıflarından birincisi, QCI 1, konuşma için ayrılmış. Bant genişliği garanti ediliyor, paket gecikme bütçesi 100 ms ve izin verilen kayıp oranı yüzde bir. Radyo tarafında da 40 baytlık IP, UDP ve RTP başlıkları birkaç bayta sıkıştırılıyor; yukarıdaki hesapta başlığın neden bu kadar pahalı olduğunu görmüştün. Kodek de gelişti. 2014’te 3GPP’nin standartlaştırdığı EVS, 20 kHz’e kadar ses bandını taşıyabiliyor. Eski telefonun 4 kHz’lik bandıyla karşılaştırınca fark, bir radyo yayınını bir müzik kaydıyla karşılaştırmak gibi.

Özet

• Gecikme bütçesi kısa: G.114’e göre tek yönde 150 ms’nin altı çoğu uygulama için rahat, 400 ms genel ağ planlamasında aşılmaması gereken sınır. Ağ bu bütçenin yalnızca bir kalemi.
• Küçük paket, pahalı başlık: 20 ms’lik 64 kbit/s ses 160 bayt yük ve 40 bayt başlık taşır; 64 kbit/s’lik ses IP katmanında 80 kbit/s olur.
• Oynatma tamponu jitter’ı emer: her paket sabit bir gecikmeyle çalınır, bundan geç gelen paket kaybolmuş sayılır. Tamponun boyu gecikme ile kayıp arasındaki ödünleşimdir.
• Kayıp yeniden istenmez, gizlenir ya da önceden telafi edilir: tekrar, eşlik paketi, düşük hızlı kopya ve serpiştirme.
• RTP sıra numarası, zaman damgası ve akış kimliği taşır: RTCP kaybı, jitter’ı ve ses ile görüntünün eşlemesini bildirir.
• SIP buluşturur, SDP anlaştırır, ICE yolu bulur: medya çoğu zaman sunucuya uğramadan eşler arasında akar.

Canlı görüşme her milisaniyeyi sayıyor, pil ise dert değil; telefon her akşam şarja giriyor. Şimdi tam tersini düşün: bir tarlaya bırakılmış, yıllarca kimsenin dokunmayacağı, iki kalem pille çalışan ve dakikada bir sıcaklık ölçen yüzlerce küçük cihaz. Hız da gecikme de önemsiz, ömür ise her şey. Böyle bir ağ nasıl kurulur?