Web Gerçek Zamanlı İletişim (WebRTC) çerçevesi, iki eşin web tarayıcıları arasında ses, video, metin, işbirliği, oyunlar vb. kullanarak doğrudan, etkileşimli ve zengin iletişimi destekler. Bu not, WebRTC çerçevesinin medya taşıma yönlerini açıklamaktadır. Gerçek Zamanlı Taşıma Protokolü'nün (RTP) WebRTC bağlamında nasıl kullanıldığını belirtir ve hangi RTP özelliklerinin, profillerinin ve uzantılarının desteklenmesi gerektiğine dair gereksinimleri sunar.

#1. Giriş

Gerçek Zamanlı Taşıma Protokolü (RTP) [RFC3550], ses ve video telekonferans verilerinin ve diğer gerçek zamanlı medya uygulamalarının iletimi için bir çerçeve sağlar. Önceki çalışmalar, çok sayıda profil, yük biçimi ve diğer uzantılarla birlikte RTP protokolünü tanımlamıştır. Uygun sinyalleşme ile birleştirildiğinde, bunlar birçok telekonferans sisteminin temelini oluşturur.

Web Gerçek Zamanlı İletişim (WebRTC) çerçevesi, iki eşin web tarayıcıları arasında ses, video, işbirliği, oyunlar vb. kullanarak doğrudan, etkileşimli ve gerçek zamanlı iletişimi desteklemek için protokol yapı taşlarını sağlar. Bu not, RTP çerçevesinin WebRTC bağlamında nasıl kullanılacağını açıklamaktadır. Tüm WebRTC uç noktaları tarafından gerçeklenmesi gereken temel bir RTP özellikleri kümesini ve geliştirilmiş işlevsellik için önerilen uzantıları önermektedir.

Bu not, WebRTC çerçevesi içinde kullanılmak üzere tasarlanan bir protokolü belirtir, ancak bu bağlamla sınırlı değildir. WebRTC çerçevesine genel bir bakış [RFC8825]'te verilmiştir.

Bu notun yapısı şu şekildedir. Bölüm 2, bu notun hazırlanmasına ve bu RTP özelliklerinin seçilmesine ilişkin gerekçemizi ana hatlarıyla sunar. Bölüm 3 terminolojiyi tanımlar. Temel RTP protokollerine ilişkin gereksinimler Bölüm 4'te, önerilen RTP uzantıları ise Bölüm 5'te açıklanmaktadır. Bölüm 6, ağ sorunlarına karşı dayanıklılığı artırabilecek mekanizmaları ana hatlarıyla sunarken, Bölüm 7 tıkanıklık denetimi ve hız uyarlama mekanizmalarını açıklar. Zorunlu RTP mekanizmalarına ilişkin tartışma, performans izleme ve ağ yönetimi araçlarının gözden geçirilmesiyle Bölüm 8'de sona erer. Bölüm 9, diğer RTP ve RTP Denetim Protokolü (RTCP) uzantılarının bu çerçeveye gelecekte dahil edilmesine yönelik bazı kılavuzlar verir. Bölüm 10, sinyalleşme kanalına getirilen gereksinimleri açıklar. Bölüm 11, RTP çerçevesinin özellikleri ile WebRTC uygulama programlama arabirimi (API) arasındaki ilişkiyi tartışır ve Bölüm 12 RTP gerçekleme hususlarını ele alır. Not, güvenlik hususları (Bölüm 13) ve IANA hususları (Bölüm 14) ile sona erer.

#2. Gerekçe

RTP çerçevesi; RTP veri aktarım protokolünü, RTP denetim protokolünü ve çok sayıda RTP yük biçimini, profilini ve uzantısını kapsar. Bu eklentiler yelpazesi, RTP'nin özgün protokol tasarımcıları tarafından öngörülmeyen çeşitli gereksinimleri karşılamasına ve birçok yeni medya kodlamasını desteklemesine olanak tanımıştır; ancak yeni gerçeklemeler tarafından hangi uzantıların destekleneceği sorusunu da gündeme getirmektedir. WebRTC çerçevesinin geliştirilmesi, mevcut RTP özellikleri ve uzantılarının gözden geçirilmesi ve tüm WebRTC uç noktaları için ortak bir temel RTP özellik kümesinin tanımlanması için bir fırsat sunar. Bu, son 20 yıllık RTP gelişimine dayanarak, geniş çapta yararlılık göstermiş uzantıların kullanımını zorunlu kılarken, mümkün olduğunda geniş kurulu RTP gerçekleme tabanı ile uyumluluğu korur.

Bu belgede ele alınmayan RTP ve RTCP uzantıları, yeni kullanım senaryoları için faydalı olmaları halinde WebRTC uç noktaları tarafından gerçeklenebilir. Ancak bunlar, [RFC7478]'de tanımlanan WebRTC kullanım senaryolarını ve gereksinimlerini karşılamak için gerekli değildir.

Bu notta tanımlanan temel RTP özellikleri ve uzantıları kümesi WebRTC çerçevesinin gereksinimlerine hedeflenmiş olsa da, RTP'nin konferansla ilgili diğer kullanımları için de geniş ölçüde faydalı olması beklenmektedir. Özellikle, bu RTP özellikleri ve uzantıları kümesinin diğer masaüstü veya mobil video konferans sistemleri ya da oda tabanlı yüksek kaliteli telebulunuş uygulamaları için uygun olması muhtemeldir.

#3. Terminoloji

Bu belgede "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, burada gösterildiği gibi yalnızca tamamı büyük harflerle göründüklerinde BCP 14 [RFC2119] [RFC8174]'te açıklandığı şekilde yorumlanacaktır. Bu anahtar sözcüklerin küçük harfli veya karma kullanımları bu notta özel bir anlam taşıyor olarak yorumlanmamalıdır.

Aşağıdaki ek terimleri tanımlıyoruz:

WebRTC MediaStream: W3C tarafından WebRTC API'sinde tanımlanan MediaStream kavramı [W3C.WD-mediacapture-streams]. Bir MediaStream, sıfır veya daha fazla MediaStreamTrack'ten oluşur.

MediaStreamTrack: W3C tarafından WebRTC API'sinde tanımlanan MediaStream kavramının bir parçası [W3C.WD-mediacapture-streams]. Bir MediaStreamTrack, mikrofon veya kamera gibi herhangi bir medya kaynağı türünden gelen tekil bir medya akışıdır; ancak bir ses karışımı veya bir video kompozisyonu gibi kavramsal kaynaklar da mümkündür.

Taşıma katmanı akışı: Kaynak IP adresi, kaynak portu, hedef IP adresi, hedef portu ve taşıma protokolünden oluşan belirli bir 5'li tarafından tanımlanan tek yönlü bir taşıma paketi akışı.

Çift yönlü taşıma katmanı akışı: Çift yönlü bir taşıma katmanı akışı, simetrik olan bir taşıma katmanı akışıdır. Yani, ters yöndeki taşıma katmanı akışı, ileri yol taşıma katmanı akışına kıyasla kaynak ve hedef adresler ile portların yer değiştirdiği bir 5'liye sahiptir ve taşıma protokolü aynıdır.

Bu belge, [RFC7656] ve [RFC8825]'teki terminolojiyi kullanır. Diğer terimler, RTP belirtimindeki [RFC3550] tanımlarına göre kullanılır. Özellikle, aşağıdaki sık kullanılan terimlere dikkat edilmelidir: RTP akışı, RTP oturumu ve uç nokta.

#4. WebRTC'de RTP Kullanımı: Temel Protokoller

Aşağıdaki bölümler, gerçeklenmesi gereken RTP ve RTCP'nin temel özelliklerini ve zorunlu RTP profillerini açıklar. Ayrıca, günümüz ağlarında etkin şekilde çalışmak için tüm WebRTC uç noktalarının gerçeklemek zorunda olduğu temel işlevleri sağlayan çekirdek uzantılar da açıklanmaktadır.

4.1. RTP ve RTCP

Gerçek Zamanlı Taşıma Protokolü (RTP) [RFC3550], WebRTC için medya taşıma protokolü olarak gerçeklenmesi GEREKLİDİR. RTP'nin kendisi iki bölümden oluşur: RTP veri aktarım protokolü ve RTP Denetim Protokolü (RTCP). RTCP, RTP'nin temel ve ayrılmaz bir parçasıdır ve tüm WebRTC uç noktalarında gerçeklenmeli ve kullanılmalıdır (MUST).

Aşağıdaki RTP ve RTCP özellikleri, sınırlı işlevselliğe sahip bazı RTP gerçeklemelerinde zaman zaman atlanmaktadır; ancak tüm WebRTC uç noktalarında GEREKLİDİR:

• Tek bir RTP oturumu içinde birden fazla eşzamanlama kaynağı (SSRC) değerinin eşzamanlı kullanımına destek; [RFC3550] ve [RFC8108]'e uygun olarak, aynı anda çok sayıda SSRC değeri gönderen RTP uç noktalarına destek dahil. [RFC8861]'de tanımlanan çoklu SSRC oturumları için RTCP iyileştirmeleri desteklenebilir (MAY); destekleniyorsa, kullanım MUTLAKA sinyalleştirilmelidir.
• Bir oturuma katılırken SSRC'nin rastgele seçilmesi; SSRC değerleri için çakışma algılama ve çözümleme (bkz. ayrıca Bölüm 4.8).
• RTP karıştırıcıları tarafından oluşturulan katkı sağlayan kaynak (CSRC) listelerini içeren RTP veri paketlerinin ve CSRC'lere ilişkin RTCP paketlerinin alınmasına destek.
• Alıcıların dudak senkronizasyonunu gerçekleyebilmesi için RTCP Gönderici Raporlarında doğru eşzamanlama bilgisinin gönderilmesi; hızlı RTP eşzamanlama uzantılarına destek için Bölüm 5.2.1'e bakınız.
• Birden fazla eşzamanlama bağlamına destek. Birden fazla eşzamanlı RTP paket akışı gönderen katılımcılar, tüm akışlar için tek bir RTCP CNAME kullanarak ve alıcıların akışları eşzamanlı olarak oynatmasına olanak tanıyarak, bunu tek bir eşzamanlama bağlamının parçası olarak yapmalıdır (SHOULD). Bu belirtimin gelecekteki olası sürümleriyle uyumluluk ya da bir ağ geçidi üzerinden WebRTC olmayan aygıtlarla birlikte çalışabilirlik için, alıcılar bir RTP oturumunda birden fazla RTCP CNAME kullanımıyla gösterilen birden fazla eşzamanlama bağlamını desteklemek ZORUNDADIR (MUST). Bu belirtim, bazı durumlarda RTP akışları gönderilirken tek bir CNAME kullanımını zorunlu kılar; bkz. Bölüm 4.9.
• RTCP Gönderici Raporu (SR), Alıcı Raporu (RR), Kaynak Tanımı (SDES) ve BYE paket türlerinin gönderilmesi ve alınmasına destek. Diğer RTCP paket türlerine destek, bu belirtimin diğer bölümleri tarafından zorunlu kılınmadıkça İSTEĞE BAĞLIDIR (OPTIONAL). RTP/SAVPF profili (Bölüm 4.2) ve diğer RTCP uzantıları (Bölüm 5) tarafından ek RTCP paket türlerinin kullanıldığına dikkat ediniz. Oturum Tanımlama Protokolü (SDP) paketleme müzakere uzantısını gerçekleyen WebRTC uç noktaları, medya akışlarını tanımlamak için SDP Gruplama Çerçevesi "mid" özniteliğini kullanacaktır. Bu tür uç noktaları, [RFC8843]'te açıklanan RTCP SDES medya tanımlama (MID) öğesini gerçeklemek ZORUNDADIR.
• Tek bir RTP oturumunda birden fazla uç noktaya destek ve RTCP iletim aralığının oturumdaki katılımcı sayısına göre ölçeklenmesine destek; RTCP raporlarının eşzamanlanmasını önlemek için rastgeleleştirilmiş RTCP iletim aralıklarına destek; RTCP zamanlayıcı yeniden değerlendirmesine ([RFC3550]'in Bölüm 6.3.6'sı) ve ters yeniden değerlendirmeye ([RFC3550]'in Bölüm 6.3.4'ü) destek.
• RTCP bant genişliğinin medya bant genişliğinin bir kesri olarak yapılandırılmasına ve RTCP bant genişliğinin göndericilere ayrılan kesrinin yapılandırılmasına destek — örneğin SDP "b=" satırının kullanımıyla [RFC4566] [RFC3556].
• [RFC3550]'in Bölüm 6.2'sinde açıklanan azaltılmış asgari RTCP raporlama aralığına destek. Azaltılmış asgari RTCP raporlama aralığı kullanıldığında, katılımcı zaman aşımı aralığı hesaplanırken sabit (azaltılmamış) asgari aralık MUTLAKA kullanılmalıdır (bkz. [RFC3550]'in Bölüm 6.2 ve 6.3.5'i). İlk bileşik RTCP paketinin gönderilmesinden önceki gecikme sıfıra ayarlanabilir (bkz. [RFC3550]'in [RFC8108] ile güncellenen Bölüm 6.2'si).
• Kesintili iletime destek. RTP, uç noktaların iletimi herhangi bir zamanda duraklatmasına ve yeniden başlatmasına olanak tanır. Yeniden başlatıldığında, RTP sıra numarası her zamanki gibi bir artar; RTP zaman damgası değerindeki artış ise duraklamanın süresine bağlıdır. Kesintili iletim en yaygın olarak bazı ses yük biçimleriyle kullanılır, ancak sese özgü değildir ve herhangi bir RTP yük biçimiyle kullanılabilir.
• Bilinmeyen RTCP paket türlerini ve RTP başlık uzantılarını yok sayma. Bu, sinyalleştirilmemiş RTP başlık uzantıları veya RTCP paket türlerinin alınmasına yol açabilecek gelecekteki uzantıların, ara kutu davranışlarının vb. sağlam bir şekilde ele alınmasını sağlamak içindir. Bilinen ve bilinmeyen RTCP paket türlerinin bir karışımını içeren bileşik bir RTCP paketi alındığında, bilinen paket türlerinin her zamanki gibi işlenmesi, yalnızca bilinmeyen paket türlerinin atılması gerekir.

Özellikle yalnızca İnternet Üzerinden Ses (VoIP) olan sistemlere hedeflenenler başta olmak üzere, önemli sayıda eski RTP gerçeklemesinin yukarıdaki özelliklerin tümünü desteklemediği ve bazı durumlarda RTCP'yi hiç desteklemediği bilinmektedir. Gerçekleyicilere, eski gerçeklemelerle birlikte çalışabilirken zarif bozulma gereksinimlerini dikkate almaları tavsiye edilir.

Diğer uygulama hususları Bölüm 12’de ele alınmaktadır.

4.2. RTP Profilinin Seçimi

Belirli bir uygulama alanı için RTP’nin eksiksiz belirtimi, bir RTP profilinin seçilmesini gerektirir. WebRTC kullanımı için, [RFC7007] ile genişletilmiş olan RTCP tabanlı geri bildirim için genişletilmiş güvenli RTP profili (RTP/SAVPF) [RFC5124] UYGULANMALIDIR. RTP/SAVPF profili; temel RTP/AVP profili [RFC3551], RTCP tabanlı geri bildirim için RTP profili (RTP/AVPF) [RFC4585] ve güvenli RTP profili (RTP/SAVP) [RFC3711] birleşimidir.

RTCP tabanlı geri bildirim uzantıları [RFC4585], geliştirilmiş RTCP zamanlayıcı modeli için gereklidir. Bu, RTCP paketlerinin bant genişliğine sıkı sıkıya bağlı kalmak yerine olaylara yanıt olarak daha esnek biçimde iletilmesine olanak tanır ve hem tıkanıklık sinyallerinin hem de ortam olaylarının raporlanabilmesi için hayati önemdedir. Bu uzantılar ayrıca RTCP bant genişliğinin tasarruflu kullanılmasını sağlar ve bir uç nokta, geri bildirim gerektiren çok sayıda olay olmadıkça genellikle tam RTCP bant genişliği tahsisini kullanmaz. Zamanlayıcı kuralları, Bölüm 5.1’de ele alınan RTP konferans uzantılarından yararlanmak için de gereklidir.

Not: RTP/AVPF profilinde tanımlanan geliştirilmiş RTCP zamanlayıcı modeli, RTCP bant genişliği değeri ve "trr-int" gibi parametre yapılandırmalarına ilişkin bazı kısıtlar sağlandığında, yalnızca RTP/AVP veya RTP/SAVP profilini uygulayan eski sistemlerle geriye dönük uyumludur. Bir ağ geçidi üzerinden RTP/(S)AVP uç noktalarıyla birlikte çalışabilirlik için en önemli etken, "trr-int" parametresinin 4 saniyeyi temsil eden bir değere ayarlanmasıdır; bkz. [RFC8108] Bölüm 7.1.3.

Güvenli RTP (SRTP) profil uzantıları [RFC3711], ortam şifrelemesi, bütünlük koruması, tekrar oynatma koruması ve sınırlı bir kaynak kimlik doğrulaması biçimi sağlamak için gereklidir. WebRTC uç noktaları temel RTP/AVP profili veya RTP/AVPF profili kullanarak paket GÖNDERMEMELİDİR; üretilen tüm RTP ve RTCP paketlerini korumak için tam RTP/SAVPF profilini kullanmak ZORUNDADIR. Başka bir deyişle, uygulamalar SRTP ve Güvenli RTCP (SRTCP) kullanmak ZORUNDADIR. RTP/SAVPF profili, [RFC8827]’de tanımlanan şifre takımları, DTLS-SRTP koruma profilleri, anahtarlama mekanizmaları ve diğer parametreler kullanılarak yapılandırılmak ZORUNDADIR.

4.3. RTP Yük Biçimlerinin Seçimi

WebRTC uç noktaları için uygulanması zorunlu ses kodekleri ve RTP yük biçimleri [RFC7874]’te tanımlanmıştır. WebRTC uç noktaları için uygulanması zorunlu video kodekleri ve RTP yük biçimleri [RFC7742]’de tanımlanmıştır. WebRTC uç noktaları, RTP yük biçimi ve ilişkili sinyallemesi tanımlanmış olan diğer herhangi bir kodeği ayrıca uygulayabilir.

WebRTC uç noktaları, bir RTP oturumundaki diğer katılımcıların, ne kadar yaygın olursa olsun, herhangi bir RTP yük biçimini anladığını varsayamaz. RTP yük türü numaraları ile belirli RTP yük biçimlerinin özel yapılandırmaları arasındaki eşlemenin, bu yük türleri/biçimleri kullanılmadan önce üzerinde anlaşılması ZORUNDADIR. SDP bağlamında bu, bir "m=" satırıyla ilişkili "a=rtpmap:" ve "a=fmtp:" öznitelikleri ile RTP yük biçimini yapılandırmak için gereken diğer SDP öznitelikleri kullanılarak yapılabilir.

Uç noktalar, her bir benzersiz RTP yük biçimi yapılandırması farklı bir RTP yük türü numarası kullandığı sürece, birden fazla RTP yük biçimi veya tek bir RTP yük biçiminin birden fazla yapılandırması için destek sinyali verebilir. Bölüm 4.8’de belirtildiği üzere, RTP yük türü numarası bazen bir RTP paket akışını bir sinyalleme bağlamıyla ilişkilendirmek için kullanılır. Bu ilişkilendirme, her bağlamda benzersiz RTP yük türü numaraları kullanılması koşuluyla mümkündür. Örneğin, bir RTP paket akışı, RTP paket akışının kullandığı RTP yük türü numaraları SDP’nin ortam bölümlerindeki "a=rtpmap:" satırlarında sinyallenmiş yük türleriyle karşılaştırılarak bir SDP "m=" satırıyla ilişkilendirilebilir. Bu, aşağıdaki hususlara yol açar:

• RTP paket akışları RTP yük türüne dayalı olarak sinyalleme bağlamlarıyla ilişkilendiriliyorsa, RTP yük türü numaralarının ataması sinyalleme bağlamları arasında benzersiz OLMALIDIR.
• Aynı RTP yük biçimi yapılandırması birden fazla bağlamda kullanılıyorsa, benzersizliği sağlamak için her bağlamda farklı bir RTP yük türü numarası atanmak ZORUNDADIR.
• RTP yük türü numarası, RTP paket akışlarını bir sinyalleme bağlamıyla ilişkilendirmek için kullanılmıyorsa, aynı RTP yük türü numarası birden fazla bağlamda birebir aynı RTP yük biçimi yapılandırmasını göstermek için kullanılabilir.

Tek bir RTP yük türü numarası, tek bir RTP oturumu içinde farklı RTP yük biçimlerine veya aynı RTP yük biçiminin farklı yapılandırmalarına atanmamalıdır (SDP BUNDLE grubundaki [RFC8843] "m=" satırlarının tek bir RTP oturumu oluşturduğunu unutmayın).

Birden fazla RTP yük biçimi için destek sinyali vermiş bir uç nokta, daha önce kod çözme yeteneğine ilişkin sınırlamalarını sinyallememişse, bu yük biçimlerinden herhangi biriyle gelen verileri her zaman kabul edebilmelidir. Bu gereklilik, aynı RTP oturumunda birden fazla ortam türü (ör. ses ve video) gönderiliyorsa kısıtlanır. Böyle bir durumda, bir kaynak (SSRC), yalnızca o kaynak tarafından gönderilmekte olan ortam türü için sinyallenmiş RTP yük biçimleri arasında geçiş yapmakla sınırlıdır; bkz. Bölüm 4.4. Kod değiştirerek hızlı oran uyarlamasını desteklemek için RTP, oturum kurulumu sırasında sinyallenmiş olan ve tek bir SSRC tarafından kullanılan RTP yük biçimleri arasındaki değişiklikler için önceden sinyalleme gerektirmez.

Farklı RTP saat hızlarını kullanan iki RTP yük türü arasında değişiklik yapılırken, bir RTP göndericisi [RFC7160] Bölüm 4.1’deki önerilere uymak ZORUNDADIR. RTP alıcıları, bir RTP oturumunda saat hızları arasında geçiş yapan kaynakları desteklemek için [RFC7160] Bölüm 4.3’teki önerilere uymak ZORUNDADIR. Alıcılar için bu öneriler, göndericilerin yalnızca tek bir saat hızı kullandığı durumla geriye dönük uyumludur.

4.4. RTP Oturumlarının Kullanımı

RTP kullanarak iletişim kuran bir dizi uç nokta arasındaki ilişki RTP oturumu olarak bilinir [RFC3550]. Bir uç nokta aynı anda birden fazla RTP oturumuna dahil olabilir. Bir multimedya oturumunda, her ortam türü tipik olarak ayrı bir RTP oturumunda taşınmıştır (ör. ses için bir RTP oturumu ve video için farklı bir taşıma katmanı akışı kullanan ayrı bir RTP oturumu). WebRTC uç noktalarının, eski sistemlerle uyumluluk için her RTP oturumunu farklı taşıma katmanı akışları kullanarak ayıran bu şekilde multimedya oturumlarını desteklemesi GEREKLİDİR (buna bazen oturum çoklama denir).

Ancak günümüz ağlarında, ağ adresi/port çeviricilerin (NAT/NAPT) ve güvenlik duvarlarının yaygın kullanımıyla, RTP uygulamaları tarafından kullanılan taşıma katmanı akışlarının sayısını azaltmak arzu edilir. Bu, tüm RTP paket akışlarının tek bir RTP oturumunda gönderilmesiyle yapılabilir; bu da tek bir taşıma katmanı akışı oluşturur. Bu, Bölüm 12.1.3’te tartışıldığı üzere bazı hizmet kalitesi mekanizmalarının kullanılmasını engeller. Bu nedenle uygulamaların, [RFC8860]’a uygun olarak, ortam türünden bağımsız tüm RTP paket akışlarının tek bir taşıma katmanı akışı kullanan tek bir RTP oturumunda taşınmasını da desteklemesi GEREKLİDİR (buna bazen SSRC çoklama denir). Tek bir RTP oturumunda birden fazla ortam türü kullanılacaksa, o RTP oturumundaki tüm katılımcılar bu kullanımı kabul etmek ZORUNDADIR. SDP bağlamında, tek bir RTP oturumu oluşturan RTP paket akışları demetini sinyallemek için [RFC8843]’te tanımlanan mekanizmalar kullanılabilir.

Farklı RTP oturumu yapılarının ve çoklama yöntemlerinin farklı senaryolara uygunluğu hakkında daha fazla tartışma [RFC8872]’de bulunabilir.

4.5. RTP ve RTCP Çoklama

Tarihsel olarak, RTP ve RTCP ayrı taşıma katmanı akışlarında çalıştırılmıştır (ör. her RTP oturumu için iki UDP portu; biri RTP, biri RTCP için). Ağ Adresi/Port Çevirimi (NAT/NAPT) kullanımının artmasıyla bu durum sorunlu hale gelmiştir; çünkü birden fazla NAT bağlamasının sürdürülmesi maliyetli olabilir. Ayrıca, RTP trafiğine izin vermek için birden fazla portun açılması gerektiğinden güvenlik duvarı yönetimini de karmaşıklaştırır. Bu maliyetleri ve oturum kurulum sürelerini azaltmak için, uygulamaların RTP veri paketleri ile RTCP denetim paketlerini tek bir taşıma katmanı akışı üzerinde çoklamayı desteklemesi GEREKLİDİR [RFC5761]. Bu tür RTP ve RTCP çoklaması kullanılmadan önce sinyalleme kanalında müzakere edilmek ZORUNDADIR. Sinyalleme için SDP kullanılıyorsa, bu müzakere [RFC5761]’de tanımlanan mekanizmayı kullanmak ZORUNDADIR. Uygulamalar ayrıca RTP ve RTCP’yi ayrı taşıma katmanı akışlarında göndermeyi de destekleyebilir, ancak bunun uygulanması İSTEĞE BAĞLIDIR. Bir uygulama RTP ve RTCP’nin ayrı taşıma katmanı akışlarında gönderilmesini desteklemiyorsa, bunu [RFC8858]’de tanımlanan mekanizmayı kullanarak belirtmek ZORUNDADIR.

RTP ve RTCP’nin tek bir taşıma katmanı akışı üzerinde çoklanmasının, etkin ortam trafiği olmasa bile o port üzerinden ara sıra trafik gönderilmesini sağladığını unutmayın. Bu, NAT bağlamalarını canlı tutmak için yararlı olabilir [RFC6263].

4.6. Azaltılmış Boyutlu RTCP

RTCP paketleri genellikle bileşik RTCP paketleri olarak gönderilir ve [RFC3550], bu bileşik paketlerin bir SR veya RR paketiyle başlamasını gerektirir. RTP/AVPF profili [RFC4585] altında sık RTCP geri bildirim iletileri kullanıldığında, bu istatistikler her pakette gerekli değildir ve ortalama RTCP paket boyutunu gereksiz yere artırır. Bu durum, RTCP paketlerinin RTCP bant genişliği payı içinde gönderilebileceği sıklığı sınırlayabilir.

Bu sorunu önlemek için [RFC5506], ortalama RTCP ileti boyutunun nasıl azaltılacağını ve daha sık geri bildirime nasıl olanak tanınacağını belirtir. Sık geri bildirim, gerçek zamanlı uygulamaların değişen ağ koşullarından hızla haberdar olmasını ve iletim ile kodlama davranışlarını uyarlayabilmesini sağlamak için gereklidir. Uygulamaların, bileşik olmayan RTCP geri bildirim paketlerini gönderme ve alma desteği sağlaması ZORUNLUDUR [RFC5506]. Bileşik olmayan RTCP paketlerinin kullanımı sinyalleme kanalı üzerinden müzakere edilmek ZORUNDADIR. Sinyalleme için SDP kullanılıyorsa, bu müzakere [RFC5506]’da tanımlanan öznitelikleri kullanmak ZORUNDADIR. Geriye dönük uyumluluk için, uzak uç nokta sinyalleme alışverişinde bileşik olmayan RTCP kullanımını kabul etmezse, uygulamaların bileşik RTCP geri bildirim paketlerinin kullanımını da desteklemesi GEREKLİDİR.

4.7. Simetrik RTP/RTCP

NAT ve güvenlik duvarı cihazlarından geçişi kolaylaştırmak için, uygulamaların simetrik RTP’yi [RFC4961] uygulaması ve kullanması GEREKLİDİR. Simetrik RTP kullanmanın temel nedeni, gönderme ve alma RTP paket akışlarının ve RTCP’nin gerçekten çift yönlü taşıma katmanı akışları olmasını sağlayarak NAT’ler ve güvenlik duvarlarıyla ilgili sorunlardan kaçınmaktır. Bu, NAT ve güvenlik duvarı açıklıklarını canlı tutar ve alma yönünün, hedef alıcının gerçekten istediği bir taşıma katmanı akışı olduğuna dair rızanın gösterilmesine yardımcı olur. Ayrıca, özellikle uç noktalardaki portlar olmak üzere kaynaklardan ve ağda da tasarruf sağlar; çünkü NAT eşlemeleri veya güvenlik duvarı durumu gereksiz yere şişirilmez. Ağda tutulan akış başına QoS durumu miktarı da azaltılır.

4.8. RTP Eşzamanlama Kaynağının (SSRC) Seçimi

Uygulamaların, sinyallenmiş RTP eşzamanlama kaynağı (SSRC) tanımlayıcılarını desteklemesi GEREKLİDİR. SDP kullanılıyorsa, bu [RFC5576] Bölüm 4.1 ve 5’te tanımlanan "a=ssrc:" SDP özniteliği ve [RFC5576] Bölüm 6.2’de tanımlanan "previous-ssrc" kaynak özniteliği kullanılarak yapılmak ZORUNDADIR; [RFC5576]’da tanımlanan diğer SSRC başına öznitelikler desteklenebilir.

Sinyallenmiş SSRC tanımlayıcıları için destek zorunlu olmakla birlikte, bunların bir RTP oturumunda kullanımı İSTEĞE BAĞLIDIR. Uygulamaların, önceden açıkça sinyallenmemiş SSRC’leri kullanan RTP ve RTCP paketlerini kabul etmeye hazır olması ZORUNDADIR. Uygulamaların rastgele SSRC atamasını desteklemesi ve [RFC3550]’a uygun olarak SSRC çakışma tespiti ve çözümlemesini desteklemesi ZORUNDADIR. Sinyallenmiş SSRC değerleri kullanılırken, çakışma tespiti [RFC5576] Bölüm 5’te açıklandığı şekilde yapılmak ZORUNDADIR.

Bir RTP paket akışını RTP dışı bir bağlamla ilişkilendirmek çoğu zaman arzu edilir. WebRTC API kullanıcıları için, SSRC’ler ile MediaStreamTracks arasındaki eşleme Bölüm 11’e göre sağlanır. Ağ geçitleri veya diğer kullanımlar için, bir RTP paket akışını SDP kullanılarak biçimlendirilmiş bir oturum açıklamasındaki bir "m=" satırıyla ilişkilendirmek mümkündür. SSRC’ler sinyallenmişse bu basittir (SDP’de "a=ssrc:" satırı ortam düzeyinde yer alır ve doğrudan bir "m=" satırıyla ilişkilendirmeye olanak tanır). SSRC’ler sinyallenmemişse, bir RTP paket akışında kullanılan RTP yük türü numaraları çoğu zaman bu paket akışını bir sinyalleme bağlamıyla ilişkilendirmek için yeterlidir. Örneğin, bu belgenin Bölüm 4.3’ünde açıklandığı şekilde RTP yük türü numaraları atanmışsa, bir RTP paket akışının kullandığı RTP yük türleri, SDP’de ortam düzeyinde bulunan ve dolayısıyla bir "m=" satırına eşlenen "a=rtpmap:" satırlarındaki değerlerle karşılaştırılabilir.

4.9. RTCP Kanonik Adının (CNAME) Oluşturulması

RTCP Kanonik Adı (CNAME), bir RTP uç noktası için kalıcı bir taşıma katmanı tanımlayıcısı sağlar. Bir RTP uç noktası için SSRC tanımlayıcısı bir çakışma tespit edildiğinde veya RTP uygulaması yeniden başlatıldığında değişebilse de, RTCP CNAME’inin bir RTCPeerConnection [W3C.WebRTC] süresi boyunca değişmeden kalması amaçlanır; böylece RTP uç noktaları, ilişkili RTP oturumları kümesi içinde benzersiz olarak tanımlanabilir ve RTP paket akışlarıyla ilişkilendirilebilir.

Her RTP uç noktasının en az bir RTCP CNAME’i OLMALIDIR ve bu RTCP CNAME’i RTCPeerConnection içinde benzersiz OLMALIDIR. RTCP CNAME’leri belirli bir eşzamanlama bağlamını tanımlar — yani tek bir RTCP CNAME’iyle ilişkilendirilmiş tüm SSRC’ler ortak bir referans saatini paylaşır. Bir uç noktanın, eşzamanlı olmayan birden fazla referans saatiyle ilişkili SSRC’leri varsa ve dolayısıyla farklı eşzamanlama bağlamları söz konusuysa, her eşzamanlama bağlamı için bir tane olmak üzere birden fazla RTCP CNAME’i kullanması gerekecektir.

Bölüm 11’deki tartışma dikkate alındığında, bir WebRTC uç noktası, tek bir RTCPeerConnection’a ait RTP oturumlarında birden fazla RTCP CNAME’i KULLANMAMALIDIR (yani bir RTCPeerConnection bir eşzamanlama bağlamı oluşturur). RTP ara kutuları, çok katılımcılı bir RTP oturumunun parçası olan birden fazla farklı uç noktadan gelen ortamı yeniden eşzamanlamak zorunda kalmamak için, birden fazla RTCP CNAME’iyle ilişkili RTP paket akışları üretebilir.

RTP belirtimi [RFC3550], benzersiz bir RTP CNAME seçimi için yönergeler içerir, ancak NAT cihazlarının varlığında bunlar yeterli değildir. Ayrıca, uzun vadeli kalıcı tanımlayıcılar gizlilik açısından sorunlu olabilir (Bölüm 13). Buna göre, bir WebRTC uç noktası, her RTCPeerConnection için [RFC7022]’yi izleyerek yeni, benzersiz, kısa süreli kalıcı bir RTCP CNAME’i oluşturmak ZORUNDADIR; tek bir istisna olarak, oluşturma sırasında açıkça talep edilirse, bir RTCPeerConnection, ortak aynı-köken bağlamları içinde mevcut bir RTCPeerConnection ile aynı CNAME’i kullanabilir.

Bir WebRTC uç noktası, RTP belirtiminde [RFC3550] belirtilen sözdizimi kısıtlamalarına uyan herhangi bir CNAME’in alınmasını desteklemek ZORUNDADIR ve herhangi bir CNAME’in yukarıda önerilen biçime göre seçileceğini varsayamaz.

4.10. Artık Saniyelerin Ele Alınması

RTP medya oynatımı ve senkronizasyonu üzerindeki etkilerini sınırlamak amacıyla artık saniyelerin ele alınmasına ilişkin [RFC7164] belgesinde verilen yönergeler izlenmelidir.

#5. WebRTC’de RTP Kullanımı: Uzantılar

WebRTC bağlamında, tam işlevselliğin elde edilmesi için gerekli olan ya da temel performansın iyileştirilmesi açısından son derece yararlı olan bir dizi RTP uzantısı bulunmaktadır. Bu uzantıların bir kümesi konferansla ilgilidir; diğerleri ise daha genel niteliktedir. Aşağıdaki alt bölümler, WebRTC kapsamında kullanımı zorunlu kılınan veya önerilen çeşitli RTP uzantılarını açıklamaktadır.

5.1. Konferans Uzantıları ve Topolojiler

RTP, doğası gereği grup iletişimini destekleyen bir protokoldür. Gruplar; her uç noktanın RTP paket akışlarını trafiği yeniden dağıtan bir RTP orta kutusuna göndermesiyle, uç noktalar arasında tekil yayın (unicast) RTP paket akışlarından oluşan bir ağ örgüsü (mesh) kullanılarak ya da RTP paket akışlarını dağıtmak için bir IP çoklu yayın (multicast) grubu kullanılarak uygulanabilir. Bu topolojiler, [RFC7667] belgesinde tartışıldığı üzere çeşitli şekillerde gerçekleştirilebilir.

IP çoklu yayın gruplarının kullanımı IPTV sistemlerinde yaygın olmakla birlikte, etkileşimli video konferans ortamlarında RTP orta kutularına dayalı topolojiler baskındır. Ortak bir RTP oturumu oluşturmak için tekil yayın taşıma katmanı akışlarından oluşan bir ağ örgüsüne dayalı topolojiler bugüne kadar yaygın bir dağıtım görmemiştir. Buna bağlı olarak, WebRTC uç noktalarının IP çoklu yayın gruplarına dayalı topolojileri veya tek bir RTP oturumu olarak yapılandırılmış noktadan-çok-noktaya bir ağ örgüsü gibi ağ örgüsü tabanlı topolojileri ( [RFC7667] terminolojisinde "Topo-Mesh") desteklemesi beklenmez. Ancak, WebRTC’de bağımsız RTCPeerConnections [W3C.WebRTC] kullanılarak birden fazla RTP oturumu ile kurulan noktadan-çok-noktaya bir ağ örgüsünün WebRTC’de kullanılması beklenir ve bunun desteklenmesi gerekir.

Bu notta tanımlandığı şekilde uygulanan WebRTC uç noktalarının, RTP uç noktalarının bir eş cihaza tekil yayın RTP paket akışları gönderip aldığı [RFC7667] belgesinde tanımlanan tüm topolojileri desteklemesi beklenir; yeter ki bu eş, RTP paket akışları üzerinde tıkanıklık denetiminin gerçekleştirilmesine katılabilsin. Eş cihaz başka bir RTP uç noktası olabileceği gibi, RTP paket akışlarını diğer RTP uç noktalarına yeniden dağıtan bir RTP orta kutusu da olabilir. Bu sınırlama, RTP orta kutusu tabanlı bazı topolojilerin WebRTC’de kullanıma uygun olmadığı anlamına gelir. Özellikle:

• Video-anahtarlamalı Çok Noktalı Kontrol Birimleri (MCU’lar) (Topo-Video-switch-MCU) KULLANILMAMALIDIR; çünkü RTCP’nin tıkanıklık denetimi ve hizmet kalitesi raporları için kullanımını sorunlu hale getirirler (bkz. [RFC7667] Bölüm 3.8).
• Aktarım Çevirici Röle (Topo-PtM-Trn-Translator) topolojisi KULLANILMAMALIDIR; çünkü güvenli kullanımı, henüz standartlaştırılmamış olan noktadan-çok-noktaya işleyebilen bir tıkanıklık denetimi algoritması veya RTP devre kesicisi gerektirir.

Aşağıdaki topoloji ise kullanılabilir; ancak dikkat edilmesi gereken bazı sorunları vardır:

• RTCP sonlandırmalı içerik-değiştirici MCU’lar (Topo-RTCP-terminating-MCU) KULLANILABİLİR. Bu RTP topolojisinde, RTP döngü algılama ve etkin göndericilerin tanımlanması WebRTC uygulamasının sorumluluğundadır; istemciler RTP katmanında birbirlerinden yalıtıldığından, RTP bu işlevlerde yardımcı olamaz (bkz. [RFC7667] Bölüm 3.9).

Bölüm 5.1.1 ile 5.1.6 arasında açıklanan RTP uzantıları, bir RTP orta kutusunun (örneğin bir konferans köprüsü) bir katılımcının RTP paket akışlarını alıp diğer katılımcılara dağıttığı merkezi konferans kullanımı için tasarlanmıştır. Bu uzantılar birlikte çalışabilirlik için gerekli değildir; bu uzantıları uygulamayan bir RTP uç noktası doğru şekilde çalışır ancak düşük performans sunabilir. Listelenen uzantıların desteklenmesi deneyim kalitesini büyük ölçüde iyileştirir; makul bir temel kalite sağlamak için bu uzantıların bazılarının WebRTC uç noktaları tarafından desteklenmesi zorunludur.

RTCP konferans uzantıları Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] ve Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104] belgelerinde tanımlanmıştır; bu uzantılar, bu profilin güvenli varyantı (RTP/SAVPF) [RFC5124] tarafından tamamen kullanılabilir.

5.1.1. Full Intra Request (FIR)

Full Intra Request iletisi, Codec Control Messages [RFC5104] belgesinin 3.5.1 ve 4.3.1 bölümlerinde tanımlanmıştır. Oturumdaki bir katılımcıdan yeni bir Intra görüntü talep etmek için mikserin bu isteği yapmasını sağlar. Bu, kaynaklar arasında geçiş yapılırken alıcıların uzun tahmin zincirlerine sahip video veya diğer öngörücü medya kodlamalarını çözebilmesini sağlamak için kullanılır. Medya gönderen WebRTC uç noktaları, aldıkları FIR geri bildirim iletilerini ANLAMAK ve TEPKİ VERMEK ZORUNDADIR; çünkü bu, merkezi mikser tabanlı konferans kullanıldığında kullanıcı deneyimini büyük ölçüde iyileştirir. FIR iletilerinin gönderilmesi için destek İSTEĞE BAĞLIDIR.

5.1.2. Picture Loss Indication (PLI)

Picture Loss Indication iletisi, RTP/AVPF profilinin [RFC4585] 6.3.1 bölümünde tanımlanmıştır. Bir alıcının, kodlayıcıya çözücü bağlamını kaybettiğini ve bunun bir şekilde onarılmasını istediğini bildirmesi için kullanılır. Bu, yukarıdaki Full Intra Request’ten anlamsal olarak farklıdır; çünkü isteğin karşılanması için birden fazla yol olabilir. Medya gönderen WebRTC uç noktaları, kayıp toleransı mekanizması olarak PLI geri bildirim iletilerini ANLAMAK ve TEPKİ VERMEK ZORUNDADIR. Alıcılar PLI iletileri GÖNDEREBİLİR.

5.1.3. Slice Loss Indication (SLI)

Slice Loss Indication iletisi, RTP/AVPF profilinin [RFC4585] 6.3.2 bölümünde tanımlanmıştır. Bir alıcının, bir veya daha fazla ardışık makro bloğun kaybını veya bozulmasını tespit ettiğini ve bunların bir şekilde onarılmasını istediğini kodlayıcıya bildirmesi için kullanılır. Makro blok kavramını destekleyen bir kodlayıcı kullanıldığında dilimler kaybolursa, alıcıların SLI geri bildirim iletileri üretmesi ÖNERİLİR. Bir SLI geri bildirim iletisi alan gönderici, kaybolan dilim(ler)i onarmaya ÇALIŞMALIDIR.

5.1.4. Reference Picture Selection Indication (RPSI)

Reference Picture Selection Indication (RPSI) iletileri, RTP/AVPF profilinin [RFC4585] 6.3.3 bölümünde tanımlanmıştır. Bazı video kodlama standartları, öngörücü kodlama için en son görüntü yerine daha eski referans görüntülerin kullanılmasına izin verir. Böyle bir kodlayıcı kullanılıyorsa ve kodlayıcı-kod çözücü senkronizasyonunun kaybolduğu öğrenilmişse, doğruluğu bilinen bir referans görüntü gelecekteki kodlama için temel olarak kullanılabilir. RPSI iletisi, bunun işaretlenmesini sağlar. Kodlayıcı-kod çözücü senkronizasyonunun kaybolduğunu tespit eden alıcılar, kullanılan kodlayıcı referans görüntü seçimini destekliyorsa bir RPSI geri bildirim iletisi ÜRETMELİDİR. Böyle bir RPSI iletisi alan bir RTP paket akışı göndericisi, mevcut bant genişliği kısıtları içinde ve kullanılan kodlayıcıyla mümkünse, referans görüntüyü değiştirmek üzere bu iletiye TEPKİ VERMELİDİR.

5.1.5. Temporal-Spatial Trade-Off Request (TSTR)

Zamansal-uzamsal ödünleşim isteği ve bildirimi, [RFC5104] belgesinin 3.5.2 ve 4.3.2 bölümlerinde tanımlanmıştır. Bu istek, video kodlayıcıdan zamansal ve uzamsal çözünürlük arasında yaptığı ödünleşimi değiştirmesini istemek için kullanılabilir — örneğin yüksek uzamsal görüntü kalitesini, ancak düşük kare hızını tercih etmesi gibi. TSTR istekleri ve bildirimleri için destek İSTEĞE BAĞLIDIR.

5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR)

Temporary Maximum Media Stream Bit Rate Request (TMMBR) geri bildirim iletisi, Codec Control Messages [RFC5104] belgesinin 3.5.4 ve 4.2.1 bölümlerinde tanımlanmıştır. Bu istek ve buna karşılık gelen Temporary Maximum Media Stream Bit Rate Notification (TMMBN) iletisi [RFC5104], bir medya alıcısı tarafından, bu alıcı için mevcut bant genişliğinde geçici bir sınırlama olduğunu gönderici tarafa bildirmek amacıyla kullanılır. Bunun çeşitli nedenleri olabilir; örneğin bir RTP mikseri, medyayı yeniden kodlamadan, mikser tarafından iletilen göndericinin medya hızını, diğer oturum katılımcılarına giden yollardaki darboğazlara uyacak şekilde sınırlamak için bu iletiyi kullanabilir. Medya gönderen WebRTC uç noktalarının TMMBR iletileri için destek uygulaması ZORUNLUDUR ve kendi SSRC’leri için alınan bir TMMBR iletisi tarafından belirlenen bant genişliği sınırlamalarına UYMAK ZORUNDADIR. TMMBR iletilerinin gönderilmesi İSTEĞE BAĞLIDIR.

5.2. Başlık Uzantıları

RTP belirtimi [RFC3550], bant içi veri içeren RTP başlık uzantılarının eklenebilmesini sağlar; ancak uzantıların biçimi ve anlambilimi zayıf şekilde tanımlanmıştır. Başlık uzantılarının kullanımı WebRTC’de İSTEĞE BAĞLIDIR; ancak kullanıldıkları takdirde, RTP başlık uzantıları için iyi tanımlanmış bir anlambilim sağladığından, [RFC8285] belgesinde tanımlanan genel mekanizmayı izleyerek BİÇİMLENDİRİLMELİ ve SİNYALLENMELİDİR.

[RFC8285]’te belirtildiği üzere, RTP belirtimindeki başlık uzantılarının "başlık uzantısının yok sayılabilecek şekilde tasarlanması" gereksinimi [RFC3550] geçerliliğini korur. Açık olmak gerekirse, başlık uzantıları yalnızca alıcı tarafından güvenle yok sayılabilecek ve birlikte çalışabilirliği etkilemeyecek veriler için KULLANILMALIDIR ve uzantının varlığının, paketin geri kalanının biçimini veya doğasını, akışın sinyallendiği şekilde (örneğin yük türü tarafından tanımlandığı gibi) uyumsuz olacak biçimde değiştirdiği durumlarda KULLANILMAMALIDIR. RTP başlık uzantılarına geçerli örnekler, olağan RTP bilgilerine ek olan ancak birlikte çalışabilirliği tehlikeye atmadan güvenle yok sayılabilen üst verileri içerebilir.

5.2.1. Hızlı Senkronizasyon

Birçok RTP oturumu, ses, video ve diğer içerikler arasında senkronizasyon gerektirir. Bu senkronizasyon, RTP belirtiminde [RFC3550] açıklandığı üzere RTCP SR paketlerinde bulunan bilgiler kullanılarak alıcılar tarafından gerçekleştirilir. Ancak bu temel mekanizma yavaş olabilir; bu nedenle, RTCP SR tabanlı senkronizasyona ek olarak [RFC6051]’de açıklanan hızlı RTP senkronizasyon uzantılarının uygulanması ÖNERİLİR.

Bu başlık uzantısı, [RFC8285]’te tanımlanan genel başlık uzantısı çerçevesini kullanır ve bu nedenle kullanılmadan önce müzakere edilmesi gerekir.

5.2.2. İstemciden Mikser’e Ses Seviyesi

İstemciden mikser’e ses seviyesi uzantısı [RFC6464], bir uç noktanın, başlığın eklendiği paketteki ses etkinliği düzeyi hakkında bir mikseri bilgilendirmek için kullandığı bir RTP başlık uzantısıdır. Bu, bir RTP orta kutusunun yükü çözmeden veya ayrıntılı inceleme yapmadan karıştırma ya da seçim kararları almasını sağlar ve bazı mikser türlerinde karmaşıklığı azaltır. Ayrıca alıcılarda kod çözme kaynaklarından tasarruf sağlayabilir; alıcılar, ses etkinliği düzeylerine dayanarak yalnızca en ilgili RTP paket akışlarını çözmeyi tercih edebilir.

İstemciden mikser’e ses seviyesi başlık uzantısı [RFC6464] UYGULANMAK ZORUNDADIR. Bu başlık uzantılarında yer alan bilgiler hassas kabul edilebileceğinden, uygulamaların başlık uzantısını [RFC6904]’e uygun şekilde şifreleyebilme yeteneğine sahip olması ZORUNLUDUR. Bu şifrelemenin kullanılması ÖNERİLİR; ancak şifrelemenin kullanımı API veya sinyalleme yoluyla açıkça devre dışı bırakılabilir.

Bu başlık uzantısı, [RFC8285]’te tanımlanan genel başlık uzantısı çerçevesini kullanır ve bu nedenle kullanılmadan önce müzakere edilmesi gerekir.

5.2.3. Mikser’den İstemci’ye Ses Seviyesi

Mikser’den istemci’ye ses seviyesi başlık uzantısı [RFC6465], bir RTP mikseri tarafından ortak bir kaynak akışına karıştırılan farklı kaynakların ses seviyelerini bir uç noktaya sağlar. Bu, bir kullanıcı arayüzünün her bir oturum katılımcısının göreli etkinlik düzeyini, yalnızca CSRC alanına dayanarak dahil edilip edilmediğini göstermek yerine, gösterebilmesini sağlar. Bu, kritik olmayan işlevlerin saf bir iyileştirmesidir ve bu nedenle uygulanması İSTEĞE BAĞLIDIR. Bu başlık uzantısı uygulanırsa, bu başlık uzantılarında yer alan bilgilerin hassas kabul edilebileceğinden, uygulamaların başlık uzantısını [RFC6904]’e uygun şekilde şifreleyebilme yeteneğine sahip olması ZORUNLUDUR. Ayrıca, şifreleme API veya sinyalleme yoluyla açıkça devre dışı bırakılmadıkça, bu şifrelemenin kullanılması ÖNERİLİR.

Bu başlık uzantısı, [RFC8285]’te tanımlanan genel başlık uzantısı çerçevesini kullanır ve bu nedenle kullanılmadan önce müzakere edilmesi gerekir.

5.2.4. Medya Akışı Tanımlama

SDP bundle müzakere uzantısını uygulayan WebRTC uç noktaları, medya akışlarını tanımlamak için SDP Grouping Framework "mid" özniteliğini kullanacaktır. Bu tür uç noktalar, [RFC8843]’te tanımlanan RTP MID başlık uzantısını UYGULAMAK ZORUNDADIR.

Bu başlık uzantısı, [RFC8285]’te tanımlanan genel başlık uzantısı çerçevesini kullanır ve bu nedenle kullanılmadan önce müzakere edilmesi gerekir.

5.2.5. Video Yöneliminin Koordinasyonu

Video gönderen veya alan WebRTC uç noktaları, [RFC7742]’nin 4. bölümünde açıklandığı üzere video yöneliminin koordinasyonu (CVO) RTP başlık uzantısını UYGULAMAK ZORUNDADIR.

Bu başlık uzantısı, [RFC8285]’te tanımlanan genel başlık uzantısı çerçevesini kullanır ve bu nedenle kullanılmadan önce müzakere edilmesi gerekir.

#6. WebRTC’de RTP Kullanımı: Taşıma Dayanıklılığının İyileştirilmesi

RTP paket akışlarını paket kaybına karşı dayanıklı hale getirebilen ve kaybın medya kalitesi üzerindeki etkisini azaltabilen araçlar bulunmaktadır. Ancak bunlar, genellikle dayanıklı olmayan bir akışa kıyasla bir miktar ek yük getirir. Bu ek yük dikkate alınmalı ve toplam bit hızı, ağ tıkanıklığına neden olmamak için hız denetimine tabi tutulmalıdır (bkz. Bölüm 7). Sonuç olarak, dayanıklılığın artırılması daha düşük bir temel kodlama kalitesi gerektirebilir; ancak bu kaliteyi daha az hatayla sunma potansiyeline sahiptir. Aşağıdaki alt bölümlerde açıklanan mekanizmalar, paket kaybına toleransı artırmak için kullanılabilir.

6.1. Negatif Onaylar ve RTP Yeniden İletimi

RTP/SAVPF profilinin desteklenmesinin bir sonucu olarak, uygulamalar RTP veri paketleri için negatif onaylar (NACK’ler) gönderebilir [RFC4585]. Bu geri bildirim, RTCP geri bildirim kanalının kapasite sınırlamalarına tabi olarak, belirli RTP paketlerinin kaybı hakkında göndericiyi bilgilendirmek için kullanılabilir. Bir gönderici, bilinen kayıp paketleri telafi etmek üzere medya kodlamasını uyarlayarak kullanıcı deneyimini iyileştirmek için bu bilgiyi kullanabilir.

RTP paket akışı göndericilerinin, [RFC4585] belgesinin 6.2.1 bölümünde tanımlanan genel NACK iletisini ANLAMASI ZORUNLUDUR; ancak [RFC4585]’in 4.2 bölümünü izleyerek bu geri bildirimin bir kısmını veya tamamını YOK SAYMAYI tercih edebilirler. Alıcılar, eksik RTP paketleri için NACK gönderebilir. NACK’lerin ne zaman gönderileceğine ilişkin yönergeler [RFC4585]’te verilmiştir. Bir alıcının kaybolan her RTP paketi için bir NACK göndermesi beklenmez; bunun yerine, NACK geri bildirimi göndermenin maliyetini ve kaybolan paketin önemini dikkate alarak, bir paket kaybı olayını göndericiye bildirmenin değerli olup olmadığına dair bilinçli bir karar vermesi gerekir.

RTP yeniden iletim yük biçimi [RFC4588], NACK geri bildirimi temelinde kayıp paketlerin yeniden iletilmesini sağlama olanağı sunar. Yeniden iletim, yeniden iletilen paketin faydalı olacak kadar zamanında ulaşmasını sağlamak için etkileşimli gerçek zamanlı uygulamalarda dikkatle kullanılmalıdır; ancak ağ RTT’sinin nispeten düşük olduğu ortamlarda etkili olabilir. (Bir RTP göndericisi, [RFC3550] belgesinin 6.4.1 Bölümünün sonunda açıklandığı üzere, RTCP SR ve RR paketlerindeki bilgileri kullanarak alıcılara olan RTT’yi tahmin edebilir.) Yeniden iletim kullanımı, ileri yöndeki RTP bant genişliğini de artırabilir ve özgün paket kaybı ağ tıkanıklığından kaynaklanıyorsa potansiyel olarak artmış paket kaybına neden olabilir. Bununla birlikte, kod çözücü durumunu onarmak için önemli bir kayıp paketin yeniden iletilmesinin, tam bir intra kare göndermekten daha düşük maliyetli olabileceği unutulmamalıdır. Bir NACK’e yanıt olarak RTP paketlerini körü körüne yeniden iletmek uygun değildir. RTP yeniden iletimi kullanılmadan önce, kayıp paketlerin önemi ve zamanında ulaşıp faydalı olma olasılığı dikkate alınmalıdır.

Alıcıların, SSRC çoklama kullanılarak gönderilen RTP yeniden iletim paketleri [RFC4588] için destek uygulaması ZORUNLUDUR ve ayrıca oturum çoklama kullanılarak gönderilen RTP yeniden iletim paketlerini destekleyebilirler. Göndericiler, RTP yeniden iletim yük biçimi için destek müzakere edilmişse ve gönderici NACK’te referans verilen paket(ler)in yeniden iletilmesini göndermenin yararlı olduğuna inanıyorsa, NACK’lere yanıt olarak RTP yeniden iletim paketleri gönderebilir. Göndericilerin NACK edilen her paketi yeniden iletmesi gerekmez.

6.2. İleri Hata Düzeltme (FEC)

İleri Hata Düzeltme (FEC) kullanımı, sürekli bir bant genişliği ek yükü karşılığında belirli bir düzeydeki paket kaybına karşı etkili bir koruma sağlayabilir. RTP ile kullanım için tanımlanmış çeşitli FEC şemaları vardır. Bu şemalardan bazıları belirli bir RTP yük biçimine özgüdür, diğerleri ise RTP paketleri arasında çalışır ve herhangi bir yük biçimiyle kullanılabilir. Yedekli kodlama veya FEC kullanımının oynatma gecikmesini artıracağını unutmayın; bu durum, FEC şemaları ve parametreleri seçilirken dikkate alınmalıdır.

WebRTC uç noktaları, [RFC8854] belgesinde verilen FEC kullanımına ilişkin önerilere UYMALIDIR. WebRTC uç noktaları diğer FEC türlerini destekleyebilir, ancak bunlar kullanılmadan önce mutlaka müzakere edilmelidir.

#7. WebRTC’nin RTP Kullanımı: Hız Denetimi ve Medya Uyarlaması

WebRTC, dünya genelinde potansiyel olarak büyük kullanıcı gruplarını birbirine bağlamak için, kablolu ve kablosuz bağlantılar dâhil olmak üzere çeşitli bağlantı teknolojilerinin kullanıldığı heterojen ağ ortamlarında kullanılacaktır. Sonuç olarak, kullanıcılar arasındaki ağ yolları tek yönlü gecikmeler, kullanılabilir bit hızları, yük seviyeleri ve trafik karışımları açısından büyük farklılıklar gösterebilir. Tekil uç noktalar, her katılımcıya bir veya daha fazla RTP paket akışı gönderebilir ve birden fazla katılımcı bulunabilir. Bu RTP paket akışlarının her biri farklı medya türleri içerebilir ve medya türü, bit hızı ve RTP paket akışı sayısı ile taşıma katmanı akışları oldukça asimetrik olabilir. RTP dışı trafik, RTP taşıma katmanı akışlarıyla ağ yollarını paylaşabilir. Ağ ortamı öngörülebilir veya kararlı olmadığından, WebRTC uç noktaları ürettikleri RTP trafiğinin mevcut ağ kapasitesindeki değişikliklere uyum sağlayabilmesini TEMİN ETMELİDİR.

WebRTC kullanıcıları için deneyim kalitesi, medyanın ağın sınırlamalarına etkili bir şekilde uyarlanmasına büyük ölçüde bağlıdır. Uç noktalar, çok kısa zaman dilimleri dışında, ağ yolunun destekleyebileceğinden önemli ölçüde daha fazla veri iletmeyecek şekilde tasarlanmalıdır; aksi hâlde yüksek düzeyde ağ paket kaybı veya gecikme sıçramaları meydana gelir ve bu da medya kalitesinin düşmesine neden olur. Ağ yolunun kapasitesini sınırlayan etken, bağlantı bant genişliği olabileceği gibi bağlantı üzerindeki diğer trafiklerle rekabet de olabilir (bu trafik WebRTC dışı trafik, diğer WebRTC akışlarından kaynaklanan trafik veya hatta aynı oturumdaki diğer WebRTC akışlarıyla rekabet olabilir).

Bu nedenle, etkili bir medya tıkanıklık denetimi algoritması WebRTC çerçevesinin temel bir parçasıdır. Ancak bu yazının hazırlandığı sırada, WebRTC akışları gibi etkileşimli medya uygulamaları için kullanılabilecek standart bir tıkanıklık denetimi algoritması bulunmamaktadır. RTCPeerConnection’lar için tıkanıklık denetimi algoritmalarına ilişkin bazı gereksinimler [RFC8836] belgesinde ele alınmaktadır. Bu gereksinimleri karşılayan standartlaştırılmış bir tıkanıklık denetimi algoritması gelecekte geliştirilirse, bu belgenin kullanımını zorunlu kılacak şekilde güncellenmesi gerekecektir.

7.1. Sınır Koşulları ve Devre Kesiciler

WebRTC uç noktaları, [RFC8083] belgesinde tanımlanan RTP devre kesici algoritmasını uygulamak ZORUNDADIR. RTP devre kesici, uygulamaların aşırı ağ tıkanıklığı durumlarını tanımasını ve bunlara tepki vermesini sağlamak üzere tasarlanmıştır. Ancak RTP devre kesici, tıkanıklık aşırı hâle gelene kadar tetiklenmeyebileceğinden, tıkanıklık denetiminin yerine geçecek bir çözüm olarak kabul edilemez ve uygulamalar ağ kapasitesindeki değişikliklere uyum sağlayabilmek için ayrıca tıkanıklık denetimi de uygulamak ZORUNDADIR. Standartlaştırılmış bir tıkanıklık denetimi algoritması mevcut olana kadar, tıkanıklık denetimi algoritması özel mülkiyetli olmak zorunda kalacaktır. Gelecekteki RTP tıkanıklık denetimi algoritmalarının, devre kesicinin izin verdiği sınırlar içinde çalışması beklenmektedir.

Oturum kurulum sinyallemesi, medyanın bit hızının uyacağı sınırları da zorunlu olarak belirleyecektir. Medya kodlayıcılarının seçimi, uygulamanın faydalı kalite sağlamak için kullanabileceği desteklenen bit hızlarına ilişkin üst ve alt sınırları ve mevcut paketleme seçeneklerini sağlar. Ayrıca, sinyalleme kanalı SDP "b=AS:" veya "b=CT:" satırları ve RTP/AVPF TMMBR iletileri (bu belgenin 5.1.6 Bölümüne bakınız) gibi mekanizmalar kullanarak maksimum medya bit hızı sınırlarını belirleyebilir. Eşten alınan SDP "b=AS:" veya "b=CT:" satırları gibi sinyallenmiş bant genişliği sınırlamalarına, RTP paket akışları gönderilirken UYULMALIDIR. Medya alan bir WebRTC uç noktası, bant genişliği sınırlamalarını sinyallemelidir. Bu sınırlamalar, örneğin uç bağlantıların kapasitesi gibi bilinen bant genişliği kısıtlamalarına dayanmalıdır.

7.2. Tıkanıklık Denetimi Birlikte Çalışabilirliği ve Eski Sistemler

WebRTC ile birlikte çalışmak isteyen tüm uç noktalar RTCP uygulamalı ve tanımlı RTCP raporlama mekanizmaları aracılığıyla tıkanıklık geri bildirimi sağlamalıdır.

RTP/AVP profili [RFC3551] kullanarak RTCP’yi destekleyen eski uygulamalarla birlikte çalışıldığında, tıkanıklık geri bildirimi birkaç saniyede bir RTCP RR paketleri içinde sağlanır. Bu tür uç noktalarla birlikte çalışmak zorunda olan uygulamalar, neden olabilecekleri tıkanıklığı sınırlamak için RTP devre kesici [RFC8083] kısıtları içinde kaldıklarından EMİN OLMALIDIR.

Bir eski uç nokta RTP/AVPF’yi destekliyorsa, bu durum "trr-int" parametresi gibi sık raporlama için önemli parametrelerin müzakere edilmesini ve TMMBR [RFC5104] gibi tıkanıklık denetimi amaçları için yararlı bazı geri bildirim biçimlerinin desteklenmesi olasılığını mümkün kılar. Bu tür uç noktalarla birlikte çalışmak zorunda olan uygulamalar, neden olabilecekleri tıkanıklığı sınırlamak için RTP devre kesici [RFC8083] kısıtları içinde kaldıklarından EMİN OLMALIDIR; ancak mevcut geri bildirim miktarına bağlı olarak daha iyi bir tıkanıklık tepkisi elde edebileceklerini görebilirler.

Özel mülkiyetli tıkanıklık denetimi algoritmalarıyla, farklı algoritmalar ve uygulamalar bir iletişim oturumunda etkileşime girdiğinde sorunlar ortaya çıkabilir. Farklı uygulamalar uyarlama türü konusunda farklı seçimler yapmışsa, örneğin biri gönderici tabanlı diğeri alıcı tabanlı ise, bir yönde çift denetim uygulanırken diğer yönde denetim uygulanmayan bir durum ortaya çıkabilir. Bu belge, özel mülkiyetli tıkanıklık denetimi algoritmaları için davranış zorunluluğu getiremez; ancak bu tür algoritmaları kullanan uygulamaların bu sorunun farkında olması ve her iki yönde akan medya için etkili tıkanıklık denetiminin müzakere edildiğinden emin olmaya çalışması gerekir. IETF’nin gelecekte WebRTC trafiği için hem gönderici tabanlı hem de alıcı tabanlı tıkanıklık denetimi algoritmalarını standartlaştırması durumunda, birlikte çalışabilirlik, denetim ve medya akışının her iki yönünün de tıkanıklık denetimine tabi olmasının sağlanmasına ilişkin konuların da dikkate alınması gerekecektir.

#8. WebRTC’nin RTP Kullanımı: Performans İzleme

4.1 Bölümünde açıklandığı üzere, uygulamaların gönderdikleri ve aldıkları RTP paket akışlarıyla ilişkili RTCP Gönderici Raporu (SR) ve Alıcı Raporu (RR) paketlerini üretmesi ZORUNLUDUR. Bu RTCP raporları, temel paket kaybı ve jitter istatistiklerini içerdiklerinden performans izleme amacıyla kullanılabilir.

RTCP Genişletilmiş Raporlar (XR) çerçevesi tarafından çok sayıda ek performans metriği desteklenmektedir; bkz. [RFC3611] ve [RFC6792]. Bu yazının hazırlandığı sırada, WebRTC’de kullanım için hangi genişletilmiş metriklerin uygun olduğu net değildir; bu nedenle uygulamaların RTCP XR paketleri üretmesi yönünde bir gereklilik yoktur. Bununla birlikte, ayrıntılı performans izleme verilerini kullanabilen uygulamalar, uygun olduğunda RTCP XR paketleri üretebilir. RTCP XR paketlerinin kullanımı sinyallenmelidir; uygulamalar beklenmeyen veya anlaşılamayan RTCP XR paketlerini YOK SAYMALIDIR.

#9. WebRTC’nin RTP Kullanımı: Gelecekteki Genişletmeler

Bu belgede belirtilen RTP protokollerinin ve RTP genişletmelerinin temel kümesinin, WebRTC’nin gelecekteki gereksinimleri için yetersiz kalması mümkündür. Bu durumda, bu belgeye yapılacak gelecekteki güncellemelerin, "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736], "How to Write an RTP Payload Format" [RFC8088] ve "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] belgelerine uygun olarak yapılması gerekir. Ayrıca, RTP ve ilgili protokollerin genişletilmesine yönelik olarak geliştirilmiş olabilecek gelecekteki tüm kılavuzlar da dikkate alınmalıdır.

Gelecekteki genişletmelerin yazarlarının, genişletmeleri önerirken RTP’nin kullanıldığı çok çeşitli ortamları göz önünde bulundurmaları teşvik edilmektedir; çünkü bazı senaryolarda uygulanabilir olan genişletmeler diğerlerinde sorunlu olabilir. Mümkün olan durumlarda, WebRTC çerçevesi, RTP kullanan diğer uygulamalara geçitlerin kolayca uygulanabilmesini sağlamak için, belirli WebRTC kullanım senaryolarına dar şekilde hedeflenmiş mekanizmalar yerine genel fayda sağlayan RTP genişletmelerini benimseyecektir.

#10. Sinyalleme Hususları

RTP, harici bir sinyalleme kanalının var olduğu ve RTP oturumlarını ve özelliklerini yapılandırmak için kullanılabileceği varsayımıyla tasarlanmıştır. Bir RTP oturumunun temel yapılandırması aşağıdaki parametrelerden oluşur:

• RTP profili: Oturumda kullanılacak RTP profilinin adı. RTP/AVP [RFC3551] ve RTP/AVPF [RFC4585] profilleri temel bir düzeyde birlikte çalışabilir; güvenli türevleri olan RTP/SAVP [RFC3711] ve RTP/SAVPF [RFC5124] de kendi aralarında birlikte çalışabilir. Profillerin güvenli türevleri, SRTP paketlerinde kimlik doğrulama için ek başlık alanlarının bulunması ve yükün kriptografik dönüşüme tabi tutulması nedeniyle, güvenli olmayan türevlerle doğrudan birlikte çalışamaz. WebRTC, RTP/SAVPF profilinin kullanılmasını gerektirir ve bu MUTLAKA sinyallenmelidir. Birlikte çalışma işlevleri, eski bir kullanım durumu için bunu RTP/SAVP profiline dönüştürebilir; bu, WebRTC uç noktasına RTP/SAVPF’nin kullanıldığını bildirerek ve "trr-int" değerini 4 saniye olarak yapılandırarak yapılabilir.

Taşıma bilgileri: Her RTP oturumu için RTP ve RTCP’ye ait kaynak ve hedef IP adresleri ile portlar sinyallenmelidir. WebRTC’de bu taşıma adresleri, adayları sinyalleyen ve seçilmiş aday adres çiftlerine ulaşan Interactive Connectivity Establishment (ICE) [RFC8445] tarafından sağlanacaktır. RTP ve RTCP çoklama [RFC5761] kullanılacaksa, yani RTP ve RTCP akışları için tek bir port — başka bir deyişle tek bir taşıma katmanı akışı — kullanılacaksa, bu durum MUTLAKA sinyallenmelidir (bkz. Bölüm 4.5).

RTP yük türleri, medya biçimleri ve biçim parametreleri: Medya türü adları (dolayısıyla kullanılacak RTP yük biçimleri) ile RTP yük türü numaraları arasındaki eşleme sinyallenmelidir. Her medya türü ayrıca kodlayıcıyı ve RTP yük biçimini yapılandırmak için sinyallenmesi GEREKEN bir dizi medya türü parametresine sahip olabilir (SDP’deki "a=fmtp:" satırı). Bu belgenin 4.3 Bölümü, yük türlerinin benzersizliği için gereksinimleri ele almaktadır.

RTP genişletmeleri: Gerekli tüm parametreler dâhil olmak üzere, ek RTP başlık genişletmelerinin ve RTCP paket türlerinin kullanımı sinyallenmelidir. Bu sinyalleme, özellikle gönderim sırasında, bir WebRTC uç noktasının davranışının öngörülebilir ve tutarlı olmasını sağlar. Sağlamlık ve bir ağ geçidi aracılığıyla bir WebRTC oturumuna bağlanabilecek WebRTC dışı sistemlerle uyumluluk için, uygulamaların bilinmeyen RTCP paketlerini ve RTP başlık genişletmelerini yok sayması ZORUNLUDUR (ayrıca bkz. Bölüm 4.1).

RTCP bant genişliği: Uç noktalar arasında RTCP bant genişliği değerlerinin değişimini desteklemek gerekli olacaktır. Bu, SDP kullanılıyorsa "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556] belgesinde açıklandığı şekilde veya anlamsal olarak eşdeğer bir yöntemle YAPILACAKTIR. Bu aynı zamanda uç noktaların RTCP bant genişliği konusunda ortak bir görüşe sahip olmasını sağlar. Farklı uç noktalar arasında RTCP bant genişliği konusunda ortak bir görüşe sahip olunması, RTCP paket zamanlaması ve zaman aşımı aralıklarındaki farklılıkların birlikte çalışabilirlik sorunlarına yol açmasını önlemek açısından önemlidir.

Bu parametreler genellikle bir teklif/yanıt alışverişi içinde iletilen SDP iletilerinde ifade edilir. RTP, SDP’ye veya teklif/yanıt modeline bağımlı değildir; ancak gerekli tüm parametrelerin üzerinde anlaşılmasını ve RTP uygulamasına sağlanmasını gerektirir. WebRTC’de bu parametrelerin nasıl yapılandırılacağı, sinyalleme modeline ve API’ye bağlı olacaktır; ancak bunların ya API’de ayarlanması ya da eşler arasında açıkça sinyallenmesi gerekecektir.

#11. WebRTC API Hususları

WebRTC API’si [W3C.WebRTC] ve Media Capture and Streams API’si [W3C.WD-mediacapture-streams], sıfır veya daha fazla MediaStreamTrack’ten oluşan bir MediaStream kavramını tanımlar ve kullanır. Bir MediaStreamTrack, mikrofon veya kamera gibi herhangi bir medya kaynağından gelen bireysel bir medya akışıdır; ancak bir ses miksajı veya video kompozisyonu gibi kavramsal kaynaklar da mümkündür. Bir MediaStream içindeki MediaStreamTrack’lerin oynatma sırasında senkronize edilmesi gerekebilir.

Bir MediaStreamTrack’in, bir RTCPeerConnection bağlamında RTP’deki karşılığı, RTCPeerConnection’ın bir parçası olan bir RTP oturumu içinde gönderilen ve bir SSRC ile tanımlanan bir kaynak paket akışından oluşur. MediaStreamTrack, aynı RTP oturumu içinde ek paket akışlarına ve dolayısıyla ek SSRC’lere de yol açabilir. Bunlar, böyle bir medya kodlayıcısı kullanılıyorsa, MediaStreamTrack ile ilişkili kaynak akışın ölçeklenebilir kodlamasından türetilmiş bağımlı paket akışları olabilir. Ayrıca yedeklilik paket akışları da olabilir; bunlar, kaynak paket akışına İleri Hata Düzeltme (Bölüm 6.2) veya RTP yeniden iletimi (Bölüm 6.1) uygulandığında elde edilir.

Aynı medya kaynağının birden fazla MediaStreamTrack’i besleyebileceğini belirtmek önemlidir. MediaStreamTrack’e farklı kısıt kümeleri veya başka parametreler uygulanabildiğinden, bir RTCPeerConnection’a eklenen her MediaStreamTrack örneği, kendi ilişkili paket akışları kümesine sahip bağımsız bir kaynak paket akışı ve dolayısıyla farklı SSRC(ler) ile sonuçlanmalıdır. Kaynak akışının ve kodlama yapılandırmasının, aynı medya kaynağını paylaşan farklı MediaStreamTrack’ler arasında özdeş olup olmayacağı, uygulanan kısıtlar ve parametrelere bağlıdır. Kodlama parametreleri ve kısıtlar aynıysa, bir uygulama farklı RTP paket akışlarını oluşturmak için yalnızca tek bir kodlanmış akışı kullanmayı tercih edebilir. Ancak bu tür iyileştirmelerin, MediaStreamTrack’lerden biri için kısıtların herhangi bir anda değişebileceğini ve bunun kodlama yapılandırmalarının artık özdeş olmayabileceği anlamına geldiğini dikkate alması gerekir; bu durumda iki farklı kodlayıcı örneğine ihtiyaç duyulacaktır.

Aynı MediaStreamTrack birden fazla MediaStream’e de dahil edilebilir; dolayısıyla birden fazla MediaStream kümesi dolaylı olarak aynı senkronizasyon tabanını kullanma gereksinimi duyabilir. Bunun tüm durumlarda çalışmasını sağlamak ve bir uç noktanın devam eden herhangi bir paket akışının iletimi sırasında senkronizasyon tabanını ve CNAME’i değiştirerek medyayı bozmak zorunda kalmamasını temin etmek için, aynı uç noktadan kaynaklanan tüm MediaStreamTrack’ler ve bunlarla ilişkili SSRC’ler, tek bir RTCPeerConnection içinde aynı CNAME kullanılarak gönderilmelidir. Bu durum, Bölüm 4.9’da tek bir CNAME kullanımını motive etmektedir.

Aynı uç noktadan kaynaklanan tüm SSRC’ler için aynı CNAME’in kullanılması gereksinimi, birden fazla uç noktadan gelen trafiği ileten bir middlebox’ın yalnızca tek bir CNAME kullanmasını zorunlu kılmaz.

Bölüm 4.9’da belirtildiği üzere, normalde farklı RTCPeerConnection örnekleri için farklı CNAME’lerin kullanılması gerekir. Aynı CNAME ile iki iletişim oturumuna sahip olmak, bir kullanıcının veya cihazın farklı hizmetler arasında izlenmesini mümkün kılabilir (ayrıntılar için [RFC8826] Bölüm 4.4.1’e bakınız). Bir web uygulaması, (aynı origin bağlamı içinde) farklı RTCPeerConnection’larda kullanılan CNAME’lerin aynı olmasını talep edebilir; bu, uç noktanın RTP paket akışlarının farklı RTCPeerConnection’lar arasında senkronize edilmesine olanak tanır.

Not: Bu durum bir izleme sorununa yol açmaz; çünkü eşleşen CNAME’lerin oluşturulması, tek bir origin içindeki mevcut izlemeye bağlıdır.

Yukarıda belirtilenler, şu anda bir RTCPeerConnection üzerinde bir MediaStreamTrack alan ve bunu herhangi bir RTCPeerConnection üzerinde giden bir akış olarak ekleyen bir WebRTC uç noktasını, akışı yeniden senkronize etmeye zorlar. Gönderen tarafın kullandığı CNAME’e geçmesi gerektiğinden, bu, senkronizasyon için zaman tabanı olarak yerel bir sistem saatini kullanması gerektiği anlamına gelir. Dolayısıyla, gelen akışın zaman tabanı ile gönderen sistemin zaman tabanı arasındaki göreli ilişkinin tanımlanması gerekir. Bu ilişkinin saat kayması açısından izlenmesi ve büyük olasılıkla senkronizasyonun ayarlanması da gerekir. Gönderen varlık, gönderdiği akışlar için tıkanıklık kontrolünden de sorumludur. Paket kaybı durumlarında, gelen verinin kaybının da ele alınması gerekir. Bu durum, giden kaynak paket akışında sorunlara veya kesintilere yol açma olasılığı en düşük yöntemin, onarım da dahil olmak üzere tam kod çözme ve ardından medyanın giden paket akışına yeniden kodlanması modeli olduğu gözlemini doğurur. Bu yöntemin iyileştirilmesi açıkça mümkündür ve uygulamaya özgüdür.

Bir WebRTC uç noktası, her biri farklı CNAME’ler kullanan birden fazla MediaStreamTrack’in alınmasını DESTEKLEMELİDİR. Ancak, farklı CNAME’lerle alınan MediaStreamTrack’ler için tanımlanmış bir senkronizasyon yoktur.

Not: Birden fazla CNAME alımının desteklenmesinin motivasyonu, uç noktaların akışları aktardığı/iletildiği durumlarda daha verimli akış işleme sağlayabilecek gelecekteki değişikliklerle ileriye dönük uyumluluğa izin vermektir. Ayrıca, uç noktaların belirli türde çoklu akış middlebox’ları veya WebRTC olmayan uç noktalarla birlikte çalışabilmesini de sağlar.

"JavaScript Session Establishment Protocol (JSEP)" [RFC8829], WebRTC MediaStream’leri, MediaStreamTrack’leri ve SSRC arasındaki bağlamanın, "WebRTC MediaStream Identification in the Session Description Protocol" [RFC8830] içinde belirtildiği şekilde yapıldığını tanımlar. MediaStream Identification (MSID) belgesinin [RFC8830] Bölüm 4.1’i, bilinmeyen SSRC’lere sahip kaynak paket akışlarının MediaStreamTrack’lere ve MediaStream’lere nasıl eşleneceğini de tanımlar. Bu durum, bazı eski sistemlerle birlikte çalışabilirlik senaryolarını ele almak için önemlidir. Genellikle, gelen herhangi bir paketin RTP yük türü, paket akışının bir kaynak akışı mı yoksa bir yedeklilik ya da bağımlı paket akışı mı olduğunu ortaya koyar. Doğru kaynak paket akışıyla ilişkilendirme, paket akışı için kullanılan yük biçimine bağlıdır.

Son olarak, bu teknik özellik, WebRTC API’sine CSRC listesinin (Bölüm 4.1) ve (desteklendiğinde) mikserden istemciye ses seviyelerinin (Bölüm 5.2.3) belirlenmesi için bir yöntem gerçekleştirme gereksinimi getirir; bunun temel gereksinimleri Bölüm 12.2.1’de daha ayrıntılı olarak ele alınmaktadır.

#12. RTP Uygulama Hususları

Aşağıdaki tartışma, bu belgede tanımlanan RTP özelliklerinin uygulanmasına ilişkin bazı yönlendirmeler sunar. Odak noktası bir WebRTC uç noktası uygulama perspektifidir ve middlebox davranışlarına dair bazı atıflar yapılmakla birlikte, bu belgenin ana odağı bu değildir.

12.1. RTP Oturumlarının Yapılandırılması ve Kullanımı

Bir WebRTC uç noktası, eşzamanlı olarak bir veya daha fazla RTP oturumunun katılımcısı olacaktır. Her RTP oturumu birden fazla medya kaynağını taşıyabilir ve birden fazla uç noktadan gelen medya verilerini içerebilir. Aşağıda, WebRTC uç noktalarının RTP oturumlarını yapılandırıp kullanabileceği bazı yollar ana hatlarıyla açıklanmaktadır.

12.1.1. Bir RTP Oturumu İçinde Birden Fazla Medya Kaynağının Kullanımı

RTP bir grup iletişim protokolüdür ve her RTP oturumu potansiyel olarak birden fazla RTP paket akışı içerebilir. Bunun istenebilir olmasının birkaç nedeni vardır:

• Birden fazla medya türü:

  WebRTC dışında, her medya kaynağı türü için ayrı bir RTP oturumu kullanmak yaygındır (örneğin, ses kaynakları için bir RTP oturumu ve video kaynakları için başka bir RTP oturumu; her biri farklı taşıma katmanı akışları üzerinden gönderilir). Ancak kullanılan UDP portlarının sayısını azaltmak için, WebRTC’de varsayılan olarak Bölüm 4.4’te açıklandığı üzere tüm medya türleri tek bir RTP oturumunda gönderilir ve gerekli UDP portu sayısını daha da azaltmak için RTP ve RTCP çoklama (Bölüm 4.5) kullanılır. Bu RTP oturumu böylece yalnızca tek bir çift yönlü taşıma katmanı akışı kullanır, ancak her biri farklı bir medya türü içeren birden fazla RTP paket akışı barındırır. Yaygın bir örnek, kamerası ve mikrofonu olan bir uç noktanın, tek bir RTP oturumuna biri video diğeri ses olmak üzere iki RTP paket akışı göndermesidir.

• Birden fazla yakalama aygıtı:

  Bir WebRTC uç noktasında birden fazla kamera, mikrofon veya başka medya yakalama aygıtı bulunabilir; bu nedenle aynı medya türünde birden fazla RTP paket akışı üretmek isteyebilir. Alternatif olarak, tek bir yakalama aygıtından gelen medyayı aynı anda birden fazla farklı biçimde veya kalite ayarında göndermek isteyebilir. Her iki durum da, tek bir uç noktanın aynı anda tek bir RTP oturumu içine aynı medya türünde birden fazla RTP paket akışı göndermesiyle sonuçlanabilir.

• İlişkili onarım verileri:

  Bir uç nokta, başka bir akışla bir şekilde ilişkili olan bir RTP paket akışı gönderebilir. Örneğin, başka bir akışla ilgili FEC veya yeniden iletim verilerini içeren bir RTP paket akışı gönderebilir. Bazı RTP yük biçimleri bu tür ilişkili onarım verilerini kaynak paket akışının bir parçası olarak gönderirken, diğerleri bunu ayrı bir paket akışı olarak gönderir.

• Katmanlı veya çoklu tanımlı kodlama:

  Tek bir RTP oturumu içinde bir uç nokta, katmanlı bir medya kodlayıcısı — örneğin H.264 Scalable Video Coding (SVC) — veya her biri farklı bir RTP SSRC’ye sahip birden fazla RTP paket akışı üreten çoklu tanımlı bir kodlayıcı kullanabilir.

• RTP mikserleri, çevirmenler ve diğer middlebox’lar:

  WebRTC bağlamında bir RTP oturumu, bir uç nokta ile başka bir eş cihaz arasındaki, bu cihazların ortak bir SSRC alanını paylaştığı noktadan noktaya bir ilişkidir. Eş cihaz başka bir WebRTC uç noktası olabileceği gibi, bir RTP mikseri, çevirmeni veya başka bir medya işleme middlebox’ı da olabilir. İkinci durumda, middlebox birden fazla katılımcıdan gelen karıştırılmış veya iletilmiş RTP akışlarını gönderebilir ve WebRTC uç noktasının bunları oynatması gerekir. Dolayısıyla, bir WebRTC uç noktası yalnızca tek bir RTP oturumunun üyesi olsa bile, eş cihaz bu RTP oturumunu başka uç noktaları içerecek şekilde genişletiyor olabilir. WebRTC bir grup iletişim ortamıdır ve uç noktaların, tek bir RTP oturumunda dahi olsa, aynı anda birden fazla RTP paket akışını alabilmesi, kod çözebilmesi ve oynatabilmesi gerekir.

12.1.2. Birden Fazla RTP Oturumunun Kullanımı

Tek bir RTP oturumu içinde birden fazla RTP paket akışı gönderip almanın yanı sıra, bir WebRTC uç noktası birden fazla RTP oturumuna da katılabilir. Bir WebRTC uç noktasının bunu tercih etmesinin birkaç nedeni vardır:

• Eski cihazlarla birlikte çalışabilirlik sağlamak için:

  WebRTC dışındaki dünyada yaygın uygulama, farklı medya türlerini ayrı RTP oturumlarında göndermektir — örneğin, ses için bir RTP oturumu ve video için, ayrı bir taşıma katmanı akışı üzerinde, başka bir RTP oturumu kullanmak. Tüm WebRTC uç noktalarının, bu tür eski cihazlarla birlikte çalışabilmek için farklı medya türlerini farklı RTP oturumlarında gönderme seçeneğini desteklemesi gerekir. Bu konu Bölüm 4.4’te daha ayrıntılı olarak ele alınmaktadır.

• Geliştirilmiş hizmet kalitesi sağlamak için:

  Bazı ağ tabanlı hizmet kalitesi mekanizmaları, taşıma katmanı akışları düzeyinde çalışır. Belirli RTP paket akışları için farklılaştırılmış hizmet kalitesi sağlamak amacıyla bu mekanizmaların kullanılması isteniyorsa, bu RTP paket akışlarının farklı bir taşıma katmanı akışı kullanan ayrı bir RTP oturumunda ve uygun hizmet kalitesi işaretlemesiyle gönderilmesi gerekir. Bu konu Bölüm 12.1.3’te daha ayrıntılı olarak ele alınmaktadır.

• Farklı amaçlara sahip medyayı ayırmak için:

Bir uç nokta, farklı amaçlara sahip RTP paket akışlarını farklı RTP oturumlarında göndermek isteyebilir; böylece eş cihazın bunları ayırt etmesi kolaylaşır. Örneğin, bazı merkezi çok katılımcılı konferans sistemleri aktif konuşmacıyı yüksek çözünürlükte gösterirken, diğer katılımcıların düşük çözünürlüklü "küçük resimlerini" gösterir. Bu tür sistemler, RTP middlebox’ının çalışmasını basitleştirmek için uç noktaları, videolarının yüksek ve düşük çözünürlüklü simulcast sürümlerini ayrı RTP oturumları kullanarak gönderecek şekilde yapılandırabilir. WebRTC bağlamında bu, şu anda aynı medya kaynağına sahip birden fazla WebRTC MediaStreamTrack’in tek bir (veya birden fazla) RTCPeerConnection içinde kurulmasıyla mümkündür. Her MediaStreamTrack belirli bir medya kalitesi ve dolayısıyla medya bit hızı sunacak şekilde yapılandırılır ve bu RTCPeerConnection bağlamında özel olarak üzerinde uzlaşılan kodlayıcı parametreleriyle bağımsız olarak kodlanmış bir sürüm üretir. RTP middlebox’ı, düşük ve yüksek çözünürlüklü akışlara karşılık gelen paketleri SSRC, RTP yük türü veya RTP yükü, RTP başlık uzantısı ya da RTCP paketleri içinde yer alan başka bilgiler üzerinden ayırt edebilir. Bununla birlikte, RTP paket akışlarının ayrı taşıma katmanı akışları üzerinde, ayrı RTP oturumları olarak gelmesi durumunda ayırt etmek daha kolay olabilir.

• Birden fazla eşle doğrudan bağlantı kurmak için:

  Çok katılımcılı bir konferansın bir RTP middlebox kullanması gerekmez. Bunun yerine, Şekil 1’de gösterildiği gibi, her katılımcının diğer her katılımcıya ayrı bir RTP oturumu üzerinden (yani bağımsız bir RTCPeerConnection nesnesi kullanarak) RTP trafiği gönderdiği çoklu-unicast bir ağ oluşturulabilir. Bu topolojinin avantajı, medya verilerine erişip bunları işlemek üzere güvenilen bir RTP middlebox düğümüne ihtiyaç duymamasıdır. Dezavantajı ise, göndericinin kendisi dışındaki her katılımcı için RTP paket akışlarının bir kopyasını gerektirdiğinden, her göndericide kullanılan bant genişliğini artırmasıdır.

  `` +---+ +---+ | A |<--->| B | +---+ +---+ ^ ^ \ / \ / v v +---+ | C | +---+ ``

  Şekil 1: Birden Fazla RTP Oturumu Kullanarak Çoklu-Unicast

  Çoklu-unicast topolojisi, birden fazla eşler arası taşıma katmanı bağlantısını kapsayan tek bir RTP oturumu olarak ya da her eş çifti arasında birer tane olacak şekilde birden fazla ikili RTP oturumu olarak da uygulanabilir. RTP oturumları ile RTCPeerConnection nesneleri arasındaki ilişkinin tutarlı bir eşlemesini korumak için, bunun birkaç ayrı RTP oturumu olarak uygulanması ÖNERİLİR. Bunun tek dezavantajı, A uç noktasının B ile C arasındaki iletimlerin kalitesi hakkında bilgi edinmemesidir; çünkü B ile C arasındaki RTP oturumu için RTCP raporlarını görmeyecektir. Oysa üç katılımcının da tek bir RTP oturumunun parçası olması durumunda bunu görebilirdi. Mbone araçlarıyla (1990’ların sonlarından kalma, RTP tabanlı deneysel çok noktaya yayın konferans araçları) edinilen deneyimler, üçüncü taraflara ait RTCP alım kalite raporlarının, kullanıcıların asimetrik ağ sorunlarını anlamalarına yardımcı olacak şekilde sunulabildiğini göstermiştir ve ayrı RTP oturumları kullanma yaklaşımı bunu engeller. Ancak ayrı RTP oturumları kullanmanın bir avantajı, farklı eşler arasında farklı medya bit hızları ve RTP oturumu yapılandırmalarının kullanılmasına olanak tanımasıdır; böylece A’dan C’ye giden iletimde sınırlamalar varsa, B’nin de C ile aynı kalite düşüşlerine katlanmak zorunda kalmaması sağlanır. Bu avantajların, hata ayıklama gücündeki sınırlamalardan daha ağır bastığı düşünülmektedir.

• Birden fazla eşle dolaylı bağlantı kurmak için:

  Çok katılımcılı konferanslarda yaygın bir senaryo, bir RTP mikseri, çevirmeni veya başka bir tür RTP middlebox kullanarak birden fazla eşe dolaylı bağlantılar oluşturmaktır. Şekil 2, dört kişilik merkezi bir konferansta kullanılabilecek basit bir topolojiyi ana hatlarıyla göstermektedir. Middlebox, belirli bakış açılarından RTP paket akışlarının iletimini iyileştirmek için hareket eder; ya alınan RTP paket akışının yalnızca bir kısmını herhangi bir alıcıya gönderir ya da katkıda bulunan akışlar kümesinden birleşik bir RTP paket akışı sağlar.

  `` +---+ +-------------+ +---+ | A |<---->| |<---->| B | +---+ | RTP mixer, | +---+ | translator, | | or other | +---+ | middlebox | +---+ | C |<---->| |<---->| D | +---+ +-------------+ +---+ ``

  Şekil 2: Yalnızca Unicast Yolları Olan RTP Mikseri

Middlebox için çeşitli gerçekleştirme yöntemleri vardır. Standart bir RTP mikseri veya çevirici olarak gerçekleştirilirse, tek bir RTP oturumu middlebox boyunca uzanır ve tek bir çok taraflı oturumda tüm uç noktaları kapsar. Diğer middlebox türleri, her bir uç nokta ile middlebox arasında ayrı RTP oturumları kullanabilir. Ortak bir özellik, bu RTP middlebox’larının bir WebRTC uç noktasının sağladığı medya kodlamasını denetlemek için bir dizi araç kullanabilmesidir. Buna, kodlama zincirinin kırılmasının istenmesi ve kodlayıcının sözde bir Intra kare üretmesini sağlamak gibi işlevler dahildir. Bir diğer ortak özellik, karıştırılmış çıktıyla daha iyi eşleşmesi için bir akışın bit hızının sınırlandırılmasıdır. Diğer yönler arasında en uygun kare hızının, görüntü çözünürlüğünün ve kare hızı ile uzamsal kalite arasındaki dengenin denetlenmesi yer alır. Middlebox, uygulamaya uygun medya iyileştirmeleri sağlarken tıkanıklık denetimini doğru şekilde gerçekleştirmekten, kaynakları tanımlamaktan ve eşzamanlamayı yönetmekten sorumludur. Middlebox ayrıca güvenlik açısından da güvenilir bir düğüm olmak zorundadır; çünkü bir uç noktadan alınan RTP başlığını veya medyanın kendisini (ya da her ikisini) diğer uç nokta(lar)a göndermeden önce değiştirir; bu nedenle, RTP paket akışını göndermeden önce çözebilmesi ve ardından yeniden şifreleyebilmesi gerekir.

Mikserlerin, kendi üzerlerinden geçen RTP paket akışlarına ilişkin RTCP raporlarını iletmemesi beklenir. Bunun nedeni, farklı uç noktalara sağlanan RTP paket akışları arasındaki farktır. Özgün medya kaynağı, mikserin farklı alıcılara gönderilmeden önce yaptığı değişikliklere ilişkin bilgiye sahip değildir. Bu senaryo aynı zamanda bir uç noktanın geri bildirimlerinin veya isteklerinin mikser’e gitmesiyle sonuçlanır. Mikser bunları kendi başına gerçekleştiremediğinde, alıcının isteğini karşılamak için özgün medya kaynağına başvurmak zorunda kalır. Bu durum herhangi bir RTP ve RTCP trafiğinde mutlaka açıkça görünmeyebilir; ancak etkileşimler ve bunların tamamlanma süresi bu tür bağımlılıkları gösterecektir.

Çok taraflı senaryolarda kaynak kimlik doğrulaması sağlamak zorludur. Mikser tabanlı topolojilerde, uç nokta kaynak kimlik doğrulaması, birincisi medyanın kriptografik doğrulama yoluyla mikserden geldiğinin doğrulanmasına ve ikincisi mikserin herhangi bir kaynağı uç noktaya doğru şekilde tanımladığına duyulan güvene dayanır. Bir uç noktanın birden fazla uç noktayı doğrudan görebildiği RTP oturumlarında, tüm uç noktalar birbirlerinin anahtar anahtarları hakkında bilgi sahibi olur ve böylece oturumdaki başka bir uç noktadan geliyormuş gibi paket enjekte edebilir. Aktarma yapan herhangi bir düğüm, daha önce başka uç noktalardan gelmiş SSRC alanlarına sahip paketlerin iletilmesini engelleyerek kriptografik olmayan bir azaltma uygulayabilir. Kaynağın kriptografik doğrulanması için SRTP, SRTP için Zamanlı Verimli Akış Kayıp Toleranslı Kimlik Doğrulama (Timed Efficient Stream Loss-Tolerant Authentication - TESLA) [RFC4383] gibi ek güvenlik mekanizmaları gerektirir; bunlar temel WebRTC standartlarının bir parçası değildir.

• Birden fazla eş arasında medyayı iletmek için:

  Bazen bir RTP paket akışı alan bir uç noktanın, bu RTP paket akışını üçüncü bir tarafa iletebilmesi istenir. Bunu desteklemenin bazı açık güvenlik ve gizlilik sonuçları vardır; ancak potansiyel kullanım alanları da mevcuttur. Bu, W3C API’sinde, alınan ve çözümlenen medyanın yeniden kodlanarak yeni bir akış olarak iletilen bir medya kaynağı olarak kullanılmasıyla desteklenir.

  RTP katmanında medya iletimi, arka arkaya bağlı bir RTP alıcısı ve RTP göndericisi gibi davranır. Alıcı taraf RTP oturumunu sonlandırır ve medyayı çözerken, gönderici taraf medyayı yeniden kodlar ve tamamen ayrı bir RTP oturumu kullanarak iletir. Özgün gönderici, medyanın yalnızca tek bir alıcısını görür ve iletimin gerçekleştiğini RTP katmanı bilgilerine dayanarak anlayamaz; çünkü iletilen medyanın gönderilmesinde kullanılan RTP oturumu, iletimi yapan düğümün medyayı aldığı RTP oturumuna bağlı değildir.

  İletimi gerçekleştiren uç nokta, ileriye doğru iletim için uygun bir RTP paket akışı üretmekten sorumludur. İletilen medyanın gönderilmesi için kullanılan giden RTP oturumu, medyanın alındığı RTP oturumundan tamamen ayrıdır. Bu, giden RTP oturumu için uygun bir bit hızı üretmek amacıyla tıkanıklık denetimi kapsamında medya dönüştürmeyi gerektirir; bu da medya kalitesini düşürür ve iletimi yapan uç noktanın dönüştürme için kaynak harcamasını zorunlu kılar. Medya dönüştürme, iki farklı bacak arasında bir ayrım sağlar, neredeyse tüm bağımlılıkları ortadan kaldırır ve iletimi yapan uç noktanın medya dönüştürme işlemini iyileştirmesine olanak tanır. Bunun bedeli, iletimi yapan düğümde büyük ölçüde artan hesaplama karmaşıklığıdır. İletilen akışın alıcıları, iletim yapan aygıtı akışın göndericisi olarak görür ve RTP katmanından, tamamen yeni bir RTP paket akışı yerine iletilmiş bir akış aldıklarını anlayamaz.

12.1.3. RTP Akışlarının Farklılaştırılmış İşlenmesi

RTP paket akışlarının farklılaştırılmış şekilde işlenmesine yönelik kullanım durumları vardır. Bu tür bir farklılaştırma, sistemde birkaç farklı noktada gerçekleşebilir. İlk olarak, medyayı gönderen uç nokta içindeki önceliklendirme gelir; bu, hangi RTP paket akışlarının gönderileceğini ve tıkanıklık denetimi tarafından belirlenen mevcut toplam kapasite içinden bit hızının nasıl paylaştırılacağını denetler.

WebRTC API’sinin [W3C.WebRTC], uygulamanın farklı MediaStreamTrack’ler için göreli öncelikleri belirtmesine izin vermesi beklenmektedir. Bu öncelikler daha sonra, özellikle tıkanıklık denetimi amacıyla mevcut bant genişliğinin RTP paket akışları arasında nasıl bölüneceğini belirlerken, yerel RTP işlemesini etkilemek için kullanılabilir. Göreli öncelikteki herhangi bir değişiklik, RTP yeniden iletimi ve FEC için yedek akışlar gibi ana RTP paket akışlarıyla ilişkili RTP paket akışları için de dikkate alınmalıdır. Bu tür yedek RTP paket akışlarının önemi, kullanılan medya türüne ve kodlayıcının paket kaybına karşı ne kadar dayanıklı olduğuna bağlıdır. Ancak varsayılan bir politika olarak, yedek bir RTP paket akışı için kaynak RTP paket akışıyla aynı öncelik kullanılabilir.

İkinci olarak, ağ, RTP paket akışları da dahil olmak üzere taşıma katmanı akışlarını ve alt akışlarını önceliklendirebilir. Tipik olarak, farklılaştırılmış işleme iki adım içerir: ilki, bir IP paketinin farklı şekilde ele alınması gereken bir sınıfa ait olup olmadığının belirlenmesi; ikincisi ise paketleri önceliklendirmek için kullanılan gerçek mekanizmadır. IP paketlerini sınıflandırmak için üç yaygın yöntem şunlardır:

• DiffServ: Uç nokta, paketin belirli bir sınıfa ait olduğunu ağa bildirmek için paketi bir DiffServ kod noktasıyla işaretler.
• Akış tabanlı: Belirli bir işleme tabi tutulması gereken paketler, IP ve port adreslerinin bir birleşimi kullanılarak tanımlanır.
• Derin paket incelemesi: Bir ağ sınıflandırıcısı (DPI), paketi inceler ve paketin önceliklendirilmesi gereken belirli bir uygulamayı ve türü temsil edip etmediğini belirlemeye çalışır.

Akış tabanlı farklılaştırma, bir taşıma katmanı akışı içindeki tüm paketlere aynı işlemi uygular; yani göreli önceliklendirme mümkün değildir. Ayrıca, kaynaklar sınırlıysa, bir WebRTC oturumunda kullanılan tüm RTP paket akışları için en iyi çaba (best effort) yaklaşımına kıyasla farklılaştırılmış işleme sağlamak mümkün olmayabilir. Akış tabanlı farklılaştırmanın kullanımı, WebRTC sistemi ile ağ(lar) arasında eşgüdüm gerektirir. WebRTC uç noktasının, RTP paket akışlarının farklı UDP akışlarına ayrılmasının akış tabanlı farklılaştırmanın daha ayrıntılı kullanılmasını sağlayabileceği durumlarda, bu yöntemin kullanılabileceğini bilmesi gerekir. Kullanılan akışlar, bunların 5-tuple bilgileri ve önceliklendirme, ağ tarafından akışların doğru şekilde tanımlanarak önceliklendirme yapılabilmesi için ağa iletilmelidir. Bunun için belirli bir protokol desteği tanımlanmamıştır.

DiffServ, uç noktanın veya bir sınıflandırıcının paketleri uygun bir Farklılaştırılmış Hizmetler Kod Noktası (DSCP) ile işaretleyebilmesini ve paketlerin bu işaretlemeye göre işlenmesini varsayar. Trafiği işaretleyecek olan uç nokta ise, WebRTC bağlamında iki gereksinim ortaya çıkar:

1. WebRTC uç noktasının hangi DSCP’lerin kullanılacağını ve bunları hangi RTP paket akışları kümesi üzerinde kullanabileceğini bilmesi gerekir.
2. Bilginin, paket iletimi sırasında işletim sistemine aktarılması gerekir.

Bu sürecin ayrıntıları bu belgenin kapsamı dışındadır ve "WebRTC QoS için Farklılaştırılmış Hizmetler Kod Noktası (DSCP) Paket İşaretlemeleri" [RFC8837] belgesinde daha ayrıntılı olarak ele alınmaktadır.

SRTP medya şifrelemesine rağmen, derin paket inceleyiciler RTP akışlarını sınıflandırma konusunda hâlâ oldukça yeteneklidir. Bunun nedeni, SRTP’nin RTP başlığının ilk 12 baytını şifrelememiş bırakmasıdır. Bu, SSRC kullanılarak RTP akışlarının kolayca tanımlanmasını sağlar ve sınıflandırıcıya, örneğin akışın medya türünü belirlemek için ilişkilendirilebilecek yararlı bilgiler sunar. Paket boyutları, alım zamanları, paketler arası aralıklar, RTP zaman damgası artışları ve sıra numaraları kullanılarak oldukça güvenilir sınıflandırmalar elde edilir.

Paket tabanlı işaretleme şemaları için, RTP yükünün göreli önceliğine bağlı olarak tek tek RTP paketlerini farklı şekilde işaretlemek mümkün olabilir. Örneğin, I, P ve B karelerine sahip video kodlayıcıları, yalnızca B kareleri taşıyan yükleri daha düşük önceliklendirebilir; çünkü bunların kaybı daha az zararlıdır. Ancak QoS mekanizmasına ve uygulanan işaretlemelere bağlı olarak, bu durum yalnızca farklı paket düşürme olasılıklarına değil, aynı zamanda paketlerin yeniden sıralanmasına da yol açabilir; daha fazla tartışma için [RFC8837] ve [RFC7657] belgelerine bakınız. Varsayılan bir politika olarak, bir RTP paket akışıyla ilişkili tüm RTP paketlerine aynı öncelik sağlanmalıdır; paket başına önceliklendirme bu belgenin kapsamı dışındadır, ancak gelecekte başka yerlerde tanımlanabilir.

Belirli bir RTP paket akışıyla ilişkili RTCP paketlerinin nasıl işaretlenmesi gerektiğini de dikkate almak önemlidir. Gönderici Raporları (SR) içeren RTCP bileşik paketleri, RTCP tabanlı gidiş-dönüş süresi (RTT) ölçümlerinin RTP paket akışının deneyimlediği taşıma katmanı akış önceliğiyle aynı öncelik kullanılarak yapılabilmesi için, RTP paket akışının kendisiyle aynı öncelikle işaretlenmelidir. Bir RR paketi içeren RTCP bileşik paketleri, raporlanan RTP paket akışlarının çoğunluğu tarafından kullanılan öncelikle gönderilmelidir. Zaman açısından kritik geri bildirim paketleri içeren RTCP paketleri ise, bu tür geri bildirimlerin zamanında ve yüksek olasılıkla iletilmesini iyileştirmek için daha yüksek öncelik kullanabilir.

12.2. Medya Kaynağı, RTP Akışları ve Katılımcı Tanımlama

12.2.1. Medya Kaynağı Tanımlama

Her RTP paket akışı, benzersiz bir eşzamanlama kaynağı (SSRC) tanımlayıcısı ile tanımlanır. SSRC tanımlayıcısı, bir RTP paket akışını oluşturan her RTP paketinde taşınır ve ilgili RTCP raporlarında da bu akışı tanımlamak için kullanılır. SSRC, Bölüm 4.8’de tartışıldığı şekilde seçilir. Bir WebRTC uç noktasında tek bir taşıma katmanı akışı üzerinde alınan RTP ve RTCP paketlerinin çoklama çözümlemesindeki ilk aşama, RTP paket akışlarının SSRC değerlerine göre ayrılmasıdır; bu işlem tamamlandıktan sonra, ek çoklama çözümleme adımları medyanın nasıl ve nerede işleneceğini belirleyebilir.

RTP, bir mikserin veya diğer RTP katmanı middlebox’larının, birden fazla medya kaynağından gelen kodlanmış akışları birleştirerek yeni bir medya kaynağından (mikser) gelen yeni bir kodlanmış akış oluşturmasına olanak tanır. Bu yeni RTP paket akışındaki RTP paketleri, hangi özgün SSRC’lerin birleşik kaynak akışına katkıda bulunduğunu gösteren bir katkıda bulunan kaynak (CSRC) listesi içerebilir. Bölüm 4.1’de açıklandığı gibi, uygulamaların CSRC listesi içeren RTP veri paketlerinin ve CSRC listesinde bulunan kaynaklarla ilişkili RTCP paketlerinin alımını desteklemesi gerekir. CSRC listesi, gerçekleştirilen karıştırma işlemine bağlı olarak paket bazında değişebilir. Belirli bir RTP paketine hangi medya kaynaklarının katkıda bulunduğunun bilinmesi, kullanıcı arayüzünün oturumda hangi katılımcıların etkin olduğunu göstermesi açısından önemli olabilir. Paketlerde yer alan CSRC listesindeki değişikliklerin, uygulamanın oturum katılımındaki değişiklikleri izleyebilmesi için bir API aracılığıyla WebRTC uygulamasına sunulması gerekir. SSRC/CSRC ad alanının WebRTC uygulamalarına açılmasını önlemek için, CSRC değerlerinin bu API üzerinden geçerken WebRTC MediaStream kimliklerine eşlenmesi tercih edilir.

Oturumda mikserden istemciye ses seviyesi uzantısı [RFC6465] kullanılıyorsa (Bölüm 5.2.3’e bakınız), CSRC listesindeki bilgiler, katkıda bulunan her bir kaynak için ses seviyesi bilgileriyle genişletilir. Bu bilgilerin, CSRC değerleri WebRTC MediaStream kimliklerine eşlendikten sonra bir API aracılığıyla WebRTC uygulamasına sunulması ve böylece kullanıcı arayüzünde gösterilebilmesi tercih edilir.

12.2.2. SSRC Çakışması Algılama

RTP standardı, RTP uygulamalarının SSRC çakışmalarını algılama ve ele alma desteğine sahip olmasını gerektirir — yani iki farklı uç noktanın aynı SSRC değerini kullanması durumunda çatışmayı çözebilmelidir (bkz. [RFC3550] Bölüm 8.2). Bu gereksinim WebRTC uç noktaları için de geçerlidir. SSRC çakışmalarının meydana gelebileceği birkaç senaryo vardır:

• Noktadan noktaya bir oturumda, her SSRC iki uç noktadan biriyle ilişkilendirildiğinde ve ana medyayı taşıyan SSRC tanımlayıcısı sinyalleşme kanalında duyurulduğunda, kullanılan SSRC’ler hakkındaki bilgiler nedeniyle bir çakışmanın meydana gelme olasılığı daha düşüktür. SDP kullanılıyorsa, bu bilgiler kaynak-özgü SDP öznitelikleri [RFC5576] ile sağlanır. Bununla birlikte, her iki uç nokta da yeni bir SSRC tanımlayıcısını, bunu eşe sinyallemeden ve sinyalleşme mesajı için onay almadan önce kullanmaya başlarsa, çakışmalar yine de meydana gelebilir. "Oturum Tanımlama Protokolü (SDP) İçinde Kaynak-Özgü Medya Öznitelikleri" [RFC5576], uç noktanın SSRC çakışmasını nasıl çözdüğünü sinyallemek için bir mekanizma içerir.
• Sinyallenmemiş SSRC değerleri de bir RTP oturumunda görünebilir. Bu, göründüğünden daha olasıdır; çünkü bazı RTP işlevleri, işlevselliklerini sağlamak için ek SSRC’ler kullanır. Örneğin, yeniden iletim verileri, kaynak RTP paket akışının SSRC’sinden ayrı, kendi SSRC’sini gerektiren ayrı bir RTP paket akışı kullanılarak iletilebilir [RFC4588]. Bu durumlarda, bir uç nokta, hem RTP hem de RTCPeerConnection düzeyinde doğru şekilde çalışmak için sinyalleşme kanalı üzerinden duyurulmasına kesinlikle gerek olmayan yeni bir SSRC üretebilir.
• Çok taraflı bir konferanstaki birden fazla uç nokta, yeni kaynaklar oluşturabilir ve bunları RTP middlebox’una doğru sinyalleyebilir. SSRC/CSRC’lerin RTP middlebox’undan farklı uç noktalar arasında iletildiği durumlarda çakışmalar meydana gelebilir.
• Bir RTP middlebox, bir uç noktanın RTCPeerConnection’ını aynı uç noktaya ait başka bir RTCPeerConnection’a bağlayabilir; böylece uç noktanın kendi trafiğini alacağı bir döngü oluşur. Bu durum açıkça bir hata olarak değerlendirilse de, meydana geldiğinde uç noktanın bu durumu tanıyabilmesi ve ele alabilmesi önemlidir. Ortam karıştırıcıları ve benzer bileşenlerin dahil olduğu durumlarda bu vaka daha da sorunlu hale gelir; çünkü alınan akış farklı bir akış olsa bile yine de bu istemcinin girdisini içermektedir.

Bu SSRC/CSRC çakışmaları, aynı RTP oturumu bir RTP middlebox tarafından birden fazla RTCPeerConnection üzerine genişletildiğinde yalnızca RTP düzeyinde ele alınabilir. Birden fazla RTCPeerConnection’ın birbirine bağlandığı daha genel durumu çözmek için, bir MediaStreamTrack’in parçası olan ve birden fazla birbirine bağlı RTCPeerConnection üzerinden iletilen medya kaynağının veya kaynaklarının kimliğinin bu bağlantılar boyunca korunması gerekir.

12.2.3. Medya Senkronizasyon Bağlamı

Bir uç nokta birden fazla medya kaynağından medya gönderdiğinde, bu medya kaynaklarının senkronize edilip edilmeyeceğini (ve hangilerinin edileceğini) dikkate alması gerekir. RTP/RTCP’de senkronizasyon, bir RTP paket akışı kümesinin aynı senkronizasyon bağlamından ve mantıksal uç noktadan geldiğinin, aynı RTCP CNAME tanımlayıcısı kullanılarak belirtilmesiyle sağlanır.

Bir sonraki koşul, tüm medya kaynaklarının dahili saatlerinin — yani RTP zaman damgasını süren mekanizmanın — RTCP Gönderici Raporlarında NTP biçiminde kodlanan bir sistem saatiyle ilişkilendirilebilmesidir. Tüm RTP zaman damgaları tüm kaynaklar için ortak bir sistem saatine bağlanarak, farklı RTP paket akışlarının zamanlama ilişkisi, birden fazla RTP oturumu genelinde de alıcı tarafta çıkarılabilir ve istenirse akışlar senkronize edilebilir. Gereksinim, medya göndericisinin bu ilişkilendirme bilgisini sağlamasıdır; bilginin kullanılıp kullanılmaması alıcıya bağlıdır.

#13. Güvenlik Hususları

WebRTC için genel güvenlik mimarisi [RFC8827]’de açıklanmıştır ve WebRTC çerçevesi için güvenlik hususları [RFC8826]’da tanımlanmıştır. Bu hususlar bu not için de geçerlidir.

Bu notta tanımlanan eksiksiz protokol paketini oluşturan RTP belirtiminin, RTP/SAVPF profilinin ve çeşitli RTP/RTCP uzantıları ile RTP yük biçimlerinin güvenlik hususları geçerlidir. Bu çeşitli protokol uzantılarının birleşiminden kaynaklanan yeni güvenlik hususları olmadığı düşünülmektedir.

“Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)” [RFC5124], gizlilik, bütünlük ve kısmi kaynak kimlik doğrulaması sunarak temel sorunların ele alınmasını sağlar. Bu güvenli RTP profilinin ve DTLS-SRTP anahtarlandırmasının [RFC5764] birleştirilmesiyle, [RFC8827] Bölüm 5.5’te tanımlandığı üzere, uygulanması ve kullanılması zorunlu olan bir medya güvenliği çözümü meydana getirilir.

RTCP paketleri, ilgili RTP oturumları arasında senkronize edilmesi gereken RTP paket akışlarını ilişkilendirmek için kullanılan bir Kanonik Ad (CNAME) tanımlayıcısı taşır. CNAME değerlerinin uygunsuz seçimi bir gizlilik endişesi olabilir; çünkü uzun süreli kalıcı CNAME tanımlayıcıları, kullanıcıları birden fazla WebRTC çağrısı boyunca izlemek için kullanılabilir. Bu notun Bölüm 4.9’u, RFC 7022’de belirtildiği üzere kısa süreli kalıcı RTCP CNAME’lerinin üretilmesini zorunlu kılar; bu da bu riski azaltan izlenemez CNAME değerleriyle sonuçlanır.

RTCP raporlama aralığı uygunsuz bir değere ayarlanırsa bazı potansiyel hizmet reddi saldırıları mevcuttur. Bu, SDP “b=RR:” veya “b=RS:” satırları [RFC3556] ya da benzer bir mekanizma kullanılarak RTCP bant genişliği payının aşırı derecede büyük veya küçük bir değere ayarlanmasıyla veya RTP/AVPF asgari alıcı raporu aralığı için aşırı derecede büyük ya da küçük bir değer seçilmesiyle (SDP kullanılıyorsa bu, “a=rtcp-fb:... trr-int” parametresidir) [RFC4585] yapılabilir. Riskler şunlardır:

1. RTCP bant genişliği, düzenli raporlama aralığını etkili tıkanıklık kontrolünün sürdürülemeyeceği kadar büyük olacak şekilde yapılandırılabilir ve bu da medya trafiğinin neden olduğu tıkanıklık sonucu hizmet reddine yol açabilir;
2. RTCP aralığı çok küçük bir değere yapılandırılabilir; bu da uç noktaların yüksek oranlı RTCP trafiği üretmesine neden olur ve RTCP trafiğinin tıkanıklık kontrollü olmaması nedeniyle hizmet reddine yol açabilir; ve
3. RTCP parametreleri her uç nokta için farklı yapılandırılabilir; bazı uç noktalar büyük bir raporlama aralığı kullanırken bazıları daha küçük bir aralık kullanır; bu da raporlama aralığına dayanan uyumsuz zaman aşımı süreleri nedeniyle katılımcıların erken zaman aşımına uğraması sonucu hizmet reddine yol açabilir. Bu durum, uç noktaların RTP/AVPF asgari alıcı raporu aralığı (trr-int) [RFC4585] için sıfır olmayan ancak küçük bir değer kullandığı hallerde özellikle endişe vericidir; [RFC8108] Bölüm 6.1’de tartışıldığı gibi.

Katılımcıların erken zaman aşımına uğraması, katılımcı zaman aşımı hesaplanırken sabit (azaltılmamış) asgari aralığın kullanılmasıyla önlenebilir (bu notun Bölüm 4.1’ine ve [RFC8108] Bölüm 7.1.2’ye bakınız). Diğer endişeleri ele almak için, uç noktalar, RTCP raporlama aralığını [RFC3550]’de belirtilen varsayılan beş saniyelik aralıktan önemli ölçüde daha uzun olacak şekilde yapılandıran parametreleri (medya veri hızı o kadar düşük değilse ve daha uzun raporlama aralığı yaklaşık olarak medya veri hızının %5’ine karşılık gelmiyorsa) veya RTCP bant genişliğinin medya bant genişliğini aşmasına neden olacak kadar küçük bir RTCP raporlama aralığı yapılandıran parametreleri GÖZ ARDI ETMELİDİR.

Opus gibi değişken bit hızına (VBR) sahip ses kodekleri kullanılırken [RFC6562]’deki yönergeler geçerlidir (zorunlu ses kodeklerine ilişkin tartışma için Bölüm 4.3’e bakınız). [RFC6562]’deki yönergeler ayrıca, istemciden karıştırıcıya ses seviyesi başlık uzantıları (Bölüm 5.2.2) veya karıştırıcıdan istemciye ses seviyesi başlık uzantıları (Bölüm 5.2.3) kullanılırken de geçerlidir, ancak önemi daha düşüktür. Başlık uzantılarının şifrelenmesinin kullanılması, RTP middlebox’ların ses etkinliğine dayalı kaynak seçimi yapması veya üçüncü taraf izlemenin bu bilgiden büyük ölçüde fayda sağlayacağı ve bunun API ya da sinyalleşme yoluyla ifade edildiği bilinen nedenler olmadıkça ÖNERİLİR. Ses seviyesi göstergelerinden kaynaklanan bilgi sızıntısının önemli olduğunu gösteren ek kanıtlar ortaya konursa, o zaman şifreleme kullanımının zorunlu kılınması gerekir.

RTP middlebox’ların kullanıldığı çok katılımcılı iletişim senaryolarında, oturumun güvenliğini korumak için bu middlebox’lara büyük ölçüde güven duyulur. Middlebox gizliliği ve bütünlüğü sürdürmeli ve kaynak kimlik doğrulaması gerçekleştirmelidir. Bölüm 12.1.1’de tartışıldığı üzere, middlebox bir konferansa katılan herhangi bir uç noktanın başka birini taklit etmesini önleyen kontroller yapabilir. Çok katılımcılı topolojilere ilişkin bazı ek güvenlik hususları [RFC7667]’de bulunabilir.

#14. IANA Hususları

Bu belgenin IANA ile ilgili herhangi bir işlemi yoktur.

#15. Kaynaklar

15.1. Normatif Kaynaklar

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Mart 1997, https://www.rfc-editor.org/info/rfc2119.
• [RFC2736] Handley, M. ve C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, Aralık 1999, https://www.rfc-editor.org/info/rfc2736.
• [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. ve V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Temmuz 2003, https://www.rfc-editor.org/info/rfc3550.
• [RFC3551] Schulzrinne, H. ve S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, Temmuz 2003, https://www.rfc-editor.org/info/rfc3551.
• [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, Temmuz 2003, https://www.rfc-editor.org/info/rfc3556.
• [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, Mart 2004, https://www.rfc-editor.org/info/rfc3711.
• [RFC4566] Handley, M., Jacobson, V. ve C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Temmuz 2006, https://www.rfc-editor.org/info/rfc4566.

[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. ve J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, Temmuz 2006, https://www.rfc-editor.org/info/rfc4585.

[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V. ve R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, Temmuz 2006, https://www.rfc-editor.org/info/rfc4588.

[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, Temmuz 2007, https://www.rfc-editor.org/info/rfc4961.

[RFC5104] Wenger, S., Chandra, U., Westerlund, M. ve B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, Şubat 2008, https://www.rfc-editor.org/info/rfc5104.

[RFC5124] Ott, J. ve E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, Şubat 2008, https://www.rfc-editor.org/info/rfc5124.

[RFC5506] Johansson, I. ve M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, Nisan 2009, https://www.rfc-editor.org/info/rfc5506.

[RFC5761] Perkins, C. ve M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, Nisan 2010, https://www.rfc-editor.org/info/rfc5761.

[RFC5764] McGrew, D. ve E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, Mayıs 2010, https://www.rfc-editor.org/info/rfc5764.

[RFC6051] Perkins, C. ve T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, Kasım 2010, https://www.rfc-editor.org/info/rfc6051.

[RFC6464] Lennox, J., Ed., Ivov, E. ve E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, Aralık 2011, https://www.rfc-editor.org/info/rfc6464.

[RFC6465] Ivov, E., Ed., Marocco, E., Ed. ve J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, Aralık 2011, https://www.rfc-editor.org/info/rfc6465.

[RFC6562] Perkins, C. ve J.M. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, Mart 2012, https://www.rfc-editor.org/info/rfc6562.

[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, Nisan 2013, https://www.rfc-editor.org/info/rfc6904.

[RFC7007] Lennox, J., "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)", RFC 7007, DOI 10.17487/RFC7007, Ağustos 2013, https://www.rfc-editor.org/info/rfc7007.

[RFC7022] Begen, A., Perkins, C., Wing, D. ve E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Eylül 2013, https://www.rfc-editor.org/info/rfc7022.

[RFC7160] Petit-Huguenin, M. ve G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, Nisan 2014, https://www.rfc-editor.org/info/rfc7160.

[RFC7164] Gross, K. ve R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, Mart 2014, https://www.rfc-editor.org/info/rfc7164.

[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, Mart 2016, https://www.rfc-editor.org/info/rfc7742.

[RFC7874] Valin, J.M. ve C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, Mayıs 2016, https://www.rfc-editor.org/info/rfc7874.

[RFC8083] Perkins, C. ve V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, Mart 2017, https://www.rfc-editor.org/info/rfc8083.

[RFC8108] Lennox, J., Westerlund, M., Wu, Q. ve C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, Mart 2017, https://www.rfc-editor.org/info/rfc8108.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mayıs 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8285] Singer, D., Desineni, H. ve R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, Ekim 2017, https://www.rfc-editor.org/info/rfc8285.

[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, Ocak 2021, https://www.rfc-editor.org/info/rfc8825.

[RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, Ocak 2021, https://www.rfc-editor.org/info/rfc8826.

[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, Ocak 2021, https://www.rfc-editor.org/info/rfc8827.

[RFC8843] Holmberg, C., Alvestrand, H. ve C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, Ocak 2021, https://www.rfc-editor.org/info/rfc8843.

[RFC8854] Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, Ocak 2021, https://www.rfc-editor.org/info/rfc8854.

[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, Ocak 2021, https://www.rfc-editor.org/info/rfc8858.

[RFC8860] Westerlund, M., Perkins, C. ve J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", RFC 8860, DOI 10.17487/RFC8860, Ocak 2021, https://www.rfc-editor.org/info/rfc8860.

[RFC8861] Lennox, J., Westerlund, M., Wu, Q. ve C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, Ocak 2021, https://www.rfc-editor.org/info/rfc8861.

[W3C.WD-mediacapture-streams] Jennings, C., Aboba, B., Bruaroey, J.-I. ve H. Boström, "Media Capture and Streams", W3C Aday Tavsiye, https://www.w3.org/TR/mediacapture-streams/.

[W3C.WebRTC] Jennings, C., Boström, H. ve J.-I. Bruaroey, "WebRTC 1.0: Tarayıcılar Arasında Gerçek Zamanlı İletişim", W3C Önerilen Tavsiye, https://www.w3.org/TR/webrtc/.

15.2. Bilgilendirici Referanslar

[RFC3611] Friedman, T., Ed., Caceres, R., Ed. ve A. Clark, Ed., "RTP Kontrol Protokolü Genişletilmiş Raporları (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, Kasım 2003, https://www.rfc-editor.org/info/rfc3611.

[RFC4383] Baugher, M. ve E. Carrara, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) içinde Zamanlamalı Verimli Akış Kayıp-Toleranslı Kimlik Doğrulama (TESLA) Kullanımı", RFC 4383, DOI 10.17487/RFC4383, Şubat 2006, https://www.rfc-editor.org/info/rfc4383.

[RFC5576] Lennox, J., Ott, J. ve T. Schierl, "Oturum Tanımlama Protokolü (SDP) içinde Kaynağa Özgü Medya Öznitelikleri", RFC 5576, DOI 10.17487/RFC5576, Haziran 2009, https://www.rfc-editor.org/info/rfc5576.

[RFC5968] Ott, J. ve C. Perkins, "RTP Kontrol Protokolünü (RTCP) Genişletmeye Yönelik Kılavuzlar", RFC 5968, DOI 10.17487/RFC5968, Eylül 2010, https://www.rfc-editor.org/info/rfc5968.

[RFC6263] Marjou, X. ve A. Sollaud, "RTP / RTP Kontrol Protokolü (RTCP) Akışlarıyla İlişkili NAT Eşlemelerini Canlı Tutmak için Uygulama Mekanizması", RFC 6263, DOI 10.17487/RFC6263, Haziran 2011, https://www.rfc-editor.org/info/rfc6263.

[RFC6792] Wu, Q., Ed., Hunt, G. ve P. Arden, "RTP İzleme Çerçevesinin Kullanımına İlişkin Kılavuzlar", RFC 6792, DOI 10.17487/RFC6792, Kasım 2012, https://www.rfc-editor.org/info/rfc6792.

[RFC7478] Holmberg, C., Hakansson, S. ve G. Eriksson, "Web Gerçek Zamanlı İletişim Kullanım Senaryoları ve Gereksinimler", RFC 7478, DOI 10.17487/RFC7478, Mart 2015, https://www.rfc-editor.org/info/rfc7478.

[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G. ve B. Burman, Ed., "Gerçek Zamanlı Taşıma Protokolü (RTP) Kaynakları için Anlambilim ve Mekanizmaların Sınıflandırılması", RFC 7656, DOI 10.17487/RFC7656, Kasım 2015, https://www.rfc-editor.org/info/rfc7656.

[RFC7657] Black, D., Ed. ve P. Jones, "Ayrıştırılmış Hizmetler (Diffserv) ve Gerçek Zamanlı İletişim", RFC 7657, DOI 10.17487/RFC7657, Kasım 2015, https://www.rfc-editor.org/info/rfc7657.

[RFC7667] Westerlund, M. ve S. Wenger, "RTP Topolojileri", RFC 7667, DOI 10.17487/RFC7667, Kasım 2015, https://www.rfc-editor.org/info/rfc7667.

[RFC8088] Westerlund, M., "Bir RTP Yük Biçimi Nasıl Yazılır", RFC 8088, DOI 10.17487/RFC8088, Mayıs 2017, https://www.rfc-editor.org/info/rfc8088.

[RFC8445] Keranen, A., Holmberg, C. ve J. Rosenberg, "Etkileşimli Bağlantı Kurulumu (ICE): Ağ Adresi Çeviricisi (NAT) Geçişi için Bir Protokol", RFC 8445, DOI 10.17487/RFC8445, Temmuz 2018, https://www.rfc-editor.org/info/rfc8445.

[RFC8829] Uberti, J., Jennings, C. ve E. Rescorla, Ed., "JavaScript Oturum Kurulum Protokolü (JSEP)", RFC 8829, DOI 10.17487/RFC8829, Ocak 2021, https://www.rfc-editor.org/info/rfc8829.

[RFC8830] Alvestrand, H., "Oturum Tanımlama Protokolü içinde WebRTC MediaStream Tanımlaması", RFC 8830, DOI 10.17487/RFC8830, Ocak 2021, https://www.rfc-editor.org/info/rfc8830.

[RFC8836] Jesup, R. ve Z. Sarker, Ed., "Etkileşimli Gerçek Zamanlı Medya için Tıkanıklık Kontrolü Gereksinimleri", RFC 8836, DOI 10.17487/RFC8836, Ocak 2021, https://www.rfc-editor.org/info/rfc8836.

[RFC8837] Jones, P., Dhesikan, S., Jennings, C. ve D. Druta, "WebRTC QoS için Ayrıştırılmış Hizmetler Kod Noktası (DSCP) Paket İşaretlemeleri", RFC 8837, DOI 10.17487/RFC8837, Ocak 2021, https://www.rfc-editor.org/info/rfc8837.

[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H. ve R. Even, "Birden Fazla Medya Akışını Desteklemek için RTP'nin Çoklama Özelliklerinin Kullanımına Yönelik Kılavuzlar", RFC 8872, DOI 10.17487/RFC8872, Ocak 2021, https://www.rfc-editor.org/info/rfc8872.