IETF · Standards Track · Temmuz 2003

RFC 3550

RTP: Gerçek Zamanlı Uygulamalar için Bir Taşıma Protokolü

Yazarlar: H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson · Geçersiz Kılar: RFC 1889
Tüm RFC'ler Orijinal RFC

#Özet

Bu not, gerçek zamanlı taşıma protokolü olan RTP’yi tanımlar. RTP, çok noktaya yayın (multicast) veya tek noktaya yayın (unicast) ağ hizmetleri üzerinden ses, video ya da simülasyon verileri gibi gerçek zamanlı veri ileten uygulamalar için uygun uçtan uca ağ taşıma işlevleri sağlar. RTP, kaynak ayırmayı ele almaz ve gerçek zamanlı hizmetler için hizmet kalitesi garantisi vermez. Veri taşımaya, büyük çok noktaya yayın ağlarına ölçeklenebilir bir biçimde veri iletimini izlemeye ve asgari kontrol ile tanımlama işlevselliği sağlamaya olanak tanıyan bir kontrol protokolü (RTCP) eşlik eder. RTP ve RTCP, alttaki taşıma ve ağ katmanlarından bağımsız olacak şekilde tasarlanmıştır. Protokol, RTP düzeyi çeviricilerin ve karıştırıcıların kullanımını destekler.

Bu notun büyük bölümü, geçersiz kıldığı RFC 1889 ile aynıdır. Ağ üzerinden iletilen paket biçimlerinde değişiklik yoktur; yalnızca protokolün nasıl kullanıldığını yöneten kurallar ve algoritmalarda değişiklikler vardır. En büyük değişiklik, birçok katılımcının aynı anda bir oturuma katılması durumunda hedeflenen oranın üzerindeki iletimi en aza indirmek amacıyla RTCP paketlerinin ne zaman gönderileceğini hesaplayan ölçeklenebilir zamanlayıcı algoritmasındaki iyileştirmedir.

#1. Giriş

Bu not, etkileşimli ses ve video gibi gerçek zamanlı özelliklere sahip veriler için uçtan uca teslim hizmetleri sağlayan gerçek zamanlı taşıma protokolü (RTP)’nü tanımlar. Bu hizmetler; yük türü tanımlama, sıra numaralandırma, zaman damgalama ve teslimat izlemeyi kapsar. Uygulamalar genellikle çoklama ve sağlama toplamı hizmetlerinden yararlanmak için RTP’yi UDP üzerinde çalıştırır; her iki protokol de taşıma protokolü işlevselliğinin bazı kısımlarına katkıda bulunur. Bununla birlikte RTP, uygun olan diğer alttaki ağ veya taşıma protokolleriyle de kullanılabilir (bkz. Bölüm 11). RTP, alttaki ağ tarafından sağlanması halinde, çok noktaya yayın dağıtımı kullanarak birden fazla hedefe veri aktarımını destekler.

RTP’nin kendisinin zamanında teslimi sağlamak veya diğer hizmet kalitesi garantileri sunmak için herhangi bir mekanizma sağlamadığını; bunun yerine bu işlevler için alt katman hizmetlerine dayandığını unutmayınız. Teslimatı garanti etmez veya paketlerin sırasız teslim edilmesini engellemez; alttaki ağın güvenilir olduğunu ve paketleri sıralı olarak teslim ettiğini de varsaymaz. RTP’de yer alan sıra numaraları, alıcının göndericinin paket sırasını yeniden yapılandırmasına olanak tanır; ancak sıra numaraları, örneğin video kod çözmede, paketleri mutlaka sırayla çözmeden bir paketin uygun konumunu belirlemek için de kullanılabilir.

RTP öncelikle çok katılımcılı çoklu ortam konferanslarının gereksinimlerini karşılamak üzere tasarlanmış olsa da, yalnızca bu uygulamayla sınırlı değildir. Sürekli verinin depolanması, etkileşimli dağıtık simülasyon, aktif rozet ve kontrol ile ölçüm uygulamaları da RTP’yi uygulanabilir bulabilir.

Bu belge, birbirine sıkı biçimde bağlı iki bölümden oluşan RTP’yi tanımlar:

  • Gerçek zamanlı özelliklere sahip verileri taşımak için gerçek zamanlı taşıma protokolü (RTP).
  • Hizmet kalitesini izlemek ve devam eden bir oturumdaki katılımcılar hakkında bilgi iletmek için RTP kontrol protokolü (RTCP). RTCP’nin bu ikinci yönü, yani katılımcı bilgisi iletimi, açık bir üyelik kontrolü ve kurulumun olmadığı, "gevşek denetimli" oturumlar için yeterli olabilir; ancak bir uygulamanın tüm kontrol iletişimi gereksinimlerini desteklemek üzere tasarlanmış olması zorunlu değildir. Bu işlevsellik, bu belgenin kapsamı dışında kalan ayrı bir oturum kontrol protokolü tarafından tamamen ya da kısmen üstlenilebilir.

RTP, Clark ve Tennenhouse tarafından önerilen uygulama düzeyi çerçeveleme ve bütünleşik katman işleme ilkelerini izleyen yeni bir protokol tarzını temsil eder [10]. Buna göre RTP, belirli bir uygulamanın gerektirdiği bilgileri sağlayacak şekilde esnek olmayı hedefler ve çoğu zaman ayrı bir katman olarak uygulanmak yerine uygulama işleme sürecine entegre edilir. RTP, bilinçli olarak eksik bırakılmış bir protokol çerçevesidir. Bu belge, RTP’nin uygun olacağı tüm uygulamalar arasında ortak olması beklenen işlevleri tanımlar. Ek işlevlerin protokolü daha genel hale getirerek ya da ayrıştırma gerektiren bir seçenek mekanizması ekleyerek karşılandığı geleneksel protokollerin aksine, RTP’nin gereksinimlere göre başlıklarda yapılan değişiklikler ve/veya eklemeler yoluyla uyarlanması amaçlanır. Örnekler Bölüm 5.3 ve 6.4.3’te verilmiştir.

Bu nedenle, bu belgeye ek olarak, belirli bir uygulama için RTP’nin tam bir tanımı bir veya daha fazla eşlik eden belge gerektirir (bkz. Bölüm 13):

  • Bir profil tanım belgesi; yük türü kodlarının bir kümesini ve bunların yük biçimlerine (ör. ortam kodlamaları) eşlemesini tanımlar. Bir profil ayrıca belirli bir uygulama sınıfına özgü RTP uzantılarını veya değişikliklerini de tanımlayabilir. Tipik olarak bir uygulama yalnızca tek bir profil altında çalışır. Ses ve video verileri için bir profil, eşlik eden RFC 3551 [1] belgesinde bulunabilir.
  • Yük biçimi tanım belgeleri; ses veya video kodlaması gibi belirli bir yükün RTP içinde nasıl taşınacağını tanımlar.

Gerçek zamanlı hizmetlere ve bunların uygulanmasına yönelik algoritmaların tartışması ile bazı RTP tasarım kararlarına ilişkin arka plan bilgileri [11]’de bulunabilir.

1.1 Terminoloji

Bu belgede yer alan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, BCP 14, RFC 2119 [2]’de tanımlandığı şekilde yorumlanacak olup, uyumlu RTP gerçekleştirimleri için gereksinim düzeylerini belirtir.

#2. RTP Kullanım Senaryoları

Aşağıdaki bölümler, RTP’nin kullanımına ilişkin bazı yönleri açıklar. Örnekler, RTP’nin hangi amaçlarla kullanılabileceğini sınırlamak için değil, RTP kullanan uygulamaların temel işleyişini göstermek amacıyla seçilmiştir. Bu örneklerde RTP, IP ve UDP üzerinde taşınmakta ve eşlik eden RFC 3551’de belirtilen ses ve video profili tarafından oluşturulan kuralları izlemektedir.

2.1 Basit Çok Noktaya Yayın Ses Konferansı

IETF’nin bir çalışma grubu, en son protokol belgesini tartışmak üzere, ses iletişimi için İnternet’in IP çok noktaya yayın hizmetlerini kullanarak bir araya gelir. Bir tahsis mekanizması aracılığıyla, çalışma grubu başkanı bir çok noktaya yayın grup adresi ve bir port çifti elde eder. Bir port ses verisi için, diğeri ise kontrol (RTCP) paketleri için kullanılır. Bu adres ve port bilgileri, hedeflenen katılımcılara dağıtılır. Gizlilik isteniyorsa, Bölüm 9.1’de belirtildiği gibi veri ve kontrol paketleri şifrelenebilir; bu durumda bir şifreleme anahtarının da oluşturulması ve dağıtılması gerekir. Bu tahsis ve dağıtım mekanizmalarının ayrıntıları RTP’nin kapsamı dışındadır.

Her konferans katılımcısı tarafından kullanılan ses konferansı uygulaması, örneğin 20 ms süreli küçük parçalar halinde ses verisi gönderir. Her ses veri parçasının önünde bir RTP başlığı bulunur; RTP başlığı ve veri birlikte bir UDP paketi içinde yer alır. RTP başlığı, her paketin hangi tür ses kodlamasını (PCM, ADPCM veya LPC gibi) içerdiğini belirtir; böylece göndericiler konferans sırasında, örneğin düşük bant genişlikli bir bağlantı üzerinden bağlanan yeni bir katılımcıya uyum sağlamak veya ağ tıkanıklığına ilişkin göstergelere tepki vermek için kodlamayı değiştirebilir.

İnternet, diğer paket ağları gibi, zaman zaman paketleri kaybeder, sıralarını değiştirir ve değişken sürelerde geciktirir. Bu bozulmalarla başa çıkmak için RTP başlığı, alıcıların kaynağın ürettiği zamanlamayı yeniden yapılandırmasına olanak tanıyan zamanlama bilgileri ve bir sıra numarası içerir; böylece bu örnekte ses parçaları her 20 ms’de bir hoparlörden kesintisiz olarak çalınır. Bu zamanlama yeniden yapılandırması, konferanstaki her RTP paket kaynağı için ayrı ayrı gerçekleştirilir. Sıra numarası ayrıca alıcı tarafından kaç paketin kaybolduğunu tahmin etmek için de kullanılabilir.

Çalışma grubunun üyeleri konferans sırasında katılıp ayrıldığından, herhangi bir anda kimlerin katıldığını ve ses verisini ne kadar iyi aldıklarını bilmek yararlıdır. Bu amaçla, konferanstaki ses uygulamasının her bir örneği, RTCP (kontrol) portu üzerinden periyodik olarak bir alım raporu ile birlikte kullanıcısının adını çok noktaya yayınla gönderir. Alım raporu, mevcut konuşmacının ne kadar iyi alındığını gösterir ve uyarlamalı kodlamaların denetiminde kullanılabilir. Kullanıcı adına ek olarak, bant genişliği sınırlarına tabi olmak kaydıyla başka tanımlayıcı bilgiler de dahil edilebilir. Bir site, konferanstan ayrıldığında RTCP BYE paketini (Bölüm 6.6) gönderir.

2.2 Ses ve Video Konferansı

Bir konferansta hem ses hem de video ortamları kullanılıyorsa, bunlar ayrı RTP oturumları olarak iletilir. Yani, her bir ortam için iki farklı UDP port çifti ve/veya çoklu yayın adresi kullanılarak ayrı RTP ve RTCP paketleri iletilir. RTP düzeyinde ses ve video oturumları arasında doğrudan bir bağ yoktur; tek istisna, her iki oturuma da katılan bir kullanıcının, oturumların ilişkilendirilebilmesi için her ikisi için de RTCP paketlerinde aynı ayırt edici (kanonik) adı kullanması gerektiğidir.

Bu ayrımın bir gerekçesi, konferanstaki bazı katılımcıların isterlerse yalnızca tek bir ortamı alabilmelerine olanak tanımaktır. Daha fazla açıklama Bölüm 5.2'de verilmiştir. Ayrıma rağmen, bir kaynağın ses ve videosunun eşzamanlı oynatımı, her iki oturum için RTCP paketlerinde taşınan zamanlama bilgileri kullanılarak sağlanabilir.

2.3 Karıştırıcılar ve Çeviriciler

Şimdiye kadar, tüm sitelerin ortam verisini aynı biçimde almak istediğini varsaydık. Ancak bu her zaman uygun olmayabilir. Bir bölgede bulunan katılımcıların, yüksek hızlı ağ erişimine sahip konferans katılımcılarının çoğunluğuna düşük hızlı bir bağlantı üzerinden bağlandığı durumu ele alalım. Herkesi daha düşük bant genişliğine sahip, kalitesi düşürülmüş bir ses kodlaması kullanmaya zorlamak yerine, düşük bant genişliğine sahip bölgenin yakınına karıştırıcı (mixer) adı verilen RTP düzeyinde bir aktarıcı yerleştirilebilir. Bu karıştırıcı, gönderici tarafından üretilen sabit 20 ms aralığını yeniden oluşturmak için gelen ses paketlerini yeniden eşzamanlar, bu yeniden oluşturulmuş ses akışlarını tek bir akışta birleştirir, ses kodlamasını daha düşük bant genişliğine sahip bir kodlamaya çevirir ve düşük bant genişliğine sahip paket akışını düşük hızlı bağlantı üzerinden iletir. Bu paketler tek bir alıcıya tekil yayın (unicast) olarak gönderilebilir ya da birden fazla alıcıya farklı bir adreste çoklu yayın (multicast) olarak dağıtılabilir. RTP başlığı, karıştırıcıların birleştirilmiş bir pakete katkıda bulunan kaynakları tanımlayabilmesi için bir mekanizma içerir; böylece alıcılarda doğru konuşmacı göstergesi sağlanabilir.

Ses konferansına katılması amaçlanan bazı katılımcılar yüksek bant genişliğine sahip bağlantılarla bağlı olabilir, ancak IP çoklu yayın yoluyla doğrudan erişilebilir olmayabilirler. Örneğin, herhangi bir IP paketinin geçmesine izin vermeyen uygulama düzeyinde bir güvenlik duvarının arkasında olabilirler. Bu siteler için karıştırma gerekli olmayabilir; bu durumda çevirici (translator) adı verilen başka bir RTP düzeyinde aktarıcı kullanılabilir. Güvenlik duvarının her iki tarafına birer tane olmak üzere iki çevirici kurulur; dış taraftaki çevirici, aldığı tüm çoklu yayın paketlerini güvenli bir bağlantı üzerinden güvenlik duvarının içindeki çeviriciye yönlendirir. Güvenlik duvarının içindeki çevirici ise bu paketleri, sitenin iç ağıyla sınırlı bir çoklu yayın grubuna tekrar çoklu yayın paketleri olarak gönderir.

Karıştırıcılar ve çeviriciler çeşitli amaçlar için tasarlanabilir. Buna bir örnek, ayrı video akışlarındaki bireylerin görüntülerini ölçeklendiren ve bunları tek bir video akışında birleştirerek bir grup sahnesini benzeten bir video karıştırıcıdır. Çeviriye diğer örnekler arasında, yalnızca IP/UDP konuşan bir ana bilgisayar grubunun yalnızca ST-II anlayan bir ana bilgisayar grubuna bağlanması ya da yeniden eşzamanlama veya karıştırma olmaksızın bireysel kaynaklardan gelen video akışlarının paket bazında kodlama çevirisi yer alır. Karıştırıcıların ve çeviricilerin çalışmasına ilişkin ayrıntılar Bölüm 7'de verilmiştir.

2.4 Katmanlı Kodlamalar

Çoklu ortam uygulamaları, iletim hızını alıcının kapasitesine uyacak şekilde ayarlayabilmeli veya ağ tıkanıklığına uyum sağlayabilmelidir. Birçok uygulama, hız uyarlanabilirliği sorumluluğunu kaynağa yükler. Bu yaklaşım, farklı özelliklere sahip alıcıların çelişen bant genişliği gereksinimleri nedeniyle çoklu yayın iletimiyle iyi çalışmaz. Sonuç çoğu zaman, ağ örgüsündeki en dar boğazın genel canlı çoklu ortam "yayınının" kalitesini ve doğruluğunu belirlediği en düşük ortak payda senaryosudur.

Bunun yerine, hız uyarlama sorumluluğu, katmanlı bir kodlama ile katmanlı bir iletim sistemini birleştirerek alıcılara verilebilir. IP çoklu yayın üzerinden RTP bağlamında, kaynak hiyerarşik olarak temsil edilen bir sinyalin aşamalı katmanlarını, her biri kendi çoklu yayın grubunda taşınan birden fazla RTP oturumuna şeritler halinde dağıtabilir. Alıcılar daha sonra, yalnızca uygun çoklu yayın gruplarının alt kümesine katılarak ağ heterojenliğine uyum sağlayabilir ve aldıkları bant genişliğini denetleyebilir.

RTP'nin katmanlı kodlamalarla kullanımına ilişkin ayrıntılar Bölüm 6.3.9, 8.3 ve 11'de verilmiştir.

#3. Tanımlar

RTP yükü (payload): RTP tarafından bir pakette taşınan veri; örneğin ses örnekleri veya sıkıştırılmış video verisi. Yük biçimi ve yorumu bu belgenin kapsamı dışındadır.

RTP paketi: Sabit RTP başlığından, katkıda bulunan kaynakların (aşağıya bakınız) muhtemelen boş bir listesinden ve yük verisinden oluşan bir veri paketi. Bazı alt düzey protokoller, RTP paketinin kapsüllenmesinin tanımlanmasını gerektirebilir. Genellikle alt düzey protokolün bir paketi tek bir RTP paketi içerir; ancak kapsülleme yöntemi izin veriyorsa birden fazla RTP paketi de içerebilir (bkz. Bölüm 11).

RTCP paketi: RTP veri paketlerininkine benzer sabit bir başlık bölümünden ve ardından RTCP paket türüne bağlı olarak değişen yapılandırılmış öğelerden oluşan bir denetim paketi. Biçimler Bölüm 6'da tanımlanmıştır. Genellikle birden fazla RTCP paketi, alt düzey protokolün tek bir paketi içinde bileşik bir RTCP paketi olarak birlikte gönderilir; bu, her RTCP paketinin sabit başlığındaki uzunluk alanı tarafından mümkün kılınır.

Port: "Taşıma protokollerinin, belirli bir ana bilgisayar içindeki birden fazla hedefi ayırt etmek için kullandığı soyutlama. TCP/IP protokolleri portları küçük pozitif tamsayılar kullanarak tanımlar." [12] OSI taşıma katmanı tarafından kullanılan taşıma seçicileri (TSEL) portlara eşdeğerdir. RTP, bir oturumun RTP ve RTCP paketlerini çoğullamak için portlar gibi bir mekanizma sağlaması konusunda alt katman protokolüne dayanır.

Taşıma adresi: Taşıma düzeyindeki bir uç noktayı tanımlayan ağ adresi ve portun birleşimi; örneğin bir IP adresi ve bir UDP portu. Paketler bir kaynak taşıma adresinden bir hedef taşıma adresine iletilir.

RTP ortam türü: Bir RTP ortam türü, tek bir RTP oturumu içinde taşınabilen yük türlerinin toplamıdır. RTP Profili, RTP ortam türlerini RTP yük türlerine atar.

Çoklu ortam oturumu: Ortak bir katılımcı grubunu içeren eşzamanlı RTP oturumları kümesi. Örneğin, bir video konferans (bir çoklu ortam oturumudur) bir ses RTP oturumu ve bir video RTP oturumu içerebilir.

RTP oturumu: RTP ile iletişim kuran bir katılımcı kümesi arasındaki ilişki. Bir katılımcı aynı anda birden fazla RTP oturumunda yer alabilir. Bir çoklu ortam oturumunda, kodlamanın kendisi birden fazla ortamı tek bir veri akışında çoğullamıyorsa, her ortam genellikle kendi RTCP paketlerine sahip ayrı bir RTP oturumunda taşınır. Bir katılımcı, farklı hedef taşıma adresi çiftleri kullanan farklı oturumları alarak birden fazla RTP oturumunu ayırt eder; burada bir taşıma adresi çifti, RTP ve RTCP için bir ağ adresi artı bir port çifti içerir. Bir RTP oturumundaki tüm katılımcılar, IP çoklu yayın durumunda olduğu gibi ortak bir hedef taşıma adresi çiftini paylaşabilir ya da bireysel tekil yayın ağ adresleri ve port çiftleri durumunda olduğu gibi her katılımcı için çiftler farklı olabilir. Tekil yayın durumunda, bir katılımcı oturumdaki diğer tüm katılımcılardan aynı port çifti üzerinden alım yapabilir ya da her biri için ayrı bir port çifti kullanabilir.

Bir RTP oturumunun ayırt edici özelliği, her birinin SSRC tanımlayıcıları için (aşağıda tanımlanan) tam ve ayrı bir alanı korumasıdır. Bir RTP oturumuna dahil edilen katılımcılar kümesi, katılımcılardan herhangi biri tarafından RTP'de SSRC veya CSRC (aşağıda tanımlanmıştır) olarak ya da RTCP'de iletilen bir SSRC tanımlayıcısını alabilenlerden oluşur. Örneğin, her katılımcının diğer ikisinden ayrı port çiftleri üzerinden alım yaptığı tekil yayın UDP kullanılarak uygulanmış üç taraflı bir konferansı ele alalım. Eğer her katılımcı, yalnızca bir diğer katılımcıdan aldığı verilerle ilgili RTCP geri bildirimini sadece o katılımcıya geri gönderirse, konferans üç ayrı noktadan noktaya RTP oturumundan oluşur. Eğer her katılımcı, bir diğer katılımcıyı alımına ilişkin RTCP geri bildirimini her iki diğer katılımcıya da sağlarsa, konferans tek bir çok taraflı RTP oturumundan oluşur. İkinci durum, üç katılımcı arasında IP çoklu yayın iletişimiyle oluşacak davranışı benzetir.

RTP çerçevesi burada tanımlanan varyasyonlara izin verir; ancak belirli bir denetim protokolü veya uygulama tasarımı genellikle bu varyasyonlar üzerinde kısıtlamalar getirir.

Eşzamanlama kaynağı (SSRC): Ağ adresine bağımlı olmaması için RTP başlığında taşınan 32 bitlik sayısal bir SSRC tanımlayıcısıyla belirlenen, bir RTP paketleri akışının kaynağıdır. Bir eşzamanlama kaynağından gelen tüm paketler aynı zamanlama ve sıra numarası alanının parçasını oluşturur; bu nedenle bir alıcı, oynatma için paketleri eşzamanlama kaynağına göre gruplar. Eşzamanlama kaynaklarına örnek olarak mikrofon veya kamera gibi bir sinyal kaynağından türetilmiş paket akışının göndericisi ya da bir RTP karıştırıcısı (aşağıya bakınız) verilebilir. Bir eşzamanlama kaynağı zaman içinde veri biçimini, örneğin ses kodlamasını, değiştirebilir. SSRC tanımlayıcısı, belirli bir RTP oturumu içinde küresel olarak benzersiz olması amaçlanan rastgele seçilmiş bir değerdir (bkz. Bölüm 8). Bir katılımcının, bir çoklu ortam oturumundaki tüm RTP oturumları için aynı SSRC tanımlayıcısını kullanması gerekmez; SSRC tanımlayıcılarının bağlanması RTCP aracılığıyla sağlanır (bkz. Bölüm 6.5.1). Bir katılımcı tek bir RTP oturumunda, örneğin ayrı video kameralarından, birden fazla akış üretirse, her biri farklı bir SSRC olarak tanımlanmak ZORUNDADIR.

Katkıda bulunan kaynak (CSRC): Bir RTP karıştırıcısı tarafından üretilen birleşik akışa katkıda bulunmuş olan bir RTP paketleri akışının kaynağıdır (aşağıya bakınız). Karıştırıcı, belirli bir paketin üretilmesine katkıda bulunan kaynakların SSRC tanımlayıcılarının bir listesini o paketin RTP başlığına ekler. Bu liste CSRC listesi olarak adlandırılır. Örnek bir uygulama, bir karıştırıcının konuşmaları birleştirilen tüm konuşmacıları belirtmesiyle, alıcının mevcut konuşmacıyı gösterebilmesine olanak tanıyan ses konferansıdır; bu durumda tüm ses paketleri aynı SSRC tanımlayıcısını (karıştırıcınınkini) içerir.

Uç sistem: RTP paketlerinde gönderilecek içeriği üreten ve/veya alınan RTP paketlerinin içeriğini tüketen bir uygulamadır. Bir uç sistem, belirli bir RTP oturumunda bir veya daha fazla eşzamanlama kaynağı olarak hareket edebilir, ancak genellikle yalnızca bir tane olur.

Karıştırıcı (Mixer): Bir veya daha fazla kaynaktan RTP paketleri alan, verinin biçimini muhtemelen değiştiren, paketleri bir şekilde birleştiren ve ardından yeni bir RTP paketi ileten ara bir sistemdir. Birden fazla giriş kaynağı arasındaki zamanlama genellikle eşzamanlı olmayacağından, karıştırıcı akışlar arasında zamanlama ayarlamaları yapar ve birleşik akış için kendi zamanlamasını üretir. Dolayısıyla, bir karıştırıcıdan kaynaklanan tüm veri paketleri, eşzamanlama kaynağı olarak karıştırıcıya sahip olacak şekilde tanımlanır.

Çevirici (Translator): Eşzamanlama kaynağı tanımlayıcısını bozulmadan bırakarak RTP paketlerini ileten ara bir sistemdir. Çeviricilere örnek olarak karıştırma olmaksızın kodlama dönüştüren aygıtlar, çoklu yayından tekil yayına çoğaltıcılar ve güvenlik duvarlarındaki uygulama düzeyinde filtreler verilebilir.

İzleyici (Monitor): Bir RTP oturumundaki katılımcılar tarafından gönderilen RTCP paketlerini, özellikle alım raporlarını alan ve dağıtım izleme, arıza teşhisi ve uzun vadeli istatistikler için mevcut hizmet kalitesini tahmin eden bir uygulamadır. İzleyici işlevi büyük olasılıkla oturuma katılan uygulamaların içine yerleştirilmiştir; ancak aksi halde katılmayan ve RTP veri paketlerini göndermeyen veya almayan (ayrı bir portta oldukları için) ayrı bir uygulama da olabilir. Bunlara *üçüncü taraf izleyiciler* denir. Bir üçüncü taraf izleyicinin RTP veri paketlerini alması, ancak RTCP paketleri göndermemesi veya başka şekilde oturumda sayılmaması da kabul edilebilir.

RTP dışı araçlar: Kullanılabilir bir hizmet sağlamak için RTP'ye ek olarak gerekebilecek protokoller ve mekanizmalardır. Özellikle çoklu ortam konferansları için bir denetim protokolü, çoklu yayın adreslerini ve şifreleme anahtarlarını dağıtabilir, kullanılacak şifreleme algoritmasını müzakere edebilir ve önceden tanımlı bir yük türü değeri olmayan biçimler için RTP yük türü değerleri ile temsil ettikleri yük biçimleri arasında dinamik eşlemeleri tanımlayabilir. Bu tür protokollere örnek olarak Session Initiation Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] ve RTSP (RFC 2326 [16]) gibi SDP (RFC 2327 [15]) kullanan uygulamalar verilebilir. Basit uygulamalar için elektronik posta veya bir konferans veritabanı da kullanılabilir. Bu tür protokollerin ve mekanizmaların belirtimi bu belgenin kapsamı dışındadır.

#4. Bayt Sırası, Hizalama ve Zaman Biçimi

Tüm tamsayı alanları ağ bayt sırasıyla, yani en anlamlı bayt (sekizli) önce olacak şekilde taşınır. Bu bayt sırası yaygın olarak big-endian olarak bilinir. İletim sırası [3]'te ayrıntılı olarak açıklanmıştır. Aksi belirtilmedikçe, sayısal sabitler ondalık (taban 10) biçimdedir.

Tüm başlık verileri doğal uzunluklarına göre hizalanır; yani 16 bitlik alanlar çift ofsetlerde, 32 bitlik alanlar dörde bölünebilen ofsetlerde hizalanır vb. Dolgu olarak belirtilen sekizlilerin değeri sıfırdır.

Duvar saati zamanı (mutlak tarih ve saat), Network Time Protocol (NTP) zaman damgası biçimi kullanılarak temsil edilir; bu biçim, 1 Ocak 1900 UTC saat 0'a göre saniye cinsindendir [4]. Tam çözünürlüklü NTP zaman damgası, ilk 32 bitinde tamsayı kısmı ve son 32 bitinde kesirli kısmı bulunan 64 bitlik işaretsiz sabit noktalı bir sayıdır. Daha kompakt bir gösterimin uygun olduğu bazı alanlarda yalnızca orta 32 bit kullanılır; yani tamsayı kısmının düşük 16 biti ve kesirli kısmın yüksek 16 biti. Tamsayı kısmının yüksek 16 bitinin bağımsız olarak belirlenmesi gerekir.

RTP'yi kullanmak için bir uygulamanın Network Time Protocol'ü çalıştırması gerekmez. Başka zaman kaynakları veya hiçbiri kullanılmayabilir (bkz. Bölüm 6.4.1'deki NTP zaman damgası alanının açıklaması). Ancak NTP'nin çalıştırılması, ayrı ana bilgisayarlardan iletilen akışların eşzamanlanması için yararlı olabilir.

NTP zaman damgası 2036 yılı civarında sıfıra geri dönecektir; ancak RTP amaçları için yalnızca NTP zaman damgası çiftleri arasındaki farklar kullanılır. Zaman damgası çiftlerinin birbirinden 68 yıl içinde olduğu varsayılabildiği sürece, çıkarma ve karşılaştırmalar için modüler aritmetik kullanılması bu geri dönüşü önemsiz kılar.

#5. RTP Veri Aktarım Protokolü

5.1 RTP Sabit Başlık Alanları

RTP başlığı aşağıdaki biçime sahiptir:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |        sıra numarası            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           zaman damgası                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        senkronizasyon kaynağı (SSRC) tanımlayıcısı              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|           katkıda bulunan kaynak (CSRC) tanımlayıcıları         |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

İlk on iki oktet her RTP paketinde bulunur; CSRC tanımlayıcılarının listesi ise yalnızca bir karıştırıcı (mixer) tarafından eklendiğinde bulunur. Alanların anlamları aşağıdaki gibidir:

  • sürüm (V): 2 bit

    Bu alan RTP’nin sürümünü belirtir. Bu belirtimde tanımlanan sürüm iki (2)’dir. (Değer 1, RTP’nin ilk taslak sürümü tarafından kullanılmıştır ve değer 0, başlangıçta “vat” ses aracı içinde uygulanan protokol tarafından kullanılmıştır.)

  • dolgu (P): 1 bit

    Dolgu biti ayarlanmışsa, paket yükün bir parçası olmayan ve paketin sonunda bulunan bir veya daha fazla ek dolgu okteti içerir. Dolgunun son okteti, kendisi de dahil olmak üzere göz ardı edilmesi gereken dolgu oktetlerinin sayısını içerir. Dolgu, sabit blok boyutlarına sahip bazı şifreleme algoritmaları için veya bir alt katman protokolü veri birimi içinde birden fazla RTP paketinin taşınması için gerekebilir.

  • uzantı (X): 1 bit

    Uzantı biti ayarlanmışsa, sabit başlığı, Bölüm 5.3.1’de tanımlanan biçime sahip tam olarak bir başlık uzantısı MUTLAKA izlemelidir.

  • CSRC sayısı (CC): 4 bit

    CSRC sayısı, sabit başlığı izleyen CSRC tanımlayıcılarının sayısını içerir.

  • işaretleyici (M): 1 bit

    İşaretleyicinin yorumu bir profil tarafından tanımlanır. Paket akışında kare sınırları gibi önemli olayların işaretlenmesine olanak tanımak için tasarlanmıştır. Bir profil, ek işaretleyici bitleri tanımlayabilir veya yük türü alanındaki bit sayısını değiştirerek işaretleyici biti olmadığını belirtebilir (Bkz. Bölüm 5.3).

  • yük türü (PT): 7 bit

    Bu alan RTP yükünün biçimini tanımlar ve uygulama tarafından nasıl yorumlanacağını belirler. Bir profil, yük türü kodlarının yük biçimlerine varsayılan statik bir eşlemesini belirtebilir. Ek yük türü kodları, RTP dışı yollarla dinamik olarak tanımlanabilir (Bkz. Bölüm 3). Ses ve video için varsayılan eşlemeler kümesi, eşlik eden RFC 3551 [1]’de belirtilmiştir. Bir RTP kaynağı bir oturum sırasında yük türünü değiştirebilir; ancak bu alan, ayrı medya akışlarını çoklamalı taşımak için KULLANILMAMALIDIR (Bkz. Bölüm 5.2).

    Bir alıcı, anlamadığı yük türlerine sahip paketleri MUTLAKA yok saymalıdır.

  • sıra numarası: 16 bit

    Sıra numarası, gönderilen her RTP veri paketi için bir artar ve alıcı tarafından paket kaybını saptamak ve paket sırasını yeniden kurmak için kullanılabilir. Sıra numarasının başlangıç değeri, şifreleme için Bölüm 9.1’deki yönteme göre kaynak tarafından şifreleme yapılmasa bile, paketler bunu yapan bir çeviriciden geçebileceğinden, şifreleme üzerindeki bilinen-düzmetin saldırılarını zorlaştırmak amacıyla rastgele (öngörülemez) OLMALIDIR. Öngörülemez sayıların seçilmesine yönelik teknikler [17]’de tartışılmaktadır.

  • zaman damgası: 32 bit

    Zaman damgası, RTP veri paketindeki ilk oktetin örnekleme anını yansıtır. Örnekleme anı, senkronizasyon ve titreşim (jitter) hesaplamalarına olanak tanımak için zamanda monotonik ve doğrusal olarak artan bir saatten MUTLAKA türetilmelidir (Bkz. Bölüm 6.4.1). Saatin çözünürlüğü, istenen senkronizasyon doğruluğu ve paket varış titreşimini ölçmek için yeterli OLMALIDIR (video kare başına bir tik genellikle yeterli değildir). Saat frekansı, yük olarak taşınan verinin biçimine bağlıdır ve biçimi tanımlayan profil veya yük biçimi belirtiminde statik olarak belirtilir ya da RTP dışı yollarla tanımlanan yük biçimleri için dinamik olarak belirtilebilir.

    RTP paketleri periyodik olarak üretiliyorsa, sistem saatinin okunması değil, örnekleme saatinden belirlenen nominal örnekleme anı kullanılmalıdır. Örneğin, sabit hızlı ses için zaman damgası saati büyük olasılıkla her örnekleme periyodu için bir artar. Bir ses uygulaması giriş aygıtından 160 örnekleme periyodunu kapsayan bloklar okuyorsa, bu tür her blok için — blok bir pakette iletilsin ya da sessiz olarak düşürülsün — zaman damgası 160 artırılır.

    Zaman damgasının başlangıç değeri, sıra numarasında olduğu gibi rastgele OLMALIDIR. Mantıksal olarak aynı anda üretilmişlerse (örneğin aynı video karesine aitlerse), art arda gelen birkaç RTP paketinin zaman damgaları eşit olacaktır. MPEG enterpolasyonlu video kareleri durumunda olduğu gibi, veri örneklendiği sırayla iletilmiyorsa, ardışık RTP paketleri monotonik olmayan zaman damgaları içerebilir. (İletildiği şekliyle paketlerin sıra numaraları yine de monotonik olacaktır.)

    Farklı medya akışlarından gelen RTP zaman damgaları farklı hızlarda ilerleyebilir ve genellikle bağımsız, rastgele ofsetlere sahiptir. Bu nedenle, bu zaman damgaları tek bir akışın zamanlamasını yeniden kurmak için yeterli olsa da, farklı medyaların RTP zaman damgalarını doğrudan karşılaştırmak senkronizasyon için etkili değildir. Bunun yerine, her ortam için RTP zaman damgası, RTP zaman damgasına karşılık gelen verinin örneklendiği zamanı temsil eden bir referans saatinden (duvar saati) alınan bir zaman damgası ile eşleştirilir. Referans saat, senkronize edilecek tüm medyalar tarafından paylaşılır. Zaman damgası çiftleri her veri paketinde iletilmez; Bölüm 6.4’te açıklandığı üzere RTCP SR paketlerinde daha düşük bir hızda iletilir.

    Örnekleme anı, RTP zaman damgası için referans noktası olarak seçilir; çünkü bu an, ileten uç nokta tarafından bilinir ve kodlama gecikmeleri veya diğer işlemlerden bağımsız olarak tüm medyalar için ortak bir tanıma sahiptir. Amaç, aynı anda örneklenen tüm medyaların senkronize sunumuna olanak tanımaktır.

    Gerçek zamanlı olarak örneklenen veri yerine depolanmış veri ileten uygulamalar, genellikle duvar saati zamanından türetilmiş sanal bir sunum zaman çizelgesi kullanarak, depolanmış verideki her ortamın bir sonraki karesinin veya diğer biriminin ne zaman sunulacağını belirler. Bu durumda, RTP zaman damgası her birim için sunum zamanını yansıtır. Yani, her birimin RTP zaman damgası, birimin sanal sunum zaman çizelgesinde geçerli hale geldiği duvar saati zamanı ile ilişkilidir. Gerçek sunum, alıcı tarafından belirlendiği üzere bir süre sonra gerçekleşir.

    Önceden kaydedilmiş bir videonun canlı sesli anlatımını tanımlayan bir örnek, referans noktası olarak örnekleme anının seçilmesinin önemini gösterir. Bu senaryoda video, anlatıcının izlemesi için yerel olarak sunulur ve eşzamanlı olarak RTP kullanılarak iletilir. RTP ile iletilen bir video karesinin örnekleme anı, zaman damgasının, o video karesinin anlatıcıya sunulduğu duvar saati zamanına referanslanmasıyla belirlenir. Anlatıcının konuşmasını içeren ses RTP paketleri için örnekleme anı da, sesin örneklendiği aynı duvar saati zamanına referanslanarak belirlenir. Referans saatleri NTP gibi bir yöntemle senkronize edilmişse, ses ve video hatta farklı ana bilgisayarlar tarafından bile iletilebilir. Bir alıcı, RTCP SR paketlerindeki zaman damgası çiftlerini kullanarak RTP zaman damgalarını ilişkilendirip ses ve video paketlerinin sunumunu senkronize edebilir.

  • SSRC: 32 bit

    SSRC alanı senkronizasyon kaynağını tanımlar. Bu tanımlayıcı, aynı RTP oturumu içindeki iki senkronizasyon kaynağının aynı SSRC tanımlayıcısına sahip olmaması amacıyla rastgele seçilmelidir. Rastgele bir tanımlayıcı üretmek için örnek bir algoritma Ek A.6’da sunulmuştur. Birden fazla kaynağın aynı tanımlayıcıyı seçme olasılığı düşük olsa da, tüm RTP uygulamaları çakışmaları saptamaya ve çözmeye hazır olmalıdır. Bölüm 8, SSRC tanımlayıcısının benzersizliğine dayalı olarak çakışma olasılığını ve çakışmaları çözme ile RTP düzeyinde yönlendirme döngülerini saptama mekanizmasını açıklar. Bir kaynak, kaynak taşıma adresini değiştirirse, döngüye girmiş bir kaynak olarak yorumlanmamak için yeni bir SSRC tanımlayıcısı da seçmelidir (Bkz. Bölüm 8.2).

  • CSRC listesi: 0 ile 15 öğe, her biri 32 bit

    CSRC listesi, bu pakette bulunan yük için katkıda bulunan kaynakları tanımlar. Tanımlayıcıların sayısı CC alanı tarafından verilir. 15’ten fazla katkıda bulunan kaynak varsa, yalnızca 15’i tanımlanabilir. CSRC tanımlayıcıları, katkıda bulunan kaynakların SSRC tanımlayıcıları kullanılarak karıştırıcılar tarafından eklenir (Bkz. Bölüm 7.1). Örneğin, ses paketleri için, bir paketi meydana getirmek üzere birlikte karıştırılan tüm kaynakların SSRC tanımlayıcıları listelenir; bu da alıcıda doğru konuşmacı göstergesine olanak tanır.

5.2 RTP Oturumlarının Çoklanması

Verimli protokol işleme için, tümleşik katman işleme tasarım ilkesi [10]’nde açıklandığı gibi, çoklama noktalarının sayısı en aza indirilmelidir. RTP’de çoklama, her RTP oturumu için farklı olan hedef taşıma adresi (ağ adresi ve bağlantı noktası numarası) ile sağlanır. Örneğin, ses ve video ortamlarının ayrı ayrı kodlandığı bir telekonferansta, her ortam KENDİ hedef taşıma adresine sahip ayrı bir RTP oturumunda taşınmalıdır.

Ayrı ses ve video akışları, yük türü veya SSRC alanlarına dayalı olarak ayrıştırılmak üzere tek bir RTP oturumunda TAŞINMAMALIDIR. Farklı RTP medya türlerine sahip paketlerin, aynı SSRC kullanılarak iç içe geçirilmesi çeşitli sorunlara yol açar:

  1. Örneğin iki ses akışı aynı RTP oturumunu ve aynı SSRC değerini paylaşıyorsa ve bunlardan biri kodlamasını değiştirerek farklı bir RTP yük türü edinirse, hangi akışın kodlamayı değiştirdiğini tanımlamanın genel bir yolu olmaz.
  2. Bir SSRC, tek bir zamanlama ve sıra numarası uzayını tanımlamak üzere belirlenmiştir. Birden fazla yük türünün iç içe geçirilmesi, medya saat hızları farklıysa farklı zamanlama uzayları gerektirir ve hangi yük türünün paket kaybına uğradığını belirlemek için farklı sıra numarası uzayları gerektirir.
  3. RTCP gönderici ve alıcı raporları (Bkz. Bölüm 6.4), SSRC başına yalnızca bir zamanlama ve sıra numarası uzayını tanımlayabilir ve bir yük türü alanı taşımaz.
  4. Bir RTP karıştırıcısı, uyumsuz medyaların iç içe geçmiş akışlarını tek bir akışta birleştiremez.
  5. Bir RTP oturumunda birden fazla medya taşımak; uygun olduğunda farklı ağ yollarının veya ağ kaynak tahsislerinin kullanılmasını; istenirse medyanın bir alt kümesinin (örneğin video mevcut bant genişliğini aşacaksa yalnızca sesin) alınmasını; ve farklı medyalar için ayrı süreçler kullanan alıcı uygulamalarını engeller. Oysa ayrı RTP oturumlarının kullanılması, tek süreçli veya çok süreçli uygulamalara olanak tanır.

Her ortam için farklı bir SSRC kullanıp bunları aynı RTP oturumunda göndermek, ilk üç sorunu önler; ancak son iki sorunu önlemez.

Öte yandan, aynı ortamın birden fazla ilişkili kaynağını, farklı SSRC değerleri kullanarak tek bir RTP oturumunda çoklamak, çoklu gönderimli (multicast) oturumlar için yaygın bir uygulamadır. Yukarıda listelenen sorunlar bu durumda geçerli değildir: Örneğin bir RTP karıştırıcısı birden fazla ses kaynağını birleştirebilir ve aynı işlem hepsi için uygulanabilir. Son iki sorunun geçerli olmadığı diğer senaryolarda da, aynı ortamın akışlarını farklı SSRC değerleri kullanarak çoklamak uygun olabilir.

5.3 RTP Başlığına Profile Özgü Değişiklikler

Mevcut RTP veri paketi başlığının, RTP’nin destekleyebileceği tüm uygulama sınıfları arasında ortak olarak gereken işlevler kümesi için yeterli olduğu düşünülmektedir. Ancak ALF tasarım ilkesine uygun olarak, profil bağımsız izleme ve kayıt araçlarının çalışmasına hâlâ olanak tanırken, başlık bir profil belirtiminde tanımlanan değişiklikler veya eklemeler yoluyla uyarlanabilir.

  • İşaretleyici biti ve yük türü alanı profile özgü bilgi taşır; ancak birçok uygulamanın bunlara ihtiyaç duyması beklendiğinden ve aksi takdirde yalnızca bunları taşımak için başka bir 32 bitlik sözcük eklemek zorunda kalabileceklerinden, sabit başlıkta yer alırlar. Bu alanları içeren oktet, örneğin daha fazla veya daha az işaretleyici biti olacak şekilde, farklı gereksinimlere uyması için bir profil tarafından yeniden tanımlanabilir. Herhangi bir işaretleyici biti varsa, profil bağımsız izleyiciler paket kaybı örüntüleri ile işaretleyici biti arasında bir ilişki gözlemleyebileceğinden, bunlardan biri oktetin en anlamlı bitinde yer almalıdır.
  • Belirli bir yük biçimi için (örneğin bir video kodlaması) gerekli olan ek bilgiler, paketin yük bölümünde taşınmalıdır. Bu, yük bölümünün başında her zaman bulunan bir başlıkta yer alabilir ya da veri desenindeki ayrılmış bir değerle belirtilebilir.
  • Belirli bir uygulama sınıfı, yük biçiminden bağımsız ek işlevselliğe ihtiyaç duyuyorsa, bu uygulamaların çalıştığı profil, mevcut sabit başlığın SSRC alanından hemen sonra gelecek ek sabit alanları tanımlamalıdır. Bu uygulamalar ek alanlara hızlı ve doğrudan erişebilirken, profil bağımsız izleyiciler veya kaydediciler yalnızca ilk on iki okteti yorumlayarak RTP paketlerini işlemeye devam edebilir.

Eğer tüm profiller arasında ortak olarak ek işlevselliğe ihtiyaç duyulduğu ortaya çıkarsa, sabit başlıkta kalıcı bir değişiklik yapmak için RTP’nin yeni bir sürümü tanımlanmalıdır.

5.3.1 RTP Başlık Uzantısı

RTP veri paketi başlığında ek bilgilerin taşınmasını gerektiren, yük biçiminden bağımsız yeni işlevlerle bireysel uygulamaların denemeler yapmasına olanak tanımak için bir uzantı mekanizması sağlanmıştır. Bu mekanizma, uzatılmamış diğer birlikte çalışabilir uygulamalar tarafından başlık uzantısının yok sayılabilmesini sağlayacak şekilde tasarlanmıştır.

Bu başlık uzantısının yalnızca sınırlı kullanım için amaçlandığına dikkat edilmelidir. Bu mekanizmanın potansiyel kullanımlarının çoğu, önceki bölümde açıklanan yöntemler kullanılarak başka bir şekilde daha iyi gerçekleştirilebilir. Örneğin, sabit başlığa profile özgü bir uzantı, koşullu olmadığı ve değişken bir konumda bulunmadığı için işlenmesi daha az maliyetlidir. Belirli bir yük biçimi için gerekli olan ek bilgiler bu başlık uzantısını KULLANMAMALI, bunun yerine paketin yük bölümünde taşınmalıdır.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      profil tarafından tanımlanır      |           uzunluk            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        başlık uzantısı                         |
|                             ....                              |

RTP başlığındaki X biti bir ise, varsa CSRC listesini takiben RTP başlığına değişken uzunluklu bir başlık uzantısı EKLENMELİDİR. Başlık uzantısı, uzantıdaki 32 bitlik sözcüklerin sayısını sayan 16 bitlik bir uzunluk alanı içerir; dört oktetlik uzantı başlığı bu sayıya dahil değildir (dolayısıyla sıfır geçerli bir uzunluktur). RTP veri başlığına yalnızca tek bir uzantı eklenebilir. Birden fazla birlikte çalışabilir uygulamanın her birinin farklı başlık uzantılarıyla bağımsız olarak deneme yapabilmesine ya da belirli bir uygulamanın birden fazla başlık uzantısı türüyle deneme yapabilmesine olanak tanımak için, başlık uzantısının ilk 16 biti ayırt edici tanımlayıcılar veya parametreler için açık bırakılmıştır. Bu 16 bitin biçimi, uygulamaların çalıştığı profil belirtimi tarafından tanımlanacaktır. Bu RTP belirtimi, kendi başına herhangi bir başlık uzantısı tanımlamaz.

#6. RTP Kontrol Protokolü — RTCP

RTP kontrol protokolü (RTCP), oturumdaki tüm katılımcılara veri paketleriyle aynı dağıtım mekanizmasını kullanarak kontrol paketlerinin periyodik olarak iletilmesine dayanır. Altta yatan protokol, örneğin UDP ile ayrı port numaraları kullanarak, veri ve kontrol paketlerinin çoklanmasını SAĞLAMALIDIR. RTCP dört işlev yerine getirir:

  1. Birincil işlev, veri dağıtımının kalitesi hakkında geri bildirim sağlamaktır. Bu, RTP’nin bir taşıma protokolü olarak rolünün ayrılmaz bir parçasıdır ve diğer taşıma protokollerinin akış ve tıkanıklık denetimi işlevleriyle ilişkilidir (tıkanıklık denetimi gereksinimi için Bölüm 10’a bakınız). Geri bildirim, uyarlamalı kodlamaların denetimi için doğrudan yararlı olabilir [18,19]; ancak IP çok noktaya yayınla yapılan denemeler, dağıtımdaki hataların teşhis edilebilmesi için alıcılardan geri bildirim almanın da kritik olduğunu göstermiştir. Alım geri bildirim raporlarının tüm katılımcılara gönderilmesi, sorunları gözlemleyen birinin bu sorunların yerel mi yoksa genel mi olduğunu değerlendirmesine olanak tanır. IP çok noktaya yayın gibi bir dağıtım mekanizmasıyla, oturuma başka bir şekilde dahil olmayan bir ağ hizmet sağlayıcısı gibi bir varlığın da geri bildirim bilgilerini alması ve ağ sorunlarını teşhis etmek için üçüncü taraf bir izleyici olarak hareket etmesi mümkündür. Bu geri bildirim işlevi, aşağıda Bölüm 6.4’te açıklanan RTCP gönderici ve alıcı raporları tarafından yerine getirilir.
  2. RTCP, bir RTP kaynağı için kanonik ad veya CNAME olarak adlandırılan kalıcı bir taşıma katmanı tanımlayıcısı taşır (Bölüm 6.5.1). SSRC tanımlayıcısı bir çakışma tespit edildiğinde veya bir program yeniden başlatıldığında değişebileceğinden, alıcılar her katılımcıyı izlemek için CNAME’e ihtiyaç duyar. Alıcılar ayrıca, örneğin ses ve videoyu eşzamanlamak için, ilişkili RTP oturumları kümesinde belirli bir katılımcıdan gelen birden fazla veri akışını ilişkilendirmek amacıyla CNAME’e gereksinim duyabilir. Ortamlar arası eşzamanlama, veri göndericileri tarafından RTCP paketlerine dahil edilen NTP ve RTP zaman damgalarını da gerektirir.
  3. İlk iki işlev, tüm katılımcıların RTCP paketleri göndermesini gerektirir; bu nedenle, RTP’nin çok sayıda katılımcıya ölçeklenebilmesi için hızın denetlenmesi gerekir. Her katılımcının kontrol paketlerini diğerlerinin tümüne göndermesiyle, her biri katılımcı sayısını bağımsız olarak gözlemleyebilir. Bu sayı, Bölüm 6.2’de açıklandığı gibi paketlerin gönderilme hızını hesaplamak için kullanılır.
  4. Dördüncü ve İSTEĞE BAĞLI bir işlev, örneğin kullanıcı arayüzünde gösterilecek katılımcı kimliği gibi, asgari oturum denetim bilgilerini iletmektir. Bu, katılımcıların üyelik denetimi veya parametre müzakeresi olmaksızın girip çıktığı “gevşek denetimli” oturumlarda büyük olasılıkla yararlıdır. RTCP, tüm katılımcılara ulaşmak için elverişli bir kanal görevi görür; ancak bir uygulamanın tüm denetim iletişimi gereksinimlerini desteklemesi zorunlu olarak beklenmez. Bu belgenin kapsamı dışında kalan, daha üst düzey bir oturum denetim protokolüne ihtiyaç duyulabilir.

1–3 numaralı işlevler tüm ortamlarda, ancak özellikle IP çok noktaya yayın ortamında KULLANILMALIDIR. RTP uygulama tasarımcıları, yalnızca tekil gönderim (unicast) kipinde çalışabilen ve daha büyük sayılara ölçeklenemeyen mekanizmalardan KAÇINMALIDIR. RTCP iletimi, alıcıların geri bildirim sağlayamadığı tek yönlü bağlantılar gibi durumlar için, Bölüm 6.2’de açıklandığı üzere, göndericiler ve alıcılar için ayrı ayrı denetlenebilir.

Normatif olmayan not: Kaynağa Özgü Çok Noktaya Yayın (Source-Specific Multicast, SSM) olarak adlandırılan çok noktaya yayın yönlendirme yaklaşımında, her “kanal” (bir kaynak adresi, grup adresi çifti) için yalnızca bir gönderici vardır ve alıcılar (kanal kaynağı hariç) diğer kanal üyeleriyle doğrudan iletişim kurmak için çok noktaya yayını kullanamaz. Buradaki öneriler, alıcıların RTCP’sini tamamen kapatma seçeneği yoluyla yalnızca Bölüm 6.2 kapsamında SSM’yi karşılar. Gelecekteki çalışmalar, alıcılardan geri bildirimin sürdürülebilmesi için RTCP’nin SSM’ye uyarlanmasını belirleyecektir.

6.1 RTCP Paket Biçimi

Bu belirtim, çeşitli denetim bilgilerini taşımak üzere birkaç RTCP paket türü tanımlar:

  • SR: Aktif gönderici olan katılımcılardan iletim ve alım istatistikleri için gönderici raporu
  • RR: Aktif gönderici olmayan katılımcılardan alım istatistikleri için alıcı raporu ve 31’den fazla kaynak hakkında raporlayan aktif göndericiler için SR ile birlikte
  • SDES: CNAME dâhil olmak üzere kaynak tanımlama öğeleri
  • BYE: Katılımın sona erdiğini belirtir
  • APP: Uygulamaya özgü işlevler

Her RTCP paketi, RTP veri paketlerininkine benzer sabit bir bölümle başlar; bunu, paket türüne bağlı olarak değişken uzunlukta OLABİLEN, ancak MUTLAKA 32 bitlik bir sınırda sona ermesi gereken yapılandırılmış öğeler izler. Hizalama gereksinimi ve her paketin sabit bölümündeki bir uzunluk alanı, RTCP paketlerini “üst üste eklenebilir” hale getirmek için dahil edilmiştir. Birden fazla RTCP paketi, aralarında herhangi bir ayırıcı olmaksızın birleştirilerek, örneğin UDP gibi alt katman protokolünün tek bir paketinde gönderilen bileşik bir RTCP paketi oluşturulabilir. Alt katman protokollerinin, bileşik paketin sonunu belirlemek için genel bir uzunluk sağlaması beklendiğinden, bileşik paket içinde tek tek RTCP paketlerinin açık bir sayımı yoktur.

Bileşik paket içindeki her bir RTCP paketi, paketlerin sırası veya kombinasyonu hakkında herhangi bir gereksinim olmaksızın bağımsız olarak işlenebilir. Ancak protokolün işlevlerini yerine getirebilmesi için aşağıdaki kısıtlamalar getirilmiştir:

  • İstatistiklerin çözünürlüğünü en üst düzeye çıkarmak için, alım istatistikleri (SR veya RR içinde) bant genişliği kısıtlarının izin verdiği ölçüde sık gönderilmelidir; bu nedenle, periyodik olarak iletilen her bileşik RTCP paketi MUTLAKA bir rapor paketi içermelidir.
  • Yeni alıcıların, kaynağı tanımlamak ve dudak senkronizasyonu gibi amaçlarla ortamları ilişkilendirmeye başlamak için bir kaynağın CNAME’ini mümkün olan en kısa sürede alması gerekir; bu nedenle, Bölüm 9.1’de açıklandığı gibi kısmi şifreleme için bileşik RTCP paketi bölünmediği sürece, her bileşik RTCP paketi MUTLAKA SDES CNAME’i de içermelidir.
  • Bileşik pakette ilk sırada görünebilecek paket türlerinin sayısının sınırlandırılması, ilk sözcükteki sabit bitlerin sayısını ve yanlış adreslenmiş RTP veri paketlerine veya diğer ilgisiz paketlere karşı RTCP paketlerinin başarıyla doğrulanma olasılığını artırmak için gereklidir.

Dolayısıyla, tüm RTCP paketleri aşağıdaki biçimde, en az iki ayrı paketten oluşan bir bileşik paket içinde GÖNDERİLMELİDİR:

  • Şifreleme öneki: Bileşik paket yalnızca ve yalnızca Bölüm 9.1’deki yönteme göre şifrelenecekse, iletilen her bileşik paket için yeniden çekilen rastgele bir 32 bitlik değerle öneklenmesi GEREKİR. Şifreleme için dolgu gerekiyorsa, bu dolgu MUTLAKA bileşik paketin son paketine eklenmelidir.

#RTCP Bileşik Paket Gereksinimleri

SR veya RR: Bileşik paketteki ilk RTCP paketi, Ek A.2’de açıklandığı üzere başlık doğrulamasını kolaylaştırmak için her zaman bir rapor paketi **OLMALIDIR**. Hiç veri gönderilmemiş veya alınmamış olsa bile bu geçerlidir; bu durumda boş bir RR **GÖNDERİLMELİDİR** ve bileşik paketteki tek diğer RTCP paketi bir BYE olsa dahi bu kural uygulanır.

Ek RR’ler: Alım istatistikleri raporlanan kaynakların sayısı, tek bir SR veya RR paketine sığabilecek sayı olan 31’i aşıyorsa, ilk rapor paketini ek RR paketleri **İZLEMELİDİR**.

SDES: Bölüm 9.1’de belirtilen durumlar dışında, her bileşik RTCP paketine CNAME öğesi içeren bir SDES paketi **DAHİL EDİLMELİDİR**. Diğer kaynak tanımlama öğeleri, bant genişliği kısıtlarına tabi olarak (Bölüm 6.3.9’a bakınız), belirli bir uygulama tarafından gerekliyse isteğe bağlı olarak **DAHİL EDİLEBİLİR**.

BYE veya APP: Henüz tanımlanmamış olanlar dâhil diğer RTCP paket türleri, BYE’nin belirli bir SSRC/CSRC ile gönderilen son paket **OLMASI GEREKTİĞİ** durumu dışında, herhangi bir sırayla **İZLEYEBİLİR**. Paket türleri birden fazla kez **GÖRÜNEBİLİR**.

Bir RTP katılımcısı, Bölüm 6.2’de açıklandığı üzere katılımcı başına RTCP bant genişliğinin doğru tahmin edilebilmesi için, Bölüm 9.1’de açıklandığı gibi kısmi şifreleme için bileşik RTCP paketi bölünmediği sürece, her rapor aralığında yalnızca bir bileşik RTCP paketi GÖNDERMELİDİR. Gerekli tüm RR paketlerini, ağ yolunun maksimum iletim birimini (MTU) aşmadan tek bir bileşik RTCP paketine sığdırmak için çok fazla kaynak varsa, her aralıkta yalnızca bir MTU içine sığacak alt küme DAHİL EDİLMELİDİR. Alt kümeler, tüm kaynakların raporlanması için birden fazla aralık boyunca dairesel (round-robin) olarak SEÇİLMELİDİR.

Paket ek yükünü paylaştırmak için (Bölüm 7’ye bakınız), mümkün olduğunda, ilettikleri birden fazla kaynaktan gelen tekil RTCP paketlerini tek bir bileşik pakette birleştirmeleri çeviriciler ve karıştırıcılar için ÖNERİLİR. Bir karıştırıcı tarafından üretilebilecek örnek bir RTCP bileşik paketi Şekil 1’de gösterilmektedir. Bir bileşik paketin toplam uzunluğu ağ yolunun MTU’sunu aşacaksa, altta yatan protokolün ayrı paketlerinde iletilmek üzere birden fazla daha kısa bileşik pakete BÖLÜNMELİDİR. Bu durum RTCP bant genişliği tahminini bozmaz, çünkü her bileşik paket en az bir ayrı katılımcıyı temsil eder. Her bileşik paketin MUTLAKA bir SR veya RR paketiyle başlaması gerektiğine dikkat ediniz.

Bir uygulama, kendisi tarafından bilinmeyen türlere sahip gelen RTCP paketlerini YOK SAYMALIDIR. Ek RTCP paket türleri, Bölüm 15’te açıklandığı üzere Internet Assigned Numbers Authority (IANA) ile KAYDEDİLEBİLİR.

if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
|                receiver            chunk        chunk
V                reports           item  item   item  item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
|                                                                  |
|<-----------------------  compound packet ----------------------->|
|<--------------------------  UDP packet ------------------------->|

#: SSRC/CSRC identifier

Şekil 1: Bir RTCP bileşik paketi örneği

6.2 RTCP İletim Aralığı

RTP, bir uygulamanın birkaç katılımcıdan binlerce katılımcıya kadar değişen oturum boyutları üzerinde otomatik olarak ölçeklenmesine olanak tanıyacak şekilde tasarlanmıştır. Örneğin, bir sesli konferansta veri trafiği doğası gereği kendini sınırlar; çünkü aynı anda yalnızca bir veya iki kişi konuşur. Bu nedenle, çok noktaya yayın dağıtımıyla, herhangi bir bağlantı üzerindeki veri hızı katılımcı sayısından bağımsız olarak nispeten sabit kalır. Ancak denetim trafiği kendini sınırlamaz. Her katılımcıdan gelen alım raporları sabit bir hızda gönderilseydi, denetim trafiği katılımcı sayısıyla doğrusal olarak artardı. Bu nedenle hız, RTCP paket iletimleri arasındaki aralığın dinamik olarak hesaplanmasıyla düşürülmelidir.

Her oturum için, veri trafiğinin katılımcılar arasında paylaştırılacak olan ve “oturum bant genişliği” olarak adlandırılan toplam bir sınıra tabi olduğu varsayılır. Bu bant genişliği ayrılmış olabilir ve sınır ağ tarafından uygulanabilir. Rezervasyon yoksa, ortama bağlı olarak, oturumun kullanması için “makul” bir üst sınırı belirleyen başka kısıtlar bulunabilir; bu da oturum bant genişliği olur. Oturum bant genişliği, bir maliyete veya oturum için mevcut ağ bant genişliği hakkında önsel bilgiye dayanarak seçilebilir. Medya kodlamasından bir ölçüde bağımsızdır; ancak kodlama seçimi oturum bant genişliği tarafından sınırlandırılabilir. Çoğu zaman, oturum bant genişliği, eşzamanlı olarak etkin olması beklenen göndericilerin nominal bant genişliklerinin toplamıdır. Telekonferans sesi için bu değer genellikle tek bir göndericinin bant genişliği olur. Katmanlı kodlamalar için, her katman kendi oturum bant genişliği parametresine sahip ayrı bir RTP oturumudur.

Oturum bant genişliği parametresinin, bir ortam uygulamasını çağırdığında bir oturum yönetim uygulaması tarafından sağlanması beklenir; ancak ortam uygulamaları, oturum için seçilen kodlamanın tek göndericili veri bant genişliğine dayalı bir varsayılan değer BELİRLEYEBİLİR. Uygulama ayrıca, çok noktaya yayın kapsam kuralları veya diğer ölçütlere dayalı olarak bant genişliği sınırlarını UYGULAYABİLİR. Aynı RTCP aralığının hesaplanabilmesi için tüm katılımcılar oturum bant genişliği için aynı değeri KULLANMALIDIR.

Denetim ve veri trafiği için bant genişliği hesaplamaları, kaynak rezervasyon sisteminin bilmesi gereken şey bu olduğundan, alt katman taşıma ve ağ protokollerini (örneğin UDP ve IP) içerir. Uygulamanın, bu protokollerden hangilerinin kullanımda olduğunu da bilmesi beklenir. Paket, yol boyunca farklı bağlantı düzeyi başlıklarıyla kapsülleneceğinden, bağlantı düzeyi başlıkları hesaplamaya dahil edilmez.

Kontrol trafiği, oturum bant genişliğinin küçük ve bilinen bir kesriyle sınırlandırılmalıdır: küçük olmalıdır ki taşıma protokolünün temel işlevi olan veri taşıma bozulmasın; bilinen olmalıdır ki kontrol trafiği, bir kaynak rezervasyon protokolüne verilen bant genişliği tanımına dâhil edilebilsin ve her katılımcı kendi payını bağımsız olarak hesaplayabilsin. Kontrol trafiği bant genişliği, veri trafiği için olan oturum bant genişliğine eklenir. RTCP için eklenen oturum bant genişliği oranının %5 olarak sabitlenmesi TAVSİYE EDİLİR. Ayrıca, RTCP bant genişliğinin 1/4’ünün veri gönderen katılımcılara ayrılması da TAVSİYE EDİLİR; böylece çok sayıda alıcının ancak az sayıda göndericinin bulunduğu oturumlarda, yeni katılan katılımcılar gönderim yapan sitelerin CNAME bilgisini daha hızlı alır. Göndericilerin oranı katılımcıların 1/4’ünden büyük olduğunda, göndericiler tam RTCP bant genişliğindeki kendi oranlarını alırlar. Aralık hesaplamasında bu ve diğer sabitlerin değerleri kritik olmamakla birlikte, aynı aralığın hesaplanabilmesi için oturumdaki tüm katılımcıların aynı değerleri KULLANMASI GEREKİR. Bu nedenle, bu sabitler belirli bir profil için SABİTLENMELİDİR.

Bir profil, kontrol trafiği bant genişliğinin oturum bant genişliğinin katı bir yüzdesi yerine, oturumun ayrı bir parametresi olabileceğini BELİRTEBİLİR. Ayrı bir parametre kullanılması, hız uyarlamalı uygulamaların, oturum bant genişliği parametresi tarafından belirtilen azami bant genişliğinden daha düşük olan “tipik” bir veri bant genişliğiyle tutarlı bir RTCP bant genişliği ayarlamasına olanak tanır.

Profil ayrıca, kontrol trafiği bant genişliğinin, aktif veri gönderen katılımcılar ile göndermeyenler için iki ayrı oturum parametresine bölünebileceğini BELİRTEBİLİR; bu parametrelere S ve R diyelim. RTCP bant genişliğinin 1/4’ünün veri gönderenlere ayrılması yönündeki tavsiyeyi izleyerek, bu iki parametre için TAVSİYE EDİLEN varsayılan değerler sırasıyla %1,25 ve %3,75 olur. Göndericilerin oranı katılımcıların S/(S+R) değerinden büyük olduğunda, göndericiler bu parametrelerin toplamındaki kendi oranlarını alırlar. İki parametre kullanılması, belirli bir oturum için RTCP alım raporlarının tamamen kapatılmasına olanak tanır; bunun için veri göndermeyenler için RTCP bant genişliği sıfıra ayarlanırken, veri gönderenler için RTCP bant genişliği sıfırdan farklı tutulur; böylece ortamlar arası senkronizasyon için gönderici raporları hâlâ gönderilebilir. RTCP alım raporlarının kapatılması TAVSİYE EDİLMEZ; çünkü Bölüm 6’nın başında listelenen işlevler, özellikle alım kalitesi geri bildirimi ve tıkanıklık denetimi için gereklidirler. Bununla birlikte, tek yönlü bağlantılar üzerinde çalışan sistemler veya alım kalitesi ya da alıcıların canlılığı hakkında geri bildirim gerektirmeyen ve tıkanıklığı önlemek için başka araçlara sahip oturumlar için uygun olabilir.

Bileşik RTCP paketlerinin gönderimleri arasındaki hesaplanan aralığın, katılımcı sayısı az olduğunda ve trafik büyük sayılar yasasına göre yumuşatılmadığında paket patlamalarının izin verilen bant genişliğini aşmasını önlemek için bir alt sınıra da sahip OLMASI GEREKİR. Ayrıca, ağ bölünmesi gibi geçici kesintiler sırasında rapor aralığının aşırı küçülmesini engeller; böylece bölünme düzeldiğinde uyarlama gecikmez. Uygulama başlatıldığında, ilk bileşik RTCP paketi gönderilmeden önce bir gecikme UYGULANMALIDIR; bu, diğer katılımcılardan RTCP paketlerinin alınmasına zaman tanır ve rapor aralığının doğru değere daha hızlı yakınsamasını sağlar. Bu gecikme, yeni katılımcının varlığının daha hızlı bildirilebilmesi için asgari aralığın yarısı olarak AYARLANABİLİR. Sabit bir asgari aralık için TAVSİYE EDİLEN değer 5 saniyedir.

Bir uygulama, aşağıdaki sınırlamalarla, asgari RTCP aralığını oturum bant genişliği parametresiyle ters orantılı olarak daha küçük bir değere ölçeklendirebilir:

  • Çok noktaya yayın (multicast) oturumları için, yalnızca aktif veri gönderenler, bileşik RTCP paketlerinin iletim aralığını hesaplamakta azaltılmış asgari değeri KULLANABİLİR.
  • Tekil yayın (unicast) oturumları için, aktif veri gönderen olmayan katılımcılar da azaltılmış değeri KULLANABİLİR ve ilk bileşik RTCP paketinin gönderilmesinden önceki gecikme sıfır OLABİLİR.
  • Tüm oturumlar için, katılımcı zaman aşımı aralığı hesaplanırken (Bkz. Bölüm 6.3.5) sabit asgari değer KULLANILMALIDIR; böylece RTCP paketlerini iletmek için azaltılmış değeri kullanmayan uygulamalar, diğer katılımcılar tarafından erken zaman aşımına uğratılmaz.
  • Saniye cinsinden azaltılmış asgari değer için TAVSİYE EDİLEN değer, 360’ın kilobit/saniye cinsinden oturum bant genişliğine bölünmesidir. Bu asgari değer, bant genişliği 72 kb/s’den büyük olduğunda 5 saniyeden küçüktür.

Bölüm 6.3 ve Ek A.7’de tanımlanan algoritma, bu bölümde belirtilen hedefleri karşılamak üzere tasarlanmıştır. İzin verilen kontrol trafiği bant genişliğini katılımcılar arasında paylaştırmak için, bileşik RTCP paketlerinin gönderimi arasındaki aralığı hesaplar. Bu, örneğin tüm katılımcıların tanımlanmasının önemli olduğu küçük oturumlar için bir uygulamanın hızlı yanıt sağlamasına olanak tanırken, aynı zamanda büyük oturumlara otomatik olarak uyum sağlar. Algoritma aşağıdaki özellikleri içerir:

  • RTCP paketleri arasındaki hesaplanan aralık, gruptaki üye sayısıyla doğrusal olarak ölçeklenir. Tüm üyeler üzerinden toplandığında sabit miktarda kontrol trafiğine olanak tanıyan doğrusal faktör budur.
  • RTCP paketleri arasındaki aralık, tüm katılımcıların istenmeyen şekilde senkronize olmasını önlemek için, hesaplanan aralığın [0,5, 1,5] katı aralığında rastgele olarak değiştirilir [20]. Bir oturuma katıldıktan sonra gönderilen ilk RTCP paketi de asgari RTCP aralığının yarısı kadar rastgele bir değişimle geciktirilir.
  • Taşınan kontrol bilgisi miktarındaki değişikliklere otomatik olarak uyum sağlamak için, alınan ve gönderilen tüm paketler dâhil edilerek ortalama bileşik RTCP paketi boyutunun dinamik bir tahmini hesaplanır.
  • Hesaplanan aralık, gözlemlenen grup üye sayısına bağlı olduğundan, yeni bir kullanıcı mevcut bir oturuma katıldığında veya birçok kullanıcı aynı anda yeni bir oturuma katıldığında istenmeyen başlangıç etkileri oluşabilir. Bu yeni kullanıcılar başlangıçta grup üyeliği hakkında hatalı tahminlere sahip olacak ve dolayısıyla RTCP iletim aralıkları çok kısa olacaktır. Birçok kullanıcının aynı anda oturuma katılması durumunda bu sorun önemli olabilir. Bununla başa çıkmak için “zamanlayıcı yeniden değerlendirme” adlı bir algoritma kullanılır. Bu algoritma, grup boyutları artarken kullanıcıların RTCP paketi iletimini geri tutmasına neden olan basit bir geri çekilme mekanizması uygular.
  • Kullanıcılar bir oturumdan, ister bir BYE ile ister zaman aşımıyla ayrılsın, grup üyeliği azalır ve dolayısıyla hesaplanan aralığın da azalması gerekir. Grup üyeliği azalışlarına yanıt olarak üyelerin aralıklarını daha hızlı azaltmalarına olanak tanımak için “ters yeniden değerlendirme” algoritması kullanılır.
  • BYE paketlerine, diğer RTCP paketlerinden farklı bir işlem uygulanır. Bir kullanıcı bir gruptan ayrıldığında ve bir BYE paketi göndermek istediğinde, bunu bir sonraki planlanmış RTCP paketinden önce yapabilir. Ancak, çok sayıda üyenin aynı anda oturumdan ayrılması durumunda BYE paketlerinin taşmasına yol açmamak için, BYE iletimi bir geri çekilme algoritmasını izler.

Bu algoritma, tüm katılımcıların gönderim yapmasına izin verilen oturumlar için kullanılabilir. Bu durumda, oturum bant genişliği parametresi, bireysel göndericinin bant genişliğinin katılımcı sayısıyla çarpımıdır ve RTCP bant genişliği bunun %5’idir.

Algoritmanın işleyişine ilişkin ayrıntılar izleyen bölümlerde verilmiştir. Ek A.7 bir örnek uygulama sunar.

6.2.1 Oturum Üye Sayısının Sürdürülmesi

RTCP paket aralığının hesaplanması, oturuma katılan site sayısının bir tahminine bağlıdır. Yeni siteler duyulduklarında sayıya eklenir ve her biri için, bunları izlemek amacıyla SSRC veya CSRC tanımlayıcısına göre indekslenmiş bir tabloda bir giriş OLUŞTURULMALIDIR (Bkz. Bölüm 8.2). Yeni girişler, yeni SSRC’yi taşıyan birden fazla paket alınana kadar (Bkz. Ek A.1) veya bu SSRC için bir CNAME içeren bir SDES RTCP paketi alınana kadar geçerli kabul edilmeyebilir. Karşılık gelen SSRC tanımlayıcısına sahip bir RTCP BYE paketi alındığında girişler tablodan SİLİNEBİLİR; ancak BYE’den sonra bazı gecikmiş veri paketleri gelebilir ve giriş yeniden oluşturulabilir. Bunun yerine, giriş BYE almış olarak işaretlenmeli ve uygun bir gecikmeden sonra silinmelidir.

Bir katılımcı, küçük sayıda RTCP rapor aralığı (5 TAVSİYE EDİLİR) boyunca hiçbir RTP veya RTCP paketi alınmamışsa, başka bir siteyi etkin olmayan olarak işaretleyebilir veya henüz geçerli değilse silebilir. Bu, paket kaybına karşı bir miktar dayanıklılık sağlar. Bu zaman aşımının düzgün çalışabilmesi için, tüm siteler bu çarpan için aynı değere sahip olmalı ve RTCP rapor aralığı için yaklaşık olarak aynı değeri hesaplamalıdır. Bu nedenle, bu çarpan belirli bir profil için SABİTLENMELİDİR.

Çok sayıda katılımcının bulunduğu oturumlar için, hepsi adına SSRC tanımlayıcısı ve durum bilgisini saklamak üzere bir tablo tutmak pratik olmayabilir. Bir uygulama, depolama gereksinimlerini azaltmak için [21]’de tanımlandığı gibi SSRC örneklemesi KULLANABİLİR. Benzer performansa sahip başka herhangi bir algoritma da KULLANABİLİR. Temel bir gereksinim, değerlendirilen herhangi bir algoritmanın grup boyutunu önemli ölçüde eksik tahmin ETMEMESİ gerektiğidir; ancak fazla tahmin edebilir.

6.3 RTCP Paketi Gönderme ve Alma Kuralları

Bir RTCP paketi gönderirken nasıl davranılacağı ve alındığında ne yapılacağına ilişkin kurallar burada özetlenmiştir. Çok noktaya yayın ortamında veya çok noktalı tekil yayın ortamında çalışmaya izin veren bir uygulama, Bölüm 6.2’deki gereksinimleri KARŞILAMAK ZORUNDADIR. Böyle bir uygulama, bu gereksinimleri karşılamak için bu bölümde tanımlanan algoritmayı KULLANABİLİR veya eşdeğer ya da daha iyi performans sağlayan başka bir algoritma KULLANABİLİR. Yalnızca iki taraflı tekil yayın çalışmasıyla sınırlı bir uygulama, aynı ortamda çalışan birden fazla örneğin istenmeyen şekilde senkronize olmasını önlemek için RTCP iletim aralığının rastgeleleştirilmesini yine de KULLANMALIDIR; ancak Bölüm 6.3.3, 6.3.6 ve 6.3.7’deki “zamanlayıcı yeniden değerlendirme” ve “ters yeniden değerlendirme” algoritmalarını atlayabilir.

Bu kuralları uygulamak için, bir oturum katılımcısının birkaç durum bilgisini tutması gerekir:

  • tp: bir RTCP paketinin en son iletildiği zaman;
  • tc: geçerli zaman;
  • tn: bir RTCP paketinin bir sonraki planlanan iletim zamanı;
  • pmembers: tn en son yeniden hesaplandığı zamandaki tahmini oturum üye sayısı;
  • members: oturum üye sayısı için en güncel tahmin;
  • senders: oturumdaki gönderici sayısı için en güncel tahmin;
  • rtcp_bw: hedef RTCP bant genişliği; yani bu oturumun tüm üyeleri tarafından RTCP paketleri için kullanılacak toplam bant genişliği (saniye başına sekizli). Bu değer, uygulamaya başlatma sırasında sağlanan “oturum bant genişliği” parametresinin belirli bir kesri olacaktır;
  • we_sent: uygulamanın, bir önceki RTCP raporundan önceki ikinci RTCP raporu gönderildikten sonra veri gönderip göndermediğini belirten ve doğru olduğunda true olan bayrak;
  • avg_rtcp_size: bu katılımcı tarafından gönderilen ve alınan tüm RTCP paketleri üzerinden, sekizli cinsinden ortalama bileşik RTCP paketi boyutu. Boyut, Bölüm 6.2’de açıklandığı üzere alt katman taşıma ve ağ protokolü başlıklarını (ör. UDP ve IP) içerir;
  • initial: uygulamanın henüz bir RTCP paketi göndermediğini belirten ve doğru olduğunda true olan bayrak.

Bu kuralların birçoğu, paket iletimleri arasındaki “hesaplanan aralığı” kullanır. Bu aralık bir sonraki bölümde açıklanmaktadır.

6.3.1 RTCP İletim Aralığının Hesaplanması

Ölçeklenebilirliği korumak için, bir oturum katılımcısından gelen paketler arasındaki ortalama aralık grup boyutuyla ölçeklenmelidir. Bu aralığa hesaplanan aralık denir. Yukarıda açıklanan durum bilgilerinin bir kısmı birleştirilerek elde edilir. Hesaplanan aralık T aşağıdaki şekilde belirlenir:

  1. Gönderici sayısı üyeliğin (members) %25’inden küçük ya da ona eşitse, aralık katılımcının gönderici olup olmamasına bağlıdır (we_sent değerine göre).
  • Katılımcı bir göndericiyse (we_sent true), sabit C, ortalama RTCP paketi boyutunun (avg_rtcp_size), RTCP bant genişliğinin (rtcp_bw) %25’ine bölünmesiyle ayarlanır ve sabit n gönderici sayısına ayarlanır.
  • we_sent true değilse, sabit C, ortalama RTCP paketi boyutunun RTCP bant genişliğinin %75’ine bölünmesiyle ayarlanır. Sabit n, alıcı sayısına (members - senders) ayarlanır.

Gönderici sayısı %25’ten büyükse, göndericiler ve alıcılar birlikte ele alınır. Sabit C, ortalama RTCP paketi boyutunun toplam RTCP bant genişliğine bölünmesiyle ayarlanır ve n toplam üye sayısına ayarlanır.

Bölüm 6.2’de belirtildiği gibi, bir RTP profili, RTCP bant genişliğinin, gönderici olan ve olmayan katılımcılar için iki ayrı parametre (S ve R) ile açıkça tanımlanabileceğini BELİRTEBİLİR. Bu durumda %25 kesri S/(S+R) olur ve %75 kesri R/(S+R) olur. R sıfırsa, göndericilerin yüzdesi hiçbir zaman S/(S+R) değerinden büyük olmaz ve uygulama sıfıra bölmeden kaçınmak zorundadır.

  1. Katılımcı henüz bir RTCP paketi göndermemişse (initial değişkeni true ise), sabit Tmin 2,5 saniye olarak ayarlanır; aksi halde 5 saniye olarak ayarlanır.
  2. Deterministik hesaplanan aralık Td, max(Tmin, n·C) olarak ayarlanır.
  3. Hesaplanan aralık T, deterministik hesaplanan aralığın 0,5 ile 1,5 katı arasında eşit dağılımlı bir sayı olarak ayarlanır.
  4. Elde edilen T değeri, zamanlayıcı yeniden değerlendirme algoritmasının RTCP bant genişliğinin amaçlanan ortalamanın altında bir değere yakınsaması gerçeğini telafi etmek için \(e^{-3/2} = 1,21828\) sayısına bölünür.

Bu yordam, rastgele bir aralık üretir; ancak ortalama olarak RTCP bant genişliğinin en az %25’ini göndericilere, geri kalanını alıcılara verir. Göndericiler üyeliğin dörtte birinden fazlasını oluşturuyorsa, bu yordam bant genişliğini ortalama olarak tüm katılımcılar arasında eşit olarak böler.

6.3.2 Başlatma

Oturuma katıldığında, katılımcı tp’yi 0’a, tc’yi 0’a, senders’ı 0’a, pmembers’ı 1’e, members’ı 1’e, we_sent’i false’a, rtcp_bw’yi oturum bant genişliğinin belirtilen kesrine, initial’ı true’a ve avg_rtcp_size’ı uygulamanın daha sonra oluşturacağı ilk RTCP paketinin olası boyutuna ayarlar. Ardından hesaplanan aralık T hesaplanır ve ilk paket tn = T zamanı için planlanır. Bu, T zamanında sona erecek bir iletim zamanlayıcısının ayarlandığı anlamına gelir. Bir uygulamanın bu zamanlayıcıyı uygulamak için istediği herhangi bir yaklaşımı KULLANABİLECEĞİNE dikkat edin.

Katılımcı, kendi SSRC’sini üye tablosuna ekler.

6.3.3 Bir RTP veya BYE Olmayan RTCP Paketinin Alınması

Üye tablosunda SSRC’si bulunmayan bir katılımcıdan bir RTP veya RTCP paketi alındığında, SSRC tabloya eklenir ve Bölüm 6.2.1’de açıklandığı şekilde katılımcı doğrulandıktan sonra members değeri güncellenir. Doğrulanmış bir RTP paketindeki her bir CSRC için de aynı işlem gerçekleştirilir.

Gönderici tablosunda SSRC’si bulunmayan bir katılımcıdan bir RTP paketi alındığında, SSRC tabloya eklenir ve senders değeri güncellenir.

Alınan her bir bileşik RTCP paketi için avg_rtcp_size değeri güncellenir:

avg_rtcp_size = (1/16) · packet_size + (15/16) · avg_rtcp_size

burada packet_size, az önce alınan RTCP paketinin boyutudur.

6.3.4 Bir RTCP BYE Paketinin Alınması

RTCP BYE’nin gönderileceği durum için Bölüm 6.3.7’de açıklananlar dışında, alınan paket bir RTCP BYE paketi ise, SSRC üye tablosuna karşı kontrol edilir. Mevcutsa, giriş tablodan kaldırılır ve members değeri güncellenir. Daha sonra SSRC gönderici tablosuna karşı kontrol edilir. Mevcutsa, giriş tablodan kaldırılır ve senders değeri güncellenir.

Ayrıca, RTCP paketlerinin iletim hızını grup üyeliğindeki değişikliklere daha uyarlanabilir hâle getirmek için, members değerini pmembers’tan daha küçük bir değere düşüren bir BYE paketi alındığında aşağıdaki ters yeniden değerlendirme algoritması ÇALIŞTIRILMALIDIR:

  • tn değeri aşağıdaki formüle göre güncellenir:

    > tn = tc + (members/pmembers) · (tn − tc)

  • tp değeri aşağıdaki formüle göre güncellenir:

    > tp = tc − (members/pmembers) · (tc − tp)

  • Bir sonraki RTCP paketi, artık daha erken olan tn zamanında iletilmek üzere yeniden zamanlanır.
  • pmembers değeri members değerine eşitlenir.

Bu algoritma, büyük bir oturumdaki katılımcıların çoğu aynı anda ayrıldığında ancak bazıları kaldığında, erken zaman aşımları nedeniyle grup boyutu tahmininin kısa bir süre için hatalı biçimde sıfıra düşmesini engellemez. Bununla birlikte algoritma, tahminin doğru değere daha hızlı dönmesini sağlar. Bu durum yeterince nadirdir ve sonuçları yeterince zararsızdır; bu nedenle bu sorun yalnızca ikincil bir endişe olarak değerlendirilir.

6.3.5 Bir SSRC’nin Zaman Aşımına Uğraması

Zaman zaman, katılımcı diğer katılımcılardan herhangi birinin zaman aşımına uğrayıp uğramadığını kontrol ETMELİDİR. Bunu yapmak için katılımcı, bir alıcı için (rastgeleleştirme faktörü olmadan) deterministik olarak hesaplanan Td aralığını, yani we_sent false iken hesaplanan değeri belirler. tc − M·Td zamanından beri bir RTP veya RTCP paketi göndermemiş olan diğer herhangi bir oturum üyesi zaman aşımına uğramış kabul edilir (M zaman aşımı çarpanıdır ve varsayılan değeri 5’tir). Bu, ilgili SSRC’nin üye listesinden çıkarılması ve members değerinin güncellenmesi anlamına gelir.

Benzer bir kontrol gönderici listesi üzerinde gerçekleştirilir. Gönderici listesinde bulunan ve tc − 2T zamanından beri (son iki RTCP rapor aralığı içinde) bir RTP paketi göndermemiş olan herhangi bir üye gönderici listesinden çıkarılır ve senders değeri güncellenir.

Herhangi bir üye zaman aşımına uğrarsa, Bölüm 6.3.4’te açıklanan ters yeniden değerlendirme algoritması UYGULANMALIDIR.

Katılımcı bu kontrolü her RTCP iletim aralığında en az bir kez YAPMALIDIR.

6.3.6 İletim Zamanlayıcısının Sona Ermesi

Paket iletim zamanlayıcısının süresi dolduğunda, katılımcı aşağıdaki işlemleri gerçekleştirir:

  • T iletim aralığı, rastgeleleştirme faktörü dâhil olmak üzere, Bölüm 6.3.1’de açıklandığı şekilde hesaplanır.

  • Eğer tp + T ≤ tc ise, bir RTCP paketi iletilir. tp, tc değerine ayarlanır; ardından önceki adımda olduğu gibi T için yeni bir değer hesaplanır ve tn, tc + T olarak ayarlanır. İletim zamanlayıcısı tn zamanında tekrar sona erecek şekilde ayarlanır.

    Eğer tp + T > tc ise, tn, tp + T olarak ayarlanır. Hiçbir RTCP paketi iletilmez. İletim zamanlayıcısı tn zamanında sona erecek şekilde ayarlanır.

  • pmembers, members değerine ayarlanır.

Bir RTCP paketi iletilmişse, initial değeri false olarak ayarlanır. Ayrıca avg_rtcp_size değeri güncellenir:

avg_rtcp_size = (1/16) · packet_size + (15/16) · avg_rtcp_size

burada packet_size, az önce iletilen RTCP paketinin boyutudur.

6.3.7 Bir BYE Paketinin Gönderilmesi

Bir katılımcı bir oturumdan ayrılmak istediğinde, olayı diğer katılımcılara bildirmek için bir BYE paketi iletilir. Birçok katılımcının sistemden ayrıldığı durumlarda BYE paketlerinin taşmasına yol açmamak için, katılımcı ayrılmayı seçtiği anda members sayısı 50’den fazlaysa aşağıdaki algoritmayı ÇALIŞTIRMALIDIR. Bu algoritma, members değişkeninin normal rolünü geçersiz kılarak BYE paketlerini saymak için kullanır:

  • Katılımcı sistemden ayrılmaya karar verdiğinde, tp mevcut zaman olan tc’ye sıfırlanır; members ve pmembers 1 olarak başlatılır; initial 1 olarak ayarlanır; we_sent false olarak ayarlanır; senders 0 olarak ayarlanır; ve avg_rtcp_size, bileşik BYE paketinin boyutuna ayarlanır. Hesaplanan T aralığı belirlenir. BYE paketi daha sonra tn = tc + T zamanına planlanır.
  • Başka bir katılımcıdan bir BYE paketi her alındığında, söz konusu katılımcının üye tablosunda bulunup bulunmadığına bakılmaksızın ve SSRC örneklemesi kullanıldığında, BYE SSRC’sinin örneğe dâhil edilip edilmeyeceğine bakılmaksızın members 1 artırılır. Diğer RTCP paketleri veya RTP paketleri alındığında members artırılmaz; yalnızca BYE paketleri için artırılır. Benzer şekilde, avg_rtcp_size yalnızca alınan BYE paketleri için güncellenir. RTP paketleri geldiğinde senders güncellenmez; 0 olarak kalır.
  • BYE paketinin iletimi daha sonra, yukarıda açıklandığı gibi, normal bir RTCP paketinin iletim kurallarını izler.

Bu yaklaşım, BYE paketlerinin hemen gönderilmesine olanak tanırken toplam bant genişliği kullanımını kontrol eder. En kötü durumda bu, RTCP kontrol paketlerinin normalin iki katı bant genişliği kullanmasına (%%10) yol açabilir — BYE olmayan RTCP paketleri için %%5 ve BYE için %%5.

Yukarıdaki mekanizmanın bir BYE paketinin iletimine izin vermesini beklemek istemeyen bir katılımcı, hiç BYE göndermeden gruptan ayrılABİLİR. Bu katılımcı sonunda diğer grup üyeleri tarafından zaman aşımına uğratılacaktır.

Katılımcı ayrılmaya karar verdiğinde üye sayısı tahmini 50’den azsa, katılımcı bir BYE paketini hemen göndereBİLİR. Alternatif olarak, katılımcı yukarıdaki BYE geri çekilme algoritmasını uygulamayı seçeBİLİR.

Her iki durumda da, hiç RTP veya RTCP paketi göndermemiş olan bir katılımcı gruptan ayrılırken bir BYE paketi GÖNDERMEMELİDİR.

6.3.8 we_sent Değerinin Güncellenmesi

we_sent değişkeni, katılımcı yakın zamanda bir RTP paketi göndermişse true, aksi hâlde false değerini içerir. Bu belirleme, gönderici tablosunda listelenen diğer katılımcı kümesini yönetmek için kullanılan mekanizmaların aynısı kullanılarak yapılır. Katılımcı we_sent false iken bir RTP paketi gönderirse, kendisini gönderici tablosuna ekler ve we_sent değerini true olarak ayarlar. Bir SR paketinin gönderilmesinden önceki gecikmeyi olası şekilde azaltmak için, Bölüm 6.3.4’te açıklanan ters yeniden değerlendirme algoritması UYGULANMALIDIR. Gönderilen her yeni RTP paketi için, o paketin iletim zamanı tabloda tutulur. Daha sonra normal gönderici zaman aşımı algoritması katılımcıya uygulanır — tc − 2T zamanından beri bir RTP paketi iletilmemişse, katılımcı kendisini gönderici tablosundan çıkarır, gönderici sayısını azaltır ve we_sent değerini false olarak ayarlar.

6.3.9 Kaynak Tanımlama Bant Genişliğinin Tahsisi

Bu belirtim, zorunlu CNAME öğesine ek olarak NAME (kişisel ad) ve EMAIL (e-posta adresi) gibi çeşitli kaynak tanımlama (SDES) öğelerini tanımlar. Ayrıca yeni uygulamaya özgü RTCP paket türlerini tanımlamak için bir araç da sağlar. Uygulamalar, bu ek bilgilere kontrol bant genişliği tahsis ederken dikkatli olmalıdır; çünkü bu durum alım raporlarının ve CNAME’in gönderilme hızını yavaşlatacak ve dolayısıyla protokolün performansını olumsuz etkileyecektir. Tek bir katılımcıya tahsis edilen RTCP bant genişliğinin %%20’sinden fazlasının ek bilgileri taşımak için kullanılmaması ÖNERİLİR. Ayrıca, tüm SDES öğelerinin her uygulamada yer alması amaçlanmamıştır. Dâhil edilenler, faydalarına göre bant genişliğinin bir kısmını ALMALIDIR. Bu kesirleri dinamik olarak tahmin etmek yerine, yüzdelerin tipik bir öğenin uzunluğuna dayalı olarak rapor aralığı sayımlarına statik biçimde dönüştürülmesi önerilir.

Örneğin, bir uygulama yalnızca CNAME, NAME ve EMAIL gönderecek ve başka hiçbirini göndermeyecek şekilde tasarlanabilir. NAME, uygulamanın kullanıcı arayüzünde sürekli olarak gösterileceğinden, yalnızca istendiğinde gösterilen EMAIL’e kıyasla çok daha yüksek öncelik alabilir. Her RTCP aralığında bir RR paketi ve CNAME öğesini içeren bir SDES paketi gönderilir. En düşük aralıkta çalışan küçük bir oturum için bu, ortalama olarak her 5 saniyede bir olur. Her üçüncü aralıkta (15 saniye), SDES paketine bir ek öğe dâhil edilir. Sekiz seferden yedisinde bu NAME öğesi olurken, her sekizinci seferde (2 dakika) EMAIL öğesi olur.

Birden fazla uygulama, her katılımcı için ortak bir CNAME aracılığıyla uygulamalar arası bağlama kullanarak birlikte çalıştığında — örneğin her ortam için bir RTP oturumundan oluşan bir multimedya konferansında — ek SDES bilgileri yalnızca bir RTP oturumunda gönderileBİLİR. Diğer oturumlar yalnızca CNAME öğesini taşır. Özellikle bu yaklaşım, katmanlı bir kodlama şemasının birden fazla oturumu için uygulanmalıdır (bkz. Bölüm 2.4).

6.4 Gönderici ve Alıcı Raporları

RTP alıcıları, alım kalitesi geri bildirimini, alıcının aynı zamanda gönderici olup olmamasına bağlı olarak iki biçimden birini alabilen RTCP rapor paketleri kullanarak sağlar. Gönderici raporu (SR) ile alıcı raporu (RR) biçimleri arasındaki tek fark, paket türü koduna ek olarak, gönderici raporunun etkin göndericiler tarafından kullanılmak üzere 20 baytlık bir gönderici bilgi bölümü içermesidir. Bir site, son raporu veya bir önceki raporu yayınladığından bu yana geçen aralıkta herhangi bir veri paketi göndermişse SR yayınlanır; aksi hâlde RR yayınlanır.

Hem SR hem de RR biçimleri, bu alıcının son rapordan bu yana RTP veri paketleri aldığı her senkronizasyon kaynağı için birer tane olmak üzere sıfır veya daha fazla alım raporu bloğu içerir. CSRC listesinde yer alan katkı kaynakları için rapor yayınlanmaz. Her alım raporu bloğu, o blokta belirtilen belirli kaynaktan alınan verilerle ilgili istatistikler sağlar. Bir SR veya RR paketine en fazla 31 alım raporu bloğu sığabildiğinden, son rapordan bu yana duyulan tüm kaynaklara ait alım raporlarını içermek için gerektiğinde ilk SR veya RR paketinden sonra ek RR paketleri YIĞILMALIDIR. Ağ yolunun MTU’sunu aşmadan gerekli tüm RR paketlerini tek bir bileşik RTCP paketine sığdırmak için çok fazla kaynak varsa, her aralıkta yalnızca bir MTU’ya sığacak alt küme DÂHİL EDİLMELİDİR. Alt kümeler, tüm kaynaklar raporlanacak şekilde birden fazla aralık boyunca round-robin yöntemiyle seçilMELİDİR.

Sonraki bölümler, iki raporun biçimlerini, bir uygulama ek geri bildirim bilgisi gerektiriyorsa bunların profile özgü bir şekilde nasıl genişletilebileceğini ve raporların nasıl kullanılabileceğini tanımlar. Çeviriciler ve mikserler tarafından alım raporlamasının ayrıntıları Bölüm 7’de verilmiştir.

6.4.1 SR: Gönderici Raporu RTCP Paketi

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gönderici raporu paketi, tanımlanmışsa profile özgü dördüncü bir uzantı bölümüyle izlenebilen üç bölümden oluşur. İlk bölüm olan başlık 8 oktet uzunluğundadır. Alanların anlamı aşağıdaki gibidir:

sürüm (V): 2 bit RTP’nin sürümünü belirtir; bu sürüm RTCP paketlerinde, RTP veri paketlerinde olduğu gibidir. Bu belirtim tarafından tanımlanan sürüm iki (2)’dir.

doldurma (P): 1 bit Doldurma biti ayarlanmışsa, bu bireysel RTCP paketi, denetim bilgisinin bir parçası olmayan ancak uzunluk alanına dahil edilen ve sonda yer alan bazı ek doldurma sekizlilerini içerir. Doldurmanın son sekizlisi, kendisi de dahil olmak üzere yok sayılması gereken doldurma sekizlilerinin sayısını belirtir (dördün katı olacaktır). Sabit blok boyutlarına sahip bazı şifreleme algoritmaları için doldurma gerekebilir. Bileşik bir RTCP paketinde, Bölüm 9.1’deki yöntem için bileşik paket bir bütün olarak şifrelendiğinden, doldurma yalnızca tek bir bireysel paket üzerinde gereklidir. Bu nedenle, doldurma YALNIZCA son bireysel pakete eklenmelidir ve bu pakete doldurma eklenirse, doldurma biti YALNIZCA o paket üzerinde ayarlanmalıdır. Bu kural, Ek A.2’de açıklanan başlık geçerlilik denetimlerine yardımcı olur ve doldurma bitini yanlışlıkla ilk bireysel pakette ayarlayıp doldurmayı son bireysel pakete ekleyen bazı erken uygulamalardan gelen paketlerin tespit edilmesini sağlar.

alım raporu sayısı (RC): 5 bit Bu pakette yer alan alım raporu bloklarının sayısıdır. Sıfır değeri geçerlidir.

paket türü (PT): 8 bit Bunun bir RTCP SR paketi olduğunu tanımlamak için sabit 200 değerini içerir.

uzunluk: 16 bit Bu RTCP paketinin, başlık ve varsa doldurma dahil olmak üzere, 32 bitlik sözcükler cinsinden uzunluğu eksi birdir. (Bir ofseti, sıfırı geçerli bir uzunluk yapar ve bileşik bir RTCP paketini tararken olası bir sonsuz döngüyü önler; 32 bitlik sözcüklerin sayılması ise dördün katı olma için bir geçerlilik denetimini gereksiz kılar.)

SSRC: 32 bit Bu SR paketini gönderenin eşzamanlama kaynak tanımlayıcısıdır.

İkinci bölüm olan gönderici bilgisi 20 sekizli uzunluğundadır ve her gönderici raporu paketinde bulunur. Bu bölüm, bu göndericiden yapılan veri iletimlerini özetler. Alanların anlamları aşağıdaki gibidir:

NTP zaman damgası: 64 bit Bu raporun gönderildiği duvar saati zamanını (Bkz. Bölüm 4) gösterir; böylece, diğer alıcılardan gelen alım raporlarında döndürülen zaman damgalarıyla birlikte kullanılarak bu alıcılara olan gidiş-dönüş yayılım süresi ölçülebilir. Alıcılar, zaman damgasının ölçüm doğruluğunun NTP zaman damgasının çözünürlüğünden çok daha düşük olabileceğini beklemelidir. Zaman damgasının ölçüm belirsizliği belirtilmez; çünkü bu bilinmiyor olabilir. Duvar saati kavramı olmayan ancak “sistem çalışma süresi” gibi sisteme özgü bir saate sahip bir sistemde, gönderici bağıl NTP zaman damgalarını hesaplamak için bu saati bir referans olarak KULLANABİLİR. Çoklu ortam oturumunun bireysel akışlarını üretmek için ayrı uygulamalar kullanılıyorsa, tüm uygulamaların aynı saati kullanmasını sağlamak amacıyla yaygın olarak kullanılan bir saatin seçilmesi önemlidir. 2036 yılına kadar bağıl ve mutlak zaman damgaları en yüksek bitte farklılık göstereceğinden (geçersiz) karşılaştırmalar büyük bir fark gösterecektir; o zamana kadar bağıl zaman damgalarına artık ihtiyaç kalmaması umulmaktadır. Duvar saati veya geçen süre kavramı olmayan bir gönderici, NTP zaman damgasını sıfıra ayarlayabilir.

RTP zaman damgası: 32 bit Yukarıdaki NTP zaman damgası ile aynı zamana karşılık gelir, ancak veri paketlerindeki RTP zaman damgalarıyla aynı birimlerde ve aynı rastgele ofsetle ifade edilir. Bu eşleşme, NTP zaman damgaları eşzamanlanmış kaynaklar için ortam içi ve ortamlar arası eşzamanlama amacıyla kullanılabilir ve ortamdan bağımsız alıcılar tarafından nominal RTP saat frekansını tahmin etmek için kullanılabilir. Çoğu durumda bu zaman damgasının, bitişik herhangi bir veri paketindeki RTP zaman damgasına eşit olmayacağına dikkat edilmelidir. Bunun yerine, RTP zaman damgası sayacı ile gerçek zaman arasındaki ilişki, örnekleme anında duvar saati zamanının periyodik olarak kontrol edilmesiyle korunarak, karşılık gelen NTP zaman damgasından hesaplanması ZORUNLUDUR.

göndericinin paket sayısı: 32 bit Bu SR paketi oluşturulana kadar, iletimin başlangıcından itibaren gönderici tarafından iletilen toplam RTP veri paketi sayısıdır. Gönderici SSRC tanımlayıcısını değiştirirse, sayaç SIFIRLANMALIDIR.

göndericinin sekizli sayısı: 32 bit Bu SR paketi oluşturulana kadar, iletimin başlangıcından itibaren gönderici tarafından RTP veri paketlerinde iletilen toplam yük sekizlisi sayısıdır (yani başlık veya doldurma hariç). Gönderici SSRC tanımlayıcısını değiştirirse, sayaç SIFIRLANMALIDIR. Bu alan, ortalama yük veri hızını tahmin etmek için kullanılabilir.

Üçüncü bölüm, bu göndericinin son rapordan bu yana duyduğu diğer kaynakların sayısına bağlı olarak sıfır veya daha fazla alım raporu bloğu içerir. Her alım raporu bloğu, tek bir eşzamanlama kaynağından gelen RTP paketlerinin alımına ilişkin istatistikleri iletir. Alıcılar, bir çarpışma nedeniyle bir kaynak SSRC tanımlayıcısını değiştirdiğinde istatistikleri DEVAM ETTİRMEMELİDİR. Bu istatistikler şunlardır:

SSRC_n (kaynak tanımlayıcı): 32 bit Bu alım raporu bloğundaki bilgilerin ait olduğu kaynağın SSRC tanımlayıcısıdır.

kayıp oranı: 8 bit

SSRC_n kaynağından gelen RTP veri paketlerinin, önceki SR veya RR paketinin gönderilmesinden bu yana kaybolan kısmıdır; alanın sol kenarında ikili nokta bulunan sabit noktalı bir sayı olarak ifade edilir. (Bu, kayıp oranının 256 ile çarpılmasından sonra tam sayı kısmının alınmasına eşdeğerdir.) Bu oran, bir sonraki paragrafta tanımlandığı üzere, kaybolan paket sayısının beklenen paket sayısına bölünmesiyle tanımlanır. Bir uygulama Ek A.3’te gösterilmiştir. Yinelenen paketler nedeniyle kayıp negatifse, kayıp oranı sıfıra ayarlanır. Bir alıcının, aldığı son paketten sonra herhangi bir paketin kaybolup kaybolmadığını bilemeyeceğine ve son raporlama aralığında bu kaynaktan gönderilen tüm paketler kaybolmuşsa o kaynak için herhangi bir alım raporu bloğu oluşturulmayacağına dikkat edilmelidir.

kümülatif kaybolan paket sayısı: 24 bit

Alımın başlangıcından bu yana SSRC_n kaynağından kaybolmuş olan toplam RTP veri paketi sayısıdır. Bu sayı, beklenen paket sayısından fiilen alınan paket sayısının çıkarılmasıyla tanımlanır; fiilen alınan paket sayısına geç gelen veya yinelenen paketler de dahildir. Dolayısıyla geç gelen paketler kayıp olarak sayılmaz ve yinelenmeler varsa kayıp negatif olabilir. Beklenen paket sayısı, aşağıda tanımlandığı üzere, alınan genişletilmiş son sıra numarasından alınan ilk sıra numarasının çıkarılmasıyla tanımlanır. Bu, Ek A.3’te gösterildiği şekilde hesaplanabilir.

alınan en yüksek genişletilmiş sıra numarası: 32 bit

Alt 16 bit, SSRC_n kaynağından gelen bir RTP veri paketinde alınan en yüksek sıra numarasını içerir; en anlamlı 16 bit ise, Ek A.1’deki algoritmaya göre tutulabilen karşılık gelen sıra numarası çevrim sayısıyla bu sıra numarasını genişletir. Aynı oturum içindeki farklı alıcıların, başlangıç zamanları önemli ölçüde farklıysa, sıra numarasına farklı genişletmeler üreteceğine dikkat edilmelidir.

varışlar arası titreşim: 32 bit

RTP veri paketlerinin varışlar arası zamanının istatistiksel varyansına ilişkin bir tahmindir; zaman damgası birimleriyle ölçülür ve işaretsiz bir tamsayı olarak ifade edilir. Varışlar arası titreşim J, iki paket için alıcıda, göndericiye kıyasla paket aralığındaki fark D’nin ortalama sapması (yumuşatılmış mutlak değeri) olarak tanımlanır. Aşağıdaki denklemde gösterildiği gibi, bu, iki paket için “bağıl geçiş süresi” farkına eşdeğerdir.

Bağıl geçiş süresi, bir paketin RTP zaman damgası ile alıcıya varış anındaki alıcı saati arasındaki farktır ve aynı birimlerle ölçülür.

Si paket i’den gelen RTP zaman damgası ve Ri paket i’nin RTP zaman damgası birimleri cinsinden varış zamanı olmak üzere, iki paket i ve j için D şu şekilde ifade edilebilir:

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

Varışlar arası titreşim, SSRC_n kaynağından gelen her veri paketi i alındıkça, bu paket ile varış sırasına göre (mutlaka sıra numarasına göre değil) bir önceki paket i−1 arasındaki bu fark D kullanılarak, aşağıdaki formüle göre sürekli olarak HESAPLANMALIDIR:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16

Bir alım raporu yayımlandığında, J’nin güncel değeri örneklenir.

Titreşim hesabı, profil bağımsız izleyicilerin farklı uygulamalardan gelen raporları geçerli biçimde yorumlayabilmesini sağlamak için burada belirtilen formüle UYGUN OLMALIDIR. Bu algoritma en iyi birinci dereceden kestirimcidir ve 1/16 kazanç parametresi, makul bir yakınsama hızı korunurken iyi bir gürültü azaltma oranı sağlar [22]. Örnek bir uygulama Ek A.8’de gösterilmiştir. İletimden önce paket süresi ve gecikmenin değişmesinin etkilerine ilişkin bir tartışma için Bölüm 6.4.4’e bakınız.

son SR zaman damgası (LSR): 32 bit

SSRC_n kaynağından alınan en son RTCP gönderici raporu (SR) paketinin bir parçası olarak alınan NTP zaman damgasındaki 64 bitin ortadaki 32 bitidir (Bölüm 4’te açıklandığı gibi). Henüz bir SR alınmamışsa, bu alan sıfıra ayarlanır.

son SR’den beri geçen gecikme (DLSR): 32 bit

SSRC_n kaynağından son SR paketinin alınması ile bu alım raporu bloğunun gönderilmesi arasındaki gecikmedir; 1/65536 saniye birimleriyle ifade edilir. SSRC_n’den henüz bir SR paketi alınmamışsa, DLSR alanı sıfıra ayarlanır.

Bu alım raporunu yayımlayan alıcıyı SSRC_r olarak gösterelim. SSRC_n kaynağı, bu alım raporu bloğunun alındığı zaman olan A zamanını kaydederek SSRC_r’ye olan gidiş-dönüş yayılım gecikmesini hesaplayabilir. Son SR zaman damgası (LSR) alanını kullanarak toplam gidiş-dönüş süresi A − LSR hesaplanır ve ardından bu alandan çıkarılarak gidiş-dönüş yayılım gecikmesi (A − LSR − DLSR) olarak elde edilir. Bu durum Şekil 2’de gösterilmiştir. Zamanlar, hem 32 bitlik alanların onaltılık gösterimiyle hem de karşılık gelen kayan noktalı ondalık gösterimle sunulmuştur. İki nokta üst üste işareti, 32 bitlik bir alanın 16 bitlik bir tamsayı kısmı ve 16 bitlik bir kesir kısmına bölündüğünü gösterir.

Bu değer, bazı bağlantıların çok asimetrik gecikmelere sahip olmasına rağmen, alıcı kümelerine olan mesafenin yaklaşık bir ölçüsü olarak kullanılabilir.

[10 Nov 1995 11:33:25.125 UTC]       [10 Nov 1995 11:33:36.5 UTC]
n                 SR(n)              A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
                  v                 ^
ntp_sec =0xb44db705 v               ^ dlsr=0x0005:4000 (    5.250 s)
ntp_frac=0x20000000  v             ^  lsr =0xb705:2000 (46853.125 s)
  (3024992005.125 s)  v           ^
r                      v         ^ RR(n)
---------------------------------------------------------------->
                      |<-DLSR->|
                       (5.250 s)

A     0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 (    5.250 s)
LSR  -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x0006:2000 (    6.125 s)

Şekil 2: Gidiş-dönüş süresi hesaplamasına örnek

6.4.2 RR: Alıcı Raporu RTCP Paketi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of packet sender                     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)               |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           extended highest sequence number received             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      interarrival jitter                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         last SR (LSR)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last SR (DLSR)                    |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)               |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  profile-specific extensions                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alıcı raporu (RR) paketinin biçimi, paket türü alanının sabit 201 değerini içermesi ve gönderici bilgisine ait beş sözcüğün çıkarılmış olması (bunlar NTP ve RTP zaman damgaları ile göndericinin paket ve sekizli sayılarıdır) dışında, SR paketinin biçimiyle aynıdır. Kalan alanlar SR paketi için olanlarla aynı anlama sahiptir.

Boş bir RR paketi (RC = 0), rapor edilecek herhangi bir veri iletimi veya alımı olmadığında, bileşik bir RTCP paketinin başına YERLEŞTİRİLMELİDİR.

6.4.3 Gönderici ve Alıcı Raporlarının Genişletilmesi

Bir profil, gönderici veya alıcılar hakkında düzenli olarak raporlanması gereken ek bilgiler varsa, gönderici raporu ve alıcı raporu için profile özgü genişletmeleri TANIMLAMALIDIR. Bu yöntem, başka bir RTCP paket türü tanımlamaya tercih edilmelidir; çünkü daha az ek yük gerektirir:

  • pakette daha az sekizli (RTCP başlığı veya SSRC alanı yoktur);
  • daha basit ve daha hızlı ayrıştırma; çünkü o profil altında çalışan uygulamalar, alım raporlarından sonra doğrudan erişilebilir konumda yer alan genişletme alanlarını her zaman bekleyecek şekilde programlanmış olur.

Genişletme, gönderici veya alıcı raporu paketinde dördüncü bir bölüm olup, varsa alım raporu bloklarından sonra, sonda yer alır. Ek gönderici bilgisi gerekiyorsa, gönderici raporları için bu bilgiler genişletme bölümünde önce yer alır; ancak alıcı raporları için bulunmaz. Alıcılar hakkında bilgi eklenecekse, bu veriler mevcut alım raporu blokları dizisine paralel bir blok dizisi olarak YAPILANDIRILMALIDIR; yani blok sayısı RC alanı tarafından belirtilir.

6.4.4 Gönderici ve Alıcı Raporlarının Analizi

Alım kalitesi geri bildiriminin yalnızca gönderici için değil, diğer alıcılar ve üçüncü taraf izleyiciler için de yararlı olması beklenmektedir. Gönderici, geri bildirime dayanarak iletimlerini değiştirebilir; alıcılar, sorunların yerel, bölgesel veya küresel olup olmadığını belirleyebilir; ağ yöneticileri ise, yalnızca RTCP paketlerini alan ve karşılık gelen RTP veri paketlerini almayan profil bağımsız izleyicileri kullanarak çok noktaya yayın dağıtımı için ağlarının performansını değerlendirebilir.

Kümülatif sayımlar, hem gönderici bilgisi hem de alıcı raporu bloklarında kullanılır; böylece herhangi iki rapor arasındaki farklar hesaplanarak hem kısa hem de uzun zaman aralıkları boyunca ölçümler yapılabilir ve bir raporun kaybına karşı dayanıklılık sağlanır. Alınan son iki rapor arasındaki fark, dağıtımın yakın zamandaki kalitesini tahmin etmek için kullanılabilir. İki rapor arasındaki zaman aralığında bu farklardan hızların hesaplanabilmesi için NTP zaman damgası dahil edilir. Bu zaman damgası veri kodlaması için kullanılan saat hızından bağımsız olduğundan, kodlama ve profil bağımsız kalite izleyicilerinin uygulanması mümkündür.

Örnek bir hesaplama, iki alım raporu arasındaki aralık için paket kayıp oranıdır. Kayıp paketlerin kümülatif sayısındaki fark, bu aralıkta kaybolan paket sayısını verir. Alınan genişletilmiş son sıra numaralarındaki fark, aralık boyunca beklenen paket sayısını verir. Bu ikisinin oranı, aralık için paket kayıp kesridir. Bu oran, iki rapor ardışık ise fraction lost alanına eşit olmalıdır; ancak aksi durumda eşit olmayabilir. Saniye başına kayıp oranı, kayıp kesrinin saniye cinsinden ifade edilen NTP zaman damgaları farkına bölünmesiyle elde edilebilir. Alınan paket sayısı, beklenen paket sayısından kaybolan paket sayısının çıkarılmasıyla bulunur. Beklenen paket sayısı, herhangi bir kayıp tahmininin istatistiksel geçerliliğini değerlendirmek için de kullanılabilir. Örneğin, 5 paketten 1’inin kaybı, 1000 paketten 200’ünün kaybına kıyasla daha düşük bir anlamlılığa sahiptir.

Gönderici bilgisinden, üçüncü taraf bir izleyici veriyi almadan bir aralık boyunca ortalama yük verisi hızını ve ortalama paket hızını hesaplayabilir. Bu ikisinin oranı alındığında ortalama yük boyutu elde edilir. Paket kaybının paket boyutundan bağımsız olduğu varsayılabilirse, belirli bir alıcı tarafından alınan paket sayısının ortalama yük boyutu (veya karşılık gelen paket boyutu) ile çarpımı, o alıcıya görünen kullanılabilir aktarım hızını verir.

Raporlar arasındaki farklar kullanılarak uzun vadeli paket kaybı ölçümlerine olanak tanıyan kümülatif sayımlara ek olarak, fraction lost alanı tek bir rapordan kısa vadeli bir ölçüm sağlar. Bu durum, bir oturumun boyutu, tüm alıcılar için alım durumu bilgisinin tutulamayacağı kadar büyüdüğünde veya raporlar arasındaki aralık, belirli bir alıcıdan yalnızca tek bir rapor alınabilecek kadar uzadığında daha önemli hale gelir.

Interarrival jitter alanı, ağ tıkanıklığı için ikinci bir kısa vadeli ölçüm sağlar. Paket kaybı kalıcı tıkanıklığı izlerken, jitter ölçümü geçici tıkanıklığı izler. Jitter ölçümü, paket kaybına yol açmadan önce tıkanıklığı gösterebilir. Interarrival jitter alanı, rapor anındaki jitter’ın yalnızca bir anlık görüntüsüdür ve nicel olarak alınması amaçlanmamıştır. Bunun yerine, zaman içinde tek bir alıcıdan gelen birden çok rapor arasında veya aynı anda birden çok alıcıdan (örneğin tek bir ağ içinde) gelen raporlar arasında karşılaştırma yapmak için tasarlanmıştır. Alıcılar arasında karşılaştırma yapılabilmesi için jitter’ın tüm alıcılar tarafından aynı formüle göre hesaplanması önemlidir.

Jitter hesaplaması, paketteki ilk verinin örneklendiği anı temsil eden RTP zaman damgasına dayandığından, bu örnekleme anı ile paketin iletildiği zaman arasındaki gecikmedeki herhangi bir değişkenlik, hesaplanan jitter’ı etkileyecektir. Böyle bir gecikme değişkenliği, süreleri değişen ses paketlerinde ortaya çıkar. Ayrıca video kodlamalarında da ortaya çıkar; çünkü zaman damgası bir kareye ait tüm paketler için aynıdır, ancak bu paketlerin tümü aynı anda iletilmez. İletime kadar olan gecikmedeki değişkenlik, jitter hesaplamasının ağın davranışını tek başına ölçme doğruluğunu azaltır; ancak alıcı arabelleğinin bunu karşılamak zorunda olması göz önünde bulundurulduğunda dahil edilmesi uygundur. Jitter hesaplaması karşılaştırmalı bir ölçüm olarak kullanıldığında, iletime kadar olan gecikmedeki değişkenlikten kaynaklanan (sabit) bileşen çıkarılır; böylece ağ jitter bileşenindeki bir değişiklik, göreli olarak küçük olmadığı sürece gözlemlenebilir. Değişiklik küçükse, muhtemelen önemsizdir.

6.5 SDES: Kaynak Tanımlama RTCP Paketi

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_1                          |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_2                          |
  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SDES paketi, bir başlık ve sıfır veya daha fazla parçadan (chunk) oluşan üç seviyeli bir yapıdır; her parça, o parçada tanımlanan kaynağı açıklayan öğelerden oluşur. Öğeler, sonraki bölümlerde ayrı ayrı açıklanmaktadır.

sürüm (V), doldurma (P), uzunluk: SR paketi için açıklandığı gibidir (bkz. Bölüm 6.4.1).

paket türü (PT): 8 bit Bunun bir RTCP SDES paketi olduğunu belirtmek için sabit 202 değerini içerir.

kaynak sayısı (SC): 5 bit Bu SDES paketinde bulunan SSRC/CSRC parçalarının sayısıdır. Sıfır değeri geçerlidir ancak kullanışsızdır.

Her parça, bir SSRC/CSRC tanımlayıcısını ve ardından SSRC/CSRC hakkında bilgi taşıyan sıfır veya daha fazla öğeden oluşan bir listeyi içerir. Her parça 32 bitlik bir sınırda başlar. Her öğe, 8 bitlik bir tür alanı, metnin uzunluğunu tanımlayan 8 bitlik bir oktet sayısı (dolayısıyla bu iki oktetlik başlık dahil değildir) ve metnin kendisinden oluşur. Metnin 255 oktetten uzun olamayacağına dikkat edilmelidir; ancak bu, RTCP bant genişliği tüketimini sınırlama gereksinimiyle uyumludur.

Metin, RFC 2279 [5]’te belirtilen UTF-8 kodlamasına göre kodlanır. US-ASCII bu kodlamanın bir alt kümesidir ve ek bir kodlama gerektirmez. Çok oktetli kodlamaların varlığı, bir karakterin en anlamlı bitinin bir değerine ayarlanmasıyla belirtilir.

Öğeler bitişiktir; yani öğeler tek tek 32 bitlik sınırlara doldurulmaz. Bazı çok oktetli kodlamalar null oktetler içerdiğinden, metin null ile sonlandırılmaz. Her parçada bulunan öğe listesi, bir veya daha fazla null oktet ile SONLANDIRILMALIDIR; bunların ilki, listenin sonunu belirtmek üzere türü sıfır olan bir öğe türü olarak yorumlanır. Null öğe türü oktetinden sonra bir uzunluk okteti gelmez; ancak bir sonraki 32 bitlik sınıra kadar doldurmak için gerekirse ek null oktetler DAHİL EDİLMELİDİR. Bu doldurmanın, RTCP başlığındaki P biti ile belirtilen doldurmadan ayrı olduğuna dikkat edilmelidir. Sıfır öğe içeren (dört null oktet) bir parça geçerlidir ancak kullanışsızdır.

Uç sistemler, kendi kaynak tanımlayıcılarını (sabit RTP başlığındaki SSRC ile aynı) içeren tek bir SDES paketi gönderir. Bir mikser, SDES bilgisi aldığı her katkıda bulunan kaynak için bir parça içeren tek bir SDES paketi gönderir veya bu tür kaynakların sayısı 31’den fazlaysa yukarıdaki biçimde birden çok tam SDES paketi gönderir (bkz. Bölüm 7).

Halihazırda tanımlı SDES öğeleri sonraki bölümlerde açıklanmaktadır. Yalnızca CNAME öğesi zorunludur. Burada gösterilen bazı öğeler yalnızca belirli profiller için yararlı olabilir; ancak öğe türlerinin tümü, ortak kullanımı teşvik etmek ve profil bağımsız uygulamaları basitleştirmek için tek bir ortak alandan atanmıştır. Ek öğeler, Bölüm 15’te açıklandığı gibi tür numaraları IANA’ya kaydedilerek bir profilde tanımlanabilir.

6.5.1 CNAME: Kanonik Uç Nokta Tanımlayıcısı SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    CNAME=1    |     length    | user and domain name        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CNAME tanımlayıcısı aşağıdaki özelliklere sahiptir:

  • Rastgele tahsis edilen SSRC tanımlayıcısı, bir çakışma keşfedilirse veya bir program yeniden başlatılırsa değişebileceğinden, SSRC tanımlayıcısından sabit kalan bir kaynak (gönderici veya alıcı) tanımlayıcısına bağlama sağlamak için CNAME öğesi MUTLAKA dahil edilmelidir.
  • SSRC tanımlayıcısında olduğu gibi, CNAME tanımlayıcısı da tek bir RTP oturumu içindeki tüm katılımcılar arasında benzersiz OLMALIDIR.
  • Bir katılımcı tarafından kullanılan birden çok medya aracında, ilişkili RTP oturumları kümesi boyunca bağlama sağlamak için CNAME, o katılımcı için sabit OLMALIDIR.
  • Üçüncü taraf izlemeyi kolaylaştırmak için CNAME, bir programın veya bir kişinin kaynağı bulmasına uygun OLMALIDIR.

Bu nedenle, mümkün olduğunda CNAME algoritmik olarak türetilmeli ve elle girilmemelidir. Bu gereksinimleri karşılamak için, bir profil alternatif bir sözdizimi veya anlambilim belirtmedikçe aşağıdaki biçim KULLANILMALIDIR. CNAME öğesi, kullanıcı adı mevcut değilse (tek kullanıcılı sistemlerde olduğu gibi) "host" veya "user@host" biçiminde OLMALIDIR. Her iki biçimde de "host", gerçek zamanlı verinin kaynaklandığı ana bilgisayarın tam nitelikli alan adıdır ve RFC 1034 [6], RFC 1035 [7] ve RFC 1123 [8] Bölüm 2.1’de belirtilen kurallara göre biçimlendirilir; ya da RTP iletişimi için kullanılan arabirimdeki ana bilgisayarın sayısal adresinin standart ASCII gösterimidir. Örneğin, IP Sürüm 4 adresinin standart ASCII gösterimi "noktalı ondalık" (dotted decimal) olarak da bilinir; IP Sürüm 6 için adresler, RFC 3513 [23]’te ayrıntıları verilen varyasyonlarla birlikte iki nokta üst üste ile ayrılmış onaltılık rakam grupları olarak metinsel biçimde gösterilir. Diğer adres türlerinin de karşılıklı olarak benzersiz ASCII gösterimlerine sahip olması beklenir. Tam nitelikli alan adı, insan gözlemciler için daha kullanışlıdır ve ayrıca bir NAME öğesi gönderme gereksinimini ortadan kaldırabilir; ancak bazı işletim ortamlarında güvenilir biçimde elde edilmesi zor veya imkânsız olabilir. Bu tür ortamlarda çalışabilecek uygulamalar, bunun yerine adresin ASCII gösterimini KULLANMALIDIR.

Çok kullanıcılı bir sistem için örnekler "doe@sleepy.example.com", "doe@192.0.2.89" veya "doe@2201:056D::112E:144A:1E24" şeklindedir. Kullanıcı adı olmayan bir sistemde örnekler "sleepy.example.com", "192.0.2.89" veya "2201:056D::112E:144A:1E24" olacaktır.

Kullanıcı adı, "finger" veya "talk" gibi bir programın kullanabileceği bir biçimde OLMALIDIR; yani genellikle kişisel addan ziyade oturum açma adıdır. Ana bilgisayar adı, katılımcının elektronik posta adresindeki adla mutlaka aynı olmak zorunda değildir.

Bu sözdizimi, bir uygulamanın tek bir ana bilgisayardan bir kullanıcının birden çok kaynak üretmesine izin vermesi durumunda her kaynak için benzersiz tanımlayıcılar sağlamaz. Böyle bir uygulamanın, kaynağı daha ileri düzeyde tanımlamak için SSRC’ye güvenmesi gerekir veya o uygulamanın profili, CNAME tanımlayıcısı için ek bir sözdizimi belirtmelidir.

Her uygulama CNAME’ini bağımsız olarak oluşturursa, ortaya çıkan CNAME’ler, ilişkili RTP oturumları kümesinde tek bir katılımcıya ait birden çok medya aracı arasında bağlama sağlamak için gerekli olduğu gibi özdeş olmayabilir. Medyalar arası bağlama gerekiyorsa, her aracın CNAME’inin, bir eşgüdüm aracı tarafından aynı değerle harici olarak yapılandırılması gerekebilir.

Uygulama geliştiricileri, RFC 1918 [24]’te önerilen Net-10 ataması gibi özel ağ adresi atamalarının, küresel olarak benzersiz olmayan ağ adresleri üretebileceğinin farkında olmalıdır. Bu durum, özel adreslere sahip ve genel İnternet’e doğrudan IP bağlantısı olmayan ana bilgisayarların RTP paketlerinin, RTP düzeyinde bir çevirmen aracılığıyla genel İnternet’e iletilmesi halinde benzersiz olmayan CNAME’lere yol açar (ayrıca bkz. RFC 1627 [25]). Bu durumu ele almak için, uygulamalar benzersiz bir CNAME yapılandırmaya yönelik bir mekanizma SUNABİLİR; ancak gerekli olması halinde özel adreslerin açığa çıkmasını önlemek için CNAME’leri özel adreslerden genel adreslere çevirmek yükümlülüğü çevirmen üzerindedir.

6.5.2 NAME: Kullanıcı Adı SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NAME=2    |     length    | common name of source       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bu, kaynağı tanımlamak için kullanılan gerçek addır; örneğin "John Doe, Bit Recycler". Kullanıcının istediği herhangi bir biçimde olabilir. Konferans gibi uygulamalar için bu ad biçimi, katılımcı listelerinde gösterim açısından en elverişli olanı olabilir ve bu nedenle CNAME dışındaki öğeler arasında en sık gönderilenlerden biri olabilir. Profiller bu tür öncelikleri BELİRLEYEBİLİR. NAME değerinin, en azından bir oturumun süresi boyunca sabit kalması beklenir. Oturumdaki tüm katılımcılar arasında benzersiz olduğu varsayılmamalıdır.

6.5.3 EMAIL: Elektronik Posta Adresi SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    EMAIL=3    |     length    | email address of source     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Elektronik posta adresi, RFC 2822 [9]’a göre biçimlendirilir; örneğin "John.Doe@example.com". EMAIL değerinin, bir oturumun süresi boyunca sabit kalması beklenir.

6.5.4 PHONE: Telefon Numarası SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PHONE=4    |     length    | phone number of source      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Telefon numarası, uluslararası erişim kodu yerine artı işareti kullanılarak biçimlendirilmelidir. Örneğin, Amerika Birleşik Devletleri’ndeki bir numara için "+1 908 555 1212".

6.5.5 LOC: Coğrafi Kullanıcı Konumu SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     LOC=5     |     length    | geographic location of site ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Uygulamaya bağlı olarak, bu öğe için farklı ayrıntı düzeyleri uygun olabilir. Konferans uygulamaları için "Murray Hill, New Jersey" gibi bir dize yeterli olabilirken, etkin bir rozet sistemi için "Room 2A244, AT&T BL MH" gibi dizeler uygun olabilir. Ayrıntı düzeyi uygulamaya ve/veya kullanıcıya bırakılmıştır, ancak biçim ve içerik bir profil tarafından BELİRLENEBİLİR. LOC değerinin, mobil ana bilgisayarlar dışında, bir oturum süresi boyunca sabit kalması beklenir.

6.5.6 TOOL: Uygulama veya Araç Adı SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TOOL=6    |     length    | name/version of source appl. ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Akışı üreten uygulamanın adını ve varsa sürümünü veren bir dize; örneğin "videotool 1.2". Bu bilgi hata ayıklama amaçları için yararlı olabilir ve SMTP başlıklarındaki Mailer veya Mail-System-Version alanlarına benzer. TOOL değerinin oturum süresi boyunca sabit kalması beklenir.

6.5.7 NOTE: Bildirim/Durum SDES Öğesi

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NOTE=7    |     length    | note about the source       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bu öğe için aşağıdaki anlamlar önerilmektedir, ancak bunlar veya başka anlamlar bir profil tarafından açıkça TANIMLANABİLİR. NOTE öğesi, kaynağın mevcut durumunu tanımlayan geçici iletiler için tasarlanmıştır; örneğin "telefondayım, konuşamam". Ya da bir seminer sırasında, bu öğe konuşmanın başlığını iletmek için kullanılabilir. Yalnızca istisnai bilgileri taşımak için kullanılmalıdır ve tüm katılımcılar tarafından rutin olarak EKLENMEMELİDİR; çünkü bu, alım raporları ve CNAME gönderim hızını yavaşlatır ve dolayısıyla protokolün performansını olumsuz etkiler. Özellikle, bir kullanıcının yapılandırma dosyasında bir öğe olarak yer ALMAMALI ve günün sözü gibi otomatik olarak üretilMEMELİDİR.

NOTE öğesi etkin olduğu sürece görüntülenmesi önemli olabileceğinden, NAME gibi CNAME dışındaki diğer öğelerin iletim hızı, NOTE öğesinin RTCP bant genişliğinin bu kısmını alabilmesi için azaltılabilir. Geçici ileti etkinliğini yitirdiğinde, NOTE öğesi alıcılara sinyal vermek amacıyla aynı tekrar oranında ancak uzunluğu sıfır olan bir dizeyle birkaç kez daha iletilmeye DEVAM ETMELİDİR. Bununla birlikte, alıcılar NOTE öğesini, küçük bir tekrar oranı katı boyunca ya da yaklaşık 20–30 RTCP aralığı süresince alınmazsa da etkin olmayan olarak DEĞERLENDİRMELİDİR.

6.5.8 PRIV: Özel Uzantılar SDES Öğesi

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     PRIV=8    |     length    | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |                  value string               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bu öğe, deneysel veya uygulamaya özgü SDES uzantılarını tanımlamak için kullanılır. Öğenin içeriği, bir uzunluk-dize çifti olan bir önekten oluşur; bunu, öğenin geri kalanını dolduran ve istenen bilgiyi taşıyan değer dizesi izler. Önek uzunluğu alanı 8 bit uzunluğundadır. Önek dizesi, PRIV öğesini tanımlayan kişi tarafından, bu uygulamanın alabileceği diğer PRIV öğelerine göre benzersiz olacak şekilde seçilen bir addır. Uygulama geliştiricisi, gerekirse ek bir alt tür tanımlamasıyla birlikte uygulama adını kullanmayı seçebilir.

Alternatif olarak, başkalarının temsil ettikleri kuruluşa dayalı bir ad seçmeleri ve ardından bu adın kullanımını söz konusu kuruluş içinde koordine etmeleri ÖNERİLİR.

Önekin, öğenin toplam 255 sekizlik (oktet) uzunluğu içinde bir miktar alan tükettiği unutulmamalıdır; bu nedenle önek mümkün olduğunca kısa tutulmalıdır. Bu olanak ve kısıtlı RTCP bant genişliği AŞIRI YÜKLENMEMELİDİR; tüm uygulamaların tüm denetim iletişimi gereksinimlerini karşılamak üzere tasarlanmamıştır.

SDES PRIV önekleri IANA tarafından kaydedilmeyecektir. PRIV öğesinin bazı biçimleri genel olarak yararlı olduğu kanıtlanırsa, bunun yerine IANA’ya kayıtlı, düzenli bir SDES öğe türü atanması GEREKİR; böylece önek gereksinimi ortadan kalkar. Bu, kullanımı basitleştirir ve iletim verimliliğini artırır.

6.6 BYE: Veda RTCP Paketi

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|    SC   |   PT=BYE=203  |             length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           SSRC/CSRC                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :                              ...                              :
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) |     length    |               reason for leaving            ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BYE paketi, bir veya daha fazla kaynağın artık etkin olmadığını belirtir.

sürüm (V), dolgu (P), uzunluk: SR paketi için tanımlandığı gibidir (bkz. Bölüm 6.4.1).

paket türü (PT): 8 bit Bunun bir RTCP BYE paketi olduğunu tanımlamak için sabit 203 değerini içerir.

kaynak sayısı (SC): 5 bit Bu BYE paketinde yer alan SSRC/CSRC tanımlayıcılarının sayısıdır. Sıfır değeri geçerlidir, ancak kullanışsızdır.

Bir BYE paketinin ne zaman gönderilmesi gerektiğine ilişkin kurallar Bölüm 6.3.7 ve 8.2’de belirtilmiştir.

Bir BYE paketi bir karıştırıcı (mixer) tarafından alındığında, karıştırıcı BYE paketini SSRC/CSRC tanımlayıcılarını değiştirmeden iletmelidir. Bir karıştırıcı kapanırsa, yönettiği tüm katkıda bulunan kaynakları ve kendi SSRC tanımlayıcısını listeleyen bir BYE paketi göndermelidir. İsteğe bağlı olarak, BYE paketi, ayrılma nedenini belirten metni izleyen 8 bitlik bir sekizlik sayısı ve ardından o kadar sekizlik içerebilir; örneğin "kamera arızası" veya "RTP döngüsü algılandı". Dize, SDES için tanımlananla aynı kodlamaya sahiptir. Dize paketi bir sonraki 32 bitlik sınıra kadar dolduruyorsa, dize null ile sonlandırılmaz. Aksi halde, BYE paketi bir sonraki 32 bitlik sınıra kadar null sekizliklerle doldurulmak ZORUNDADIR. Bu dolgu, RTCP başlığındaki P bitiyle belirtilen dolgudan ayrıdır.

6.7 APP: Uygulama Tanımlı RTCP Paketi

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype |   PT=APP=204  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          name (ASCII)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   application-dependent data                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

APP paketi, paket türü değeri kaydı gerektirmeden, yeni uygulamalar ve yeni özellikler geliştirildikçe deneysel kullanım için tasarlanmıştır. Tanınmayan adlara sahip APP paketleri YOK SAYILMALIDIR. Testlerden sonra ve daha geniş kullanım haklı görülürse, her APP paketinin alt tür ve ad alanları olmaksızın yeniden tanımlanması ve bir RTCP paket türü kullanılarak IANA’ya kaydedilmesi ÖNERİLİR.

sürüm (V), dolgu (P), uzunluk: SR paketi için tanımlandığı gibidir (bkz. Bölüm 6.4.1).

alt tür: 5 bit Tek bir benzersiz ad altında bir APP paketleri kümesinin tanımlanmasına olanak sağlamak veya herhangi bir uygulamaya bağımlı veri için alt tür olarak kullanılabilir.

paket türü (PT): 8 bit Bunun bir RTCP APP paketi olduğunu tanımlamak için sabit 204 değerini içerir.

ad: 4 sekizlik APP paketleri kümesini tanımlayan kişi tarafından, bu uygulamanın alabileceği diğer APP paketlerine göre benzersiz olacak şekilde seçilen bir addır. Uygulama geliştiricisi, uygulama adını kullanmayı ve ardından uygulama için yeni paket türleri tanımlamak isteyen başkalarına alt tür değerlerinin tahsisini koordine etmeyi seçebilir. Alternatif olarak, başkalarının temsil ettikleri kuruluşa dayalı bir ad seçmeleri ve ardından bu adın kullanımını söz konusu kuruluş içinde koordine etmeleri ÖNERİLİR. Ad, büyük ve küçük harflerin farklı kabul edildiği dört ASCII karakterden oluşan bir dizi olarak yorumlanır.

uygulamaya bağımlı veriler: değişken uzunluk Uygulamaya bağımlı veriler bir APP paketinde yer alabilir ya da almayabilir. RTP’nin kendisi tarafından değil, uygulama tarafından yorumlanır. Uzunluğu 32 bitin katı OLMAK ZORUNDADIR.

#7. RTP Çeviriciler ve Karıştırıcılar

Uç sistemlere ek olarak RTP, RTP düzeyinde "ara sistemler" olarak değerlendirilebilecek "çeviriciler" ve "karıştırıcılar" kavramlarını destekler. Bu destek protokole bir miktar karmaşıklık eklese de, bu işlevlere duyulan gereksinim, İnternet’te çok noktaya yayınlanan ses ve video uygulamalarıyla yapılan deneylerle açıkça ortaya konmuştur. Bölüm 2.3’te verilen çevirici ve karıştırıcı kullanım örnekleri, güvenlik duvarlarının ve düşük bant genişlikli bağlantıların varlığından kaynaklanmaktadır; her ikisinin de varlığını sürdürmesi muhtemeldir.

7.1 Genel Tanım

Bir RTP çeviricisi/karıştırıcısı, iki veya daha fazla taşıma düzeyi "bulutunu" birbirine bağlar. Tipik olarak her bulut, ortak bir ağ ve taşıma protokolü (örneğin IP/UDP) ile birlikte bir çok noktaya yayın adresi ve taşıma düzeyi hedef portu ya da bir çift tek noktaya yayın adresi ve portu ile tanımlanır. (IP sürüm 4’ten IP sürüm 6’ya gibi ağ düzeyi protokol çeviricileri, RTP’ye görünmez şekilde bir bulutun içinde bulunabilir.) Bir sistem, birden fazla RTP oturumu için çevirici veya karıştırıcı olarak hizmet verebilir, ancak her biri mantıksal olarak ayrı bir varlık olarak kabul edilir.

Bir çevirici veya karıştırıcı kurulduğunda bir döngü oluşmasını önlemek için aşağıdaki kurallara UYULMAK ZORUNDADIR:

  • Tek bir RTP oturumuna katılan çeviriciler ve karıştırıcılar tarafından bağlanan bulutların her biri, bu parametrelerden en az birinde (protokol, adres, port) diğerlerinin tümünden farklı OLMALIDIR ya da ağ düzeyinde diğerlerinden yalıtılmış OLMALIDIR.
  • Birinci kuralın bir türevi olarak, iletilecek kaynaklar kümesini bir düzenlemeyle bölmedikçe, paralel olarak bağlı birden fazla çevirici veya karıştırıcı BULUNMAMALIDIR.

Benzer şekilde, bir veya daha fazla RTP çeviricisi veya karıştırıcısı üzerinden iletişim kurabilen tüm RTP uç sistemleri aynı SSRC alanını paylaşır; yani SSRC tanımlayıcıları bu uç sistemlerin tümü arasında benzersiz OLMALIDIR. Bölüm 8.2, SSRC tanımlayıcılarının benzersiz tutulduğu ve döngülerin saptandığı çakışma çözüm algoritmasını açıklar.

Farklı amaçlar ve uygulamalar için tasarlanmış birçok çevirici ve karıştırıcı türü olabilir. Bazı örnekler; şifreleme eklemek veya kaldırmak, verinin ya da altta yatan protokollerin kodlamasını değiştirmek ya da bir çok noktaya yayın adresi ile bir veya daha fazla tek noktaya yayın adresi arasında çoğaltma yapmaktır. Çeviriciler ile karıştırıcılar arasındaki ayrım şudur: çevirici, farklı kaynaklardan gelen veri akışlarını ayrı ayrı iletirken, karıştırıcı bunları birleştirerek tek bir yeni akış oluşturur:

Çevirici: RTP paketlerini SSRC tanımlayıcılarını koruyarak iletir; bu, tüm kaynaklardan gelen paketler aynı çeviriciden geçip çeviricinin ağ kaynak adresini taşısa bile, alıcıların bireysel kaynakları tanımlamasını mümkün kılar. Bazı çevirici türleri veriyi olduğu gibi iletir, ancak diğerleri verinin kodlamasını ve dolayısıyla RTP veri yükü türünü ve zaman damgasını DEĞİŞTİREBİLİR. Birden fazla veri paketi tek bir pakete yeniden kodlanırsa ya da tersi olursa, çevirici giden paketlere yeni sıra numaraları atamak ZORUNDADIR. Gelen paket akışındaki kayıplar, giden sıra numaralarında karşılık gelen boşluklara neden olabilir. Alıcılar, özgün kaynak tarafından hangi veri yükü türünün veya taşıma adresinin kullanıldığını başka bir yolla bilmiyorlarsa, bir çeviricinin varlığını saptayamaz.

Karıştırıcı: Bir veya daha fazla kaynaktan gelen RTP veri paketlerinin akışlarını alır, verinin biçimini olası olarak değiştirir, akışları bir şekilde birleştirir ve ardından birleşik akışı iletir. Birden fazla giriş kaynağı arasındaki zamanlama genellikle senkronize olmayacağından, karıştırıcı akışlar arasında zamanlama ayarlamaları yapar ve birleşik akış için kendi zamanlamasını üretir; dolayısıyla senkronizasyon kaynağıdır. Bu nedenle, bir karıştırıcı tarafından iletilen tüm veri paketleri karıştırıcının kendi SSRC tanımlayıcısıyla işaretlenmek ZORUNDADIR. Karışık pakete katkıda bulunan özgün kaynakların kimliğini korumak için, karıştırıcı bu kaynakların SSRC tanımlayıcılarını paketin sabit RTP başlığını izleyen CSRC tanımlayıcıları listesine eklemelidir. Kendisi de bazı paketler için katkıda bulunan bir kaynak olan bir karıştırıcı, o paket için CSRC listesine kendi SSRC tanımlayıcısını açıkça DAHİL ETMELİDİR.

Bazı uygulamalar için, bir karıştırıcının CSRC listesinde kaynakları tanımlamaması kabul edilebilir OLABİLİR. Ancak bu durum, söz konusu kaynakları içeren döngülerin saptanamaması tehlikesini doğurur.

Ses gibi uygulamalar için bir karıştırıcının çeviriciye göre avantajı, giriş tarafında birden fazla kaynak etkin olsa bile çıkış bant genişliğinin tek bir kaynağın bant genişliğiyle sınırlı olmasıdır. Bu, düşük bant genişlikli bağlantılar için önemli olabilir. Dezavantajı ise, çıkış tarafındaki alıcıların, karıştırıcının uzaktan denetimi için bir mekanizma uygulanmadıkça, hangi kaynakların iletildiği veya susturulduğu üzerinde herhangi bir denetime sahip olmamasıdır. Karıştırıcıların senkronizasyon bilgisini yeniden üretmesi, alıcıların özgün akışlar arasında ortamlar arası senkronizasyon yapamaması anlamına da gelir. Çoklu ortamlı bir karıştırıcı bunu yapabilir.

     [E1]                                    [E6]
      |                                       |
E1:17 |                                 E6:15 |
      |                                       |   E6:15
      V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
     (M1)-------------><T1>-----------------><T2>-------------->[E7]
      ^                 ^     E4:47           ^   E4:47
 E2:1 |           E4:47 |                     |   M3:89 (64,45)
      |                 |                     |
     [E2]              [E4]     M3:89 (64,45) |
                                              |        açıklama:
 [E3] --------->(M2)----------->(M3)------------|        [Uç sistem]
      E3:64        M2:12 (64)  ^                       (Karıştırıcı)
                               | E5:45                 <Çevirici>
                               |
                              [E5]          kaynak: SSRC (CSRC'ler)
                                            ------------------->

Şekil 3: Uç sistemler, karıştırıcılar ve çeviriciler içeren örnek RTP ağı

SSRC ve CSRC tanımlayıcıları üzerindeki etkilerini göstermek için Şekil 3’te bir karıştırıcı ve çevirici kümesi gösterilmektedir. Şekilde, uç sistemler dikdörtgenler (E olarak adlandırılmış), çeviriciler üçgenler (T olarak adlandırılmış) ve karıştırıcılar oval şekiller (M olarak adlandırılmış) ile gösterilmiştir. "M1: 48(1,17)" gösterimi, karıştırıcı M1’de kaynaklanan bir paketi ifade eder; bu paket, M1’in (rastgele) 48 değerli SSRC’si ile E1 ve E2’den gelen paketlerin SSRC tanımlayıcılarından kopyalanmış 1 ve 17 olmak üzere iki CSRC tanımlayıcısını içerir.

7.2 Çeviricilerde RTCP İşleme

Veri paketlerini, muhtemelen değiştirilmiş biçimde iletmenin yanı sıra, çeviriciler ve karıştırıcılar RTCP paketlerini de işlemek ZORUNDADIR. Birçok durumda, uç sistemlerden alınan bileşik RTCP paketlerini parçalayarak SDES bilgilerini toplulaştırırlar ve SR veya RR paketlerini değiştirirler. Bu bilgilerin yeniden iletimi, paketlerin gelişiyle ya da çeviricinin veya karıştırıcının kendi RTCP aralık zamanlayıcısı tarafından tetiklenebilir.

Veri paketlerini değiştirmeyen bir çevirici, örneğin yalnızca bir çoklu yayın adresi ile tekil yayın adresi arasında çoğaltma yapan bir çevirici, RTCP paketlerini de değiştirmeden iletebilir. Yükü herhangi bir şekilde dönüştüren bir çevirici, SR ve RR bilgilerinde de karşılık gelen dönüşümleri yapmak ZORUNDADIR; böylece bu bilgiler verinin özelliklerini ve alım kalitesini yansıtmaya devam eder. Bu tür çeviriciler RTCP paketlerini basitçe iletmemelidir. Genel olarak, bir çevirici farklı kaynaklardan gelen SR ve RR paketlerini tek bir pakette toplulaştırmamalıdır; çünkü bu, LSR ve DLSR alanlarına dayanan yayılım gecikmesi ölçümlerinin doğruluğunu azaltır.

SR gönderici bilgisi: Bir çevirici kendi gönderici bilgisini üretmez; bunun yerine bir buluttan aldığı SR paketlerini diğerlerine iletir. SSRC olduğu gibi bırakılır, ancak çeviri tarafından gerektiriliyorsa gönderici bilgisi değiştirilmelidir. Bir çevirici veri kodlamasını değiştiriyorsa, "göndericinin bayt sayısı" alanını değiştirmek ZORUNDADIR. Ayrıca birden fazla veri paketini tek bir çıkış paketinde birleştiriyorsa, "göndericinin paket sayısı" alanını değiştirmek ZORUNDADIR. Zaman damgası frekansını değiştiriyorsa, SR paketindeki "RTP zaman damgası" alanını değiştirmek ZORUNDADIR.

SR/RR alım raporu blokları: Bir çevirici, bir buluttan aldığı alım raporlarını diğerlerine iletir. Bunların verinin ters yönünde aktığını unutmayın. SSRC olduğu gibi bırakılır. Bir çevirici birden fazla veri paketini tek bir çıkış paketinde birleştiriyor ve dolayısıyla sıra numaralarını değiştiriyorsa, paket kaybı alanları ve "genişletilmiş son sıra numarası" alanı için ters işlemi yapmak ZORUNDADIR. Bu karmaşık olabilir. Uç durumda, alım raporlarını çevirmek için anlamlı bir yol olmayabilir; bu nedenle çevirici hiç alım raporu iletmeyebilir ya da kendi alımına dayalı sentetik bir rapor iletebilir. Genel kural, belirli bir çeviri için anlamlı olanı yapmaktır.

Bir çevirici kendi adına bir SSRC tanımlayıcısına ihtiyaç duymaz, ancak aldığı veriler hakkında rapor göndermek amacıyla bir tane ayırmayı seçebilir. Bu raporlar, bağlı tüm bulutlara gönderilir; her biri, veri akışının o buluta gönderilen çevirisine karşılık gelir, çünkü alım raporları normalde tüm katılımcılara çoklu yayın olarak gönderilir.

SDES: Çeviriciler genellikle bir buluttan aldıkları SDES bilgilerini değiştirmeden diğerlerine iletir, ancak örneğin bant genişliği sınırlıysa CNAME olmayan SDES bilgilerini filtrelemeye karar verebilirler. SSRC tanımlayıcı çakışmalarının algılanabilmesi için CNAME’ler iletilmek ZORUNDADIR. Kendi RR paketlerini üreten bir çevirici, bu RR paketlerini gönderdiği aynı bulutlara kendisi hakkında SDES CNAME bilgisi göndermek ZORUNDADIR.

BYE: Çeviriciler BYE paketlerini değiştirmeden iletir. Paket iletimini durdurmak üzere olan bir çevirici, daha önce o buluta iletilmiş olan tüm SSRC tanımlayıcılarını içeren bir BYE paketini, bağlı olduğu her buluta göndermelidir; buna, kendi raporlarını göndermişse çeviricinin kendi SSRC tanımlayıcısı da dahildir.

APP: Çeviriciler APP paketlerini değiştirmeden iletir.

7.3 Karıştırıcılarda RTCP İşleme

Bir karıştırıcı kendi başına yeni bir veri akışı ürettiğinden, SR veya RR paketlerini hiç iletmez; bunun yerine her iki taraf için de yeni bilgiler üretir.

SR gönderici bilgisi: Bir karıştırıcı, karıştırdığı kaynaklardan gelen gönderici bilgilerini iletmez; çünkü kaynak akışlarının özellikleri karışım içinde kaybolur. Bir senkronizasyon kaynağı olarak, karıştırıcı karışık veri akışı hakkında gönderici bilgisi içeren kendi SR paketlerini üretmeli ve bunları karışık akışla aynı yönde göndermelidir.

SR/RR alım raporu blokları: Bir karıştırıcı, her buluttaki kaynaklar için kendi alım raporlarını üretir ve bunları yalnızca aynı buluta gönderir. Bu alım raporlarını diğer bulutlara göndermemeli ve bir buluttan aldığı alım raporlarını diğerlerine iletmemelidir; çünkü o bulutlarda kaynaklar SSRC değil (yalnızca CSRC) olacaktır.

SDES: Karıştırıcılar genellikle bir buluttan aldıkları SDES bilgilerini değiştirmeden diğerlerine iletir, ancak örneğin bant genişliği sınırlıysa CNAME olmayan SDES bilgilerini filtrelemeye karar verebilirler. SSRC tanımlayıcı çakışmalarının algılanabilmesi için CNAME’ler iletilmek ZORUNDADIR. (Bir karıştırıcı tarafından üretilen bir CSRC listesindeki bir tanımlayıcı, bir uç sistem tarafından üretilen bir SSRC tanımlayıcısıyla çakışabilir.) Bir karıştırıcı, SR veya RR paketlerini gönderdiği aynı bulutlara kendisi hakkında SDES CNAME bilgisi göndermek ZORUNDADIR.

Karıştırıcılar SR veya RR paketlerini iletmediğinden, genellikle SDES paketlerini bileşik bir RTCP paketinden ayıklayacaklardır. Ek yükü en aza indirmek için, SDES paketlerinden parçalar tek bir SDES paketinde toplulaştırılabilir ve daha sonra karıştırıcıdan kaynaklanan bir SR veya RR paketinin üzerine eklenebilir. SDES paketlerini toplulaştıran bir karıştırıcı, tekil bir kaynağa kıyasla daha fazla RTCP bant genişliği kullanır; çünkü bileşik paketler daha uzun olacaktır, ancak bu uygundur çünkü karıştırıcı birden fazla kaynağı temsil eder. Benzer şekilde, SDES paketlerini alındıkları gibi ileten bir karıştırıcı, tek bir kaynağın hızından daha yüksek bir RTCP paket hızında iletim yapacaktır; ancak yine bu doğrudur çünkü paketler birden fazla kaynaktan gelmektedir. RTCP paket hızı karıştırıcının her iki tarafında da farklı olabilir.

CSRC tanımlayıcıları eklemeyen bir karıştırıcı, SDES CNAME’lerini iletmekten de kaçınabilir. Bu durumda, iki buluttaki SSRC tanımlayıcı uzayları birbirinden bağımsızdır. Daha önce belirtildiği gibi, bu çalışma biçimi döngülerin algılanamaması tehlikesini doğurur.

BYE: Karıştırıcılar BYE paketlerini iletmek ZORUNDADIR. Paket iletimini durdurmak üzere olan bir karıştırıcı, daha önce o buluta iletilmiş olan tüm SSRC tanımlayıcılarını içeren bir BYE paketini, bağlı olduğu her buluta göndermelidir; buna, kendi raporlarını göndermişse karıştırıcının kendi SSRC tanımlayıcısı da dahildir.

APP: Karıştırıcıların APP paketlerine uyguladığı işlem uygulamaya özgüdür.

7.4 Ardışık Karıştırıcılar

Bir RTP oturumu, Şekil 3’te gösterildiği gibi bir karıştırıcı ve çevirici kümesini içerebilir. M2 ve M3 örneğinde olduğu gibi iki karıştırıcı ardışık bağlandığında, bir karıştırıcı tarafından alınan paketler zaten karıştırılmış olabilir ve birden fazla tanımlayıcı içeren bir CSRC listesi barındırabilir. İkinci karıştırıcı, çıkış paketinin CSRC listesini, zaten karıştırılmış giriş paketlerindeki CSRC tanımlayıcılarını ve karıştırılmamış giriş paketlerindeki SSRC tanımlayıcılarını kullanarak oluşturmalıdır. Bu durum, şekilde M3:89(64,45) olarak etiketlenmiş karıştırıcı M3’ten çıkan okta gösterilmektedir. Ardışık olmayan karıştırıcılarda olduğu gibi, ortaya çıkan CSRC listesi 15’ten fazla tanımlayıcı içeriyorsa, kalanlar dahil edilemez.

#8. SSRC Tanımlayıcılarının Ayrılması ve Kullanımı

RTP başlığında ve RTCP paketlerinin çeşitli alanlarında taşınan SSRC tanımlayıcısı, bir RTP oturumu içinde küresel olarak benzersiz olması gereken rastgele bir 32 bitlik sayıdır. Aynı ağdaki ya da aynı zamanda başlatılan katılımcıların aynı sayıyı seçme olasılığının düşük olması için bu sayının dikkatle seçilmesi kritik öneme sahiptir.

Tanımlayıcı olarak yerel ağ adresinin (örneğin bir IPv4 adresi) kullanılması yeterli değildir; çünkü adres benzersiz olmayabilir. RTP çeviricileri ve karıştırıcıları, farklı adres uzaylarına sahip birden fazla ağ arasında birlikte çalışabilirliği sağladığından, iki uzay içindeki adres ayırma düzenleri, rastgele ayırmada ortaya çıkacak olandan çok daha yüksek bir çakışma oranına yol açabilir.

Tek bir ana bilgisayarda çalışan birden fazla kaynak da çakışmaya neden olacaktır.

Durumu dikkatle başlatmadan yalnızca random() çağırarak bir SSRC tanımlayıcısı elde etmek de yeterli değildir. Rastgele bir tanımlayıcının nasıl üretileceğine dair bir örnek Ek A.6’da sunulmaktadır.

8.1 Çakışma Olasılığı

Tanımlayıcılar rastgele seçildiğinden, iki veya daha fazla kaynağın aynı sayıyı seçmesi mümkündür. Çakışma, tüm kaynaklar aynı anda başlatıldığında en yüksek olasılıkla meydana gelir; örneğin bir oturum yönetimi olayı tarafından otomatik olarak tetiklendiğinde. N kaynak sayısı ve L tanımlayıcının uzunluğu (burada 32 bit) olmak üzere, iki kaynağın bağımsız olarak aynı değeri seçme olasılığı, büyük N için [26] yaklaşık olarak şu şekilde ifade edilebilir:

1 - exp(-N2 / 2(L+1))

N = 1000 için olasılık yaklaşık olarak 10**-4’tür.

Tipik çakışma olasılığı, yukarıdaki en kötü durumdan çok daha düşüktür. Yeni bir kaynak, diğer tüm kaynakların zaten benzersiz tanımlayıcılara sahip olduğu bir RTP oturumuna katıldığında, çakışma olasılığı yalnızca kullanılan sayıların uzaya oranıdır. Yine N kaynak sayısı ve L tanımlayıcının uzunluğu olmak üzere, çakışma olasılığı N / 2**L’dir. N = 1000 için olasılık yaklaşık olarak 210*-7’dir.

Çakışma olasılığı, yeni bir kaynağın ilk paketini (veri veya kontrol) göndermeden önce diğer katılımcılardan paket alma fırsatı sayesinde daha da azaltılır. Yeni kaynak, diğer katılımcıları (SSRC tanımlayıcılarıyla) izlerse, ilk paketini iletmeden önce kendi tanımlayıcısının alınmış olanlarla çakışmadığını doğrulayabilir ya da aksi durumda yeniden seçim yapabilir.

8.2 Çakışma Çözümü ve Döngü Algılama

SSRC tanımlayıcı çakışma olasılığı düşük olsa da, tüm RTP gerçekleştirimleri çakışmaları algılamaya ve bunları çözmek için uygun eylemleri almaya hazır olmak ZORUNDADIR. Bir kaynak, herhangi bir zamanda başka bir kaynağın kendi SSRC tanımlayıcısını kullandığını fark ederse, eski tanımlayıcı için bir RTCP BYE paketi göndermek ve başka bir rastgele tanımlayıcı seçmek ZORUNDADIR. (Aşağıda açıklandığı gibi, bir döngü durumunda bu adım yalnızca bir kez atılır.) Bir alıcı, iki başka kaynağın çakıştığını fark ederse, farklı kaynak taşıma adresleri veya CNAME’ler ile algılanabildiğinde, birinin paketlerini tutup diğerinin paketlerini atabilir. İki kaynağın, durumun uzun sürmemesi için çakışmayı çözmesi beklenir.

Rastgele SSRC tanımlayıcıları her RTP oturumu için küresel olarak benzersiz tutulduğundan, karıştırıcılar veya çeviriciler tarafından ortaya çıkabilecek döngüleri algılamak için de kullanılabilirler. Bir döngü, aşağıdaki örneklerde olduğu gibi, verinin ve kontrol bilgilerinin, değiştirilmeden ya da muhtemelen karıştırılmış olarak, çoğaltılmasına neden olur:

  • Bir çevirici, aldığı bir paketi yanlışlıkla aynı çoklu yayın grubuna, doğrudan ya da bir çevirici zinciri üzerinden, yeniden iletebilir. Bu durumda aynı paket, farklı ağ kaynaklarından geliyormuş gibi birden fazla kez görünür.
  • Paralel olarak yanlış yapılandırılmış iki çevirici, yani her iki tarafta da aynı çoklu yayın gruplarına sahip olduklarında, paketleri bir çoklu yayın grubundan diğerine iletir. Tek yönlü çeviriciler iki kopya üretir; çift yönlü çeviriciler ise bir döngü oluşturur.
  • Bir karıştırıcı, paketleri aldığı aynı taşıma hedefine, doğrudan ya da başka bir karıştırıcı veya çevirici üzerinden göndererek bir döngüyü kapatabilir. Bu durumda bir kaynak, hem bir veri paketinde SSRC olarak hem de karıştırılmış bir veri paketinde CSRC olarak görünebilir.

Bir kaynak, kendi paketlerinin döngüye girdiğini ya da başka bir kaynaktan gelen paketlerin döngüye girdiğini (üçüncü taraf döngüsü) fark edebilir. Hem döngüler hem de kaynak tanımlayıcısının rastgele seçilmesindeki çakışmalar, farklı bir kaynak taşıma adresine sahip ancak aynı SSRC tanımlayıcısını taşıyan paketlerin gelmesiyle sonuçlanır; bu adres, paketi üreten uç sistemin ya da bir ara sistemin adresi olabilir.

Bu nedenle, bir kaynak kendi kaynak taşıma adresini değiştirirse, döngüye girmiş bir kaynak olarak yorumlanmaktan kaçınmak için yeni bir SSRC tanımlayıcısı da seçebilir. (Bu ZORUNLU değildir; çünkü RTP’nin bazı uygulamalarında kaynakların bir oturum sırasında adres değiştirmesi beklenebilir.) Bir çevirici yeniden başlatılır ve sonuç olarak paketleri ilettiği kaynak taşıma adresini (örneğin UDP kaynak port numarasını) değiştirirse, bu paketlerin tümü alıcılara döngüye girmiş gibi görünecektir; çünkü SSRC tanımlayıcıları özgün kaynak tarafından uygulanır ve değişmez. Bu sorun, yeniden başlatmalar boyunca kaynak taşıma adresinin sabit tutulmasıyla önlenebilir; ancak her durumda, alıcılarda bir zaman aşımı sonrasında çözülecektir.

Bir çevirici ya da karıştırıcının öte tarafında meydana gelen döngüler veya çakışmalar, tüm paket kopyaları çevirici ya da karıştırıcı üzerinden geçtiği için kaynak taşıma adresi kullanılarak algılanamaz; ancak iki RTCP SDES paketinden gelen parçalar aynı SSRC tanımlayıcısını fakat farklı CNAME’leri içerdiğinde çakışmalar yine de algılanabilir.

Bu çakışmaları tespit etmek ve çözmek için, bir RTP uygulaması aşağıda açıklanana benzer bir algoritmayı MUTLAKA içermelidir; ancak uygulama, çakışan üçüncü taraf kaynaklardan gelen paketlerden hangilerinin tutulacağı konusunda farklı bir politika SEÇEBİLİR. Aşağıda açıklanan algoritma, yerleşik bir kaynakla çakışan yeni bir kaynaktan veya döngüden gelen paketleri yok sayar. Katılımcının kendi SSRC tanımlayıcısıyla olan çakışmaları, eski tanımlayıcı için bir RTCP BYE göndererek ve yeni bir tane seçerek çözer. Ancak çakışma, katılımcının kendi paketlerinin bir döngüsü tarafından tetiklendiyse, algoritma yalnızca bir kez yeni bir tanımlayıcı seçecek ve bundan sonra döngü oluşturan kaynak taşıma adresinden gelen paketleri yok sayacaktır. Bu, çok sayıda BYE paketinin oluşmasını önlemek için gereklidir.

Bu algoritma, kaynak tanımlayıcısına göre indekslenmiş ve o tanımlayıcıyla alınan ilk RTP paketi ile ilk RTCP paketinden gelen kaynak taşıma adreslerini ve ayrıca o kaynağa ait diğer durumu içeren bir tablo tutulmasını gerektirir. Örneğin, RTP ve RTCP paketlerinde UDP kaynak port numaraları farklı olabileceğinden iki kaynak taşıma adresi gereklidir. Bununla birlikte, her iki kaynak taşıma adresinde de ağ adresinin aynı olduğu varsayılabilir.

Bir RTP veya RTCP paketinde alınan her SSRC veya CSRC tanımlayıcısı, bu veri veya kontrol bilgisini işlemek amacıyla kaynak tanımlayıcı tablosunda aranır. Paketten gelen kaynak taşıma adresi, bir döngü veya çakışma tespit etmek için, eşleşmemeleri durumunda tabloda bu tanımlayıcı için kaydedilmiş olan karşılık gelen kaynak taşıma adresiyle karşılaştırılır. Kontrol paketleri için, örneğin bir SDES parçası gibi, kendi SSRC tanımlayıcısına sahip her öğe ayrı bir arama gerektirir. (Bir alım raporu bloğundaki SSRC tanımlayıcısı bir istisnadır; çünkü bu, raporu gönderenin duyduğu bir kaynağı tanımlar ve bu SSRC tanımlayıcısı, raporu gönderen tarafından gönderilen RTCP paketinin kaynak taşıma adresiyle ilişkili değildir.) SSRC veya CSRC bulunamazsa, yeni bir giriş oluşturulur. Bu tablo girişleri, karşılık gelen SSRC tanımlayıcısıyla bir RTCP BYE paketi alındığında ve eşleşen bir kaynak taşıma adresiyle doğrulandığında ya da nispeten uzun bir süre boyunca hiç paket gelmediğinde (bkz. Bölüm 6.2.1) kaldırılır.

Aynı ana makinedeki iki kaynağın, bir alıcı çalışmaya başladığı anda aynı kaynak tanımlayıcısıyla iletim yapması durumunda, alınan ilk RTP paketinin kaynaklardan birinden, ilk RTCP paketinin ise diğerinden gelmesi mümkün olabilir. Bu, yanlış RTCP bilgisinin RTP verileriyle ilişkilendirilmesine yol açar; ancak bu durumun yeterince nadir ve zararsız olduğu düşünülerek göz ardı edilebilir.

Katılımcının kendi veri paketlerinin döngülerini izlemek için, uygulama ayrıca çakıştığı tespit edilen kaynak taşıma adreslerinin (tanımlayıcıların değil) ayrı bir listesini MUTLAKA tutmalıdır. Kaynak tanımlayıcı tablosunda olduğu gibi, çakışan RTP ve RTCP paketlerini ayrı ayrı izlemek için iki kaynak taşıma adresi MUTLAKA tutulmalıdır. Çakışan adresler listesinin genellikle kısa, çoğu zaman boş olması gerektiğine dikkat edilmelidir. Bu listedeki her öğe, kaynak adreslerini ve en son çakışan paketin alındığı zamanı saklar. Bir öğe, o kaynaktan yaklaşık 10 RTCP rapor aralığı süresince (bkz. Bölüm 6.2) hiçbir çakışan paket gelmediğinde listeden KALDIRILABİLİR.

Gösterilen algoritma için, katılımcının kendi kaynak tanımlayıcısı ve durumunun kaynak tanımlayıcı tablosuna dahil edildiği varsayılmaktadır. Algoritma, önce katılımcının kendi kaynak tanımlayıcısına karşı ayrı bir karşılaştırma yapacak şekilde yeniden düzenlenebilir.

if (SSRC veya CSRC tanımlayıcısı
    kaynak tanımlayıcı tablosunda bulunamazsa) {
    veri veya kontrol kaynağı taşıma adresini,
        SSRC veya CSRC’yi ve diğer durumu saklayan
        yeni bir giriş oluştur;
}

/* Tanımlayıcı tabloda bulundu */

else if (tablo girdisi bir kontrol paketinin alınmasıyla
         oluşturulmuşsa ve bu ilk veri paketi ise ya da tersi) {
    bu paketten gelen kaynak taşıma adresini sakla;
}
else if (paketten gelen kaynak taşıma adresi,
         bu tanımlayıcı için tablo girdisinde kaydedilen
         adresle eşleşmiyorsa) {

    /* Bir tanımlayıcı çakışması veya döngü işaret edilir */

    if (kaynak tanımlayıcı katılımcının kendisi değilse) {
        /* İSTEĞE BAĞLI hata sayacı adımı */
        if (kaynak tanımlayıcı, tabloda yer alan CNAME’den
            farklı bir CNAME öğesi içeren bir RTCP SDES
            parçasından geliyorsa) {
            üçüncü taraf çakışmasını say;
        } else {
            üçüncü taraf döngüsünü say;
        }
        veri paketinin veya kontrol öğesinin
            işlenmesini iptal et;
        /* Yeni kaynağı tutmak için farklı bir politika
           SEÇEBİLİR */
    }

    /* Katılımcının kendi paketlerinin bir çakışması veya döngüsü */

    else if (kaynak taşıma adresi,
             çakışan veri veya kontrol kaynağı
             taşıma adresleri listesinde bulunuyorsa) {
        /* İSTEĞE BAĞLI hata sayacı adımı */
        if (kaynak tanımlayıcı, bir CNAME öğesi içeren
            bir RTCP SDES parçasından gelmiyorsa
            veya CNAME katılımcının kendisine aitse) {
            kendi trafiğinin döngüye girdiği durumu say;
        }
        çakışan adresler listesi girdisinde
            geçerli zamanı işaretle;
        veri paketinin veya kontrol öğesinin
            işlenmesini iptal et;
    }

    /* Yeni çakışma, SSRC tanımlayıcısını değiştir */

    else {
        bir çakışmanın meydana geldiğini kaydet;
        çakışan veri veya kontrol kaynağı
            taşıma adresleri listesinde yeni bir giriş oluştur
            ve geçerli zamanı işaretle;
        eski SSRC tanımlayıcısıyla bir RTCP BYE paketi gönder;
        yeni bir SSRC tanımlayıcısı seç;
        işlenmekte olan veri veya kontrol paketinden gelen
            kaynak taşıma adresiyle birlikte eski SSRC’yi içeren
            yeni bir kaynak tanımlayıcı tablosu girdisi oluştur;
    }
}

Bu algoritmada, yeni çakışan bir kaynak adresinden gelen paketler yok sayılacak ve özgün kaynak adresinden gelen paketler tutulacaktır. Özgün kaynaktan uzun bir süre boyunca paket gelmezse, tablo girdisi zaman aşımına uğrayacak ve yeni kaynak devralabilecektir. Bu durum, özgün kaynağın çakışmayı tespit edip yeni bir kaynak tanımlayıcısına geçmesi halinde meydana gelebilir; ancak olağan durumda, zaman aşımını beklemek zorunda kalmadan durumu silmek için özgün kaynaktan bir RTCP BYE paketi alınacaktır.

Özgün kaynak adresi bir mikser üzerinden alındıysa (yani bir CSRC olarak öğrenildiyse) ve daha sonra aynı kaynak doğrudan alınırsa, karışımdaki diğer kaynaklar kaybolmayacaksa alıcının yeni kaynak adresine geçmesi yerinde olabilir. Ayrıca, mobil varlıklar gibi bazı kaynakların bir RTP oturumu sırasında adres değiştirebildiği telefon uygulamaları gibi uygulamalar için, RTP uygulaması çakışma algılama algoritmasını yeni kaynak taşıma adresinden gelen paketleri kabul edecek şekilde DEĞİŞTİRMELİDİR. Gerçek bir çakışma meydana geldiğinde adresler arasında gidip gelmeyi önlemek için, algoritma bu durumu tespit edecek ve geçişi önleyecek bir mekanizma İÇERMELİDİR.

Bir çakışma nedeniyle yeni bir SSRC tanımlayıcısı seçildiğinde, aday tanımlayıcı önce kaynak tanımlayıcı tablosunda başka bir kaynak tarafından zaten kullanılıp kullanılmadığını görmek için KONTROL EDİLMELİDİR. Eğer öyleyse, başka bir aday MUTLAKA üretilmeli ve süreç tekrarlanmalıdır.

Çok noktaya yayın (multicast) hedefine giden veri paketlerinin bir döngüsü, ciddi ağ taşmasına neden olabilir. Tüm mikserler ve çeviriciler, döngüleri kırabilmek için burada anlatılana benzer bir döngü algılama algoritmasını MUTLAKA uygulamalıdır. Bu, fazla trafiği özgün trafiğin en fazla bir yinelenmiş kopyasıyla sınırlamalıdır; bu da döngünün nedeninin bulunup düzeltilmesi için oturumun devam etmesine olanak tanıyabilir. Ancak, bir mikser veya çeviricinin döngüyü düzgün şekilde kıramadığı ve yüksek trafik seviyelerinin oluştuğu aşırı durumlarda, uç sistemlerin veri veya kontrol paketlerinin iletimini tamamen durdurması gerekebilir. Bu karar uygulamaya bağlı olabilir. Uygun olduğu şekilde bir hata durumu GÖSTERİLMELİDİR. Uzun ve rastgele bir süreden (dakikalar mertebesinde) sonra iletim TEKRAR DENENEBİLİR.

8.3 Katmanlı Kodlamalarla Kullanım

Ayrı RTP oturumlarında iletilen katmanlı kodlamalar için (bkz. Bölüm 2.4), tüm katmanların ve çekirdek (temel) katmanın oturumları genelinde tek bir SSRC tanımlayıcı uzayı KULLANILMALIDIR ve SSRC tanımlayıcı tahsisi ile çakışma çözümü için çekirdek (temel) katman KULLANILMALIDIR. Bir kaynak çakıştığını fark ettiğinde, yalnızca temel katmanda bir RTCP BYE paketi gönderir ancak SSRC tanımlayıcısını tüm katmanlarda yeni değere değiştirir.

#9. Güvenlik

Alt katman protokolleri, kimlik doğrulama, bütünlük ve gizlilik dahil olmak üzere RTP uygulamaları için istenebilecek tüm güvenlik hizmetlerini zamanla sağlayabilir. Bu hizmetler IP için [27]’de belirtilmiştir. RTP kullanan ilk ses ve video uygulamalarının, IP katmanı için bu tür hizmetler mevcut olmadan önce bir gizlilik hizmetine ihtiyaç duyması nedeniyle, bir sonraki bölümde açıklanan gizlilik hizmeti RTP ve RTCP ile kullanım için tanımlanmıştır. Bu açıklama, mevcut uygulamayı kodlamak amacıyla burada yer almaktadır. RTP’nin yeni uygulamaları, geriye dönük uyumluluk için bu RTP’ye özgü gizlilik hizmetini UYGULAYABİLİR ve/veya alternatif güvenlik hizmetlerini UYGULAYABİLİR. Bu gizlilik hizmeti için RTP protokolü üzerindeki ek yük düşüktür; dolayısıyla bu hizmet gelecekte başka hizmetler tarafından geçersiz kılınırsa, ceza asgari olacaktır.

Alternatif olarak, gelecekte RTP için başka hizmetler, hizmetlerin başka uygulamaları ve başka algoritmalar tanımlanabilir. Özellikle, Secure Real-time Transport Protocol (SRTP) [28] adlı bir RTP profili, bağlantı düzeyi başlık sıkıştırma algoritmalarının çalışmaya devam edebilmesi için RTP başlığını açıkta bırakırken RTP yükünün gizliliğini sağlamak üzere geliştirilmektedir. SRTP’nin birçok uygulama için doğru tercih olması beklenmektedir. SRTP, Advanced Encryption Standard (AES) temellidir ve burada açıklanan hizmetten daha güçlü güvenlik sağlar. Burada sunulan yöntemlerin belirli bir güvenlik gereksinimi için uygun olduğuna dair bir iddiada bulunulmamaktadır. Bir profil, uygulamalar tarafından hangi hizmetlerin ve algoritmaların sunulması gerektiğini belirtebilir ve uygun kullanımlarına ilişkin rehberlik sağlayabilir.

Anahtar dağıtımı ve sertifikalar bu belgenin kapsamı dışındadır.

9.1 Gizlilik

Gizlilik, yalnızca hedeflenen alıcı(lar)ın alınan paketleri çözebilmesi anlamına gelir; diğerleri için paket yararlı hiçbir bilgi içermez. İçeriğin gizliliği şifreleme ile sağlanır.

Bu bölümde belirtilen yönteme göre RTP veya RTCP’yi şifrelemek istendiğinde, tek bir alt katman paketinde iletim için kapsüllenecek tüm sekizli (octet)ler bir bütün olarak şifrelenir. RTCP için, her birim için yeniden çekilen 32 bitlik rastgele bir sayı şifrelemeden önce birimin başına MUTLAKA eklenmelidir. RTP için herhangi bir önek eklenmez; bunun yerine, sıra numarası ve zaman damgası alanları rastgele ofsetlerle başlatılır. Bu, zayıf rastgelelik özellikleri nedeniyle zayıf bir başlatma vektörü (IV) olarak kabul edilir. Ayrıca, bir sonraki alan olan SSRC düşman tarafından manipüle edilebilirse, şifreleme yönteminde ek bir zayıflık oluşur.

RTCP için, bir uygulama bileşik bir RTCP paketindeki bireysel RTCP paketlerini, biri şifrelenmiş ve diğeri açık gönderilecek şekilde iki ayrı bileşik RTCP paketine AYIRABİLİR. Örneğin, şifreleme anahtarına sahip olmayan üçüncü taraf izleyicilere uyum sağlamak için SDES bilgileri şifrelenirken alım raporları açık gönderilebilir. Şekil 4’te gösterilen bu örnekte, tüm bileşik RTCP paketlerinin bir SR veya RR paketiyle başlaması gerekliliğini karşılamak için SDES bilgileri rapor içermeyen bir RR paketine (ve rastgele sayı ile birlikte) MUTLAKA eklenmelidir. SDES CNAME öğesi, şifrelenmiş veya şifrelenmemiş paketin herhangi birinde gereklidir, ancak her ikisinde birden gerekli değildir. Aynı SDES bilgileri her iki pakette TAŞINMAMALIDIR, çünkü bu şifrelemeyi tehlikeye atabilir.

         UDP paketi                    UDP paketi
-----------------------------  ------------------------------
[random][RR][SDES #CNAME ...]  [SR #senderinfo #site1 #site2]
-----------------------------  ------------------------------
         şifreli                      şifrelenmemiş

#: SSRC tanımlayıcısı

Şekil 4: Şifreli ve şifrelenmemiş RTCP paketleri

Şifrelemenin varlığı ve doğru anahtarın kullanımı, alıcı tarafından başlık veya yük geçerlilik kontrolleri aracılığıyla doğrulanır. RTP ve RTCP başlıkları için bu tür geçerlilik kontrollerine örnekler Ekler A.1 ve A.2’de verilmiştir.

RFC 1889’daki RTP’nin ilk belirtiminin mevcut uygulamalarıyla tutarlı olmak için, varsayılan şifreleme algoritması, RFC 1423 [29]’ün Bölüm 1.1’inde açıklandığı üzere şifre blok zincirleme (CBC) kipindeki Data Encryption Standard (DES) algoritmasıdır; ancak 8 sekizlinin katlarına doldurma, Bölüm 5.1’deki P biti için açıklandığı şekilde belirtilir. Başlatma vektörü sıfırdır; çünkü RTP başlığında veya bileşik RTCP paketleri için rastgele önekle rastgele değerler sağlanır. CBC başlatma vektörlerinin kullanımına ilişkin ayrıntılar için bkz. [30].

Burada belirtilen şifreleme yöntemini destekleyen uygulamalar, birlikte çalışabilirliği en üst düzeye çıkarmak için bu yöntem için varsayılan şifre olarak CBC kipinde DES algoritmasını her zaman DESTEKLEMELİDİR. Bu yöntem, İnternet üzerinde çalışan deneysel ses ve video araçlarında kullanımının kolay ve pratik olduğu gösterildiği için seçilmiştir. Ancak, DES’in o zamandan beri çok kolay kırılabildiği ortaya çıkmıştır.

Varsayılan algoritma yerine Triple-DES gibi daha güçlü şifreleme algoritmalarının kullanılması ÖNERİLİR. Ayrıca, güvenli CBC kipi, her paketin ilk bloğunun, şifrenin blok boyutuyla aynı boyutta rastgele ve bağımsız bir IV ile XOR’lanmasını gerektirir. RTCP için bu, her paketin başına her paket için bağımsız olarak seçilen 32 bitlik rastgele bir sayı eklenmesiyle (kısmen) sağlanır. RTP için, zaman damgası ve sıra numarası rastgele değerlerden başlar, ancak ardışık paketler bağımsız olarak rastgeleleştirilmez. Her iki durumda da (RTP ve RTCP) rastgeleliğin sınırlı olduğu unutulmamalıdır. Yüksek güvenlik gerektiren uygulamalar, daha geleneksel ve güçlü koruma yöntemlerini DÜŞÜNMELİDİR. Diğer şifreleme algoritmaları, RTP dışı yollarla bir oturum için dinamik olarak BELİRLENEBİLİR. Özellikle, AES tabanlı SRTP profili [28], bilinen açık metin ve CBC açık metin manipülasyonu endişelerini dikkate almak üzere geliştirilmektedir ve gelecekte doğru tercih olacaktır.

Yukarıda açıklandığı gibi IP düzeyinde ya da RTP düzeyinde şifrelemeye alternatif olarak, profiller şifreli kodlamalar için ek yük türleri tanımlayabilir. Bu kodlamalar, dolgu ve şifrelemenin diğer yönlerinin nasıl ele alınacağını BELİRTMEK ZORUNDADIR. Bu yöntem, yalnızca verinin şifrelenmesine izin verirken, başlıkların istenen uygulamalar için açıkta bırakılmasını sağlar. Şifre çözme ve kod çözmeyi birlikte gerçekleştirecek donanım aygıtları için özellikle yararlı olabilir. Ayrıca, RTP ve alt katman başlıklarının bağlantı düzeyinde sıkıştırılmasının istendiği ve yükün (adreslerin değil) gizliliğinin yeterli olduğu uygulamalar için de değerlidir; çünkü başlıkların şifrelenmesi sıkıştırmayı engeller.

9.2 Kimlik Doğrulama ve İleti Bütünlüğü

Kimlik doğrulama ve ileti bütünlüğü hizmetleri RTP düzeyinde tanımlanmamıştır; çünkü bu hizmetler bir anahtar yönetimi altyapısı olmadan doğrudan uygulanabilir değildir. Kimlik doğrulama ve bütünlük hizmetlerinin alt katman protokolleri tarafından sağlanması beklenmektedir.

#10. Tıkanıklık Kontrolü

İnternet üzerinde kullanılan tüm taşıma protokollerinin bir şekilde tıkanıklık kontrolünü ele alması gerekir [31]. RTP bir istisna değildir; ancak RTP üzerinden taşınan veriler çoğunlukla esnek olmayan (sabit ya da denetimli bir hızda üretilen) nitelikte olduğundan, RTP’de tıkanıklığı denetleme yöntemleri TCP gibi diğer taşıma protokollerindekilerden oldukça farklı olabilir. Bir bakımdan, esnek olmama durumu tıkanıklık riskini azaltır; çünkü RTP akışı, bir TCP akışının yapabildiği gibi mevcut tüm bant genişliğini tüketecek şekilde genişlemez. Bununla birlikte, esnek olmama durumu aynı zamanda, tıkanıklık oluştuğunda RTP akışının ağ üzerindeki yükünü keyfi olarak azaltarak tıkanıklığı ortadan kaldıramayacağı anlamına da gelir.

RTP çok çeşitli uygulamalar için, çok farklı bağlamlarda kullanılabildiğinden, tümü için geçerli tek bir tıkanıklık kontrol mekanizması yoktur. Bu nedenle, tıkanıklık kontrolü her RTP profilinde uygun şekilde TANIMLANMALIDIR. Bazı profiller için, bu profilin kullanımını mühendislik yoluyla tıkanıklığın önlendiği ortamlara sınırlayan bir uygulanabilirlik bildirimi eklemek yeterli olabilir. Diğer profiller için ise RTCP geri bildirimine dayalı veri hızı uyarlaması gibi belirli yöntemler gerekebilir.

#11. Ağ ve Taşıma Protokolleri Üzerinden RTP

Bu bölüm, RTP paketlerinin belirli ağ ve taşıma protokolleri içinde taşınmasına özgü konuları açıklar. Aşağıdaki kurallar, bu belirtim dışında protokole özgü tanımlar tarafından geçersiz kılınmadıkça geçerlidir.

RTP, RTP verisi ile RTCP denetim akışlarının ayrıştırılmasını sağlamak için alttaki protokol(ler)e güvenir. UDP ve benzeri protokoller için, RTP ÇİFT bir hedef bağlantı noktası numarası kullanmalı ve karşılık gelen RTCP akışı bir sonraki daha yüksek (TEK) hedef bağlantı noktası numarasını kullanmalıdır. Tek bir bağlantı noktası numarasını parametre olarak alan ve RTP ile RTCP bağlantı noktası çiftini bu numaradan türeten uygulamalar için, eğer tek bir numara sağlanırsa uygulama bu numarayı bağlantı noktası çiftinin tabanı olarak kullanmak üzere bir önceki daha düşük (çift) numara ile DEĞİŞTİRMELİDİR. RTP ve RTCP hedef bağlantı noktası numaralarının açık, ayrı parametrelerle (bir sinyalleşme protokolü ya da başka yollarla) belirtildiği uygulamalarda, uygulama bağlantı noktalarının çift/tek ve ardışık olmasına ilişkin kısıtlamaları GÖZ ARDI EDEBİLİR; ancak çift/tek bir bağlantı noktası çiftinin kullanılması yine de teşvik edilir. RTP ve RTCP bağlantı noktası numaraları AYNI OLMAMALIDIR; çünkü RTP, RTP verisi ile RTCP denetim akışlarını ayrıştırmak için bağlantı noktası numaralarına dayanır.

Tek noktaya yayın (unicast) bir oturumda, her iki katılımcının da RTP ve RTCP paketlerini almak için bir bağlantı noktası çifti belirlemesi gerekir. Her iki katılımcı AYNI bağlantı noktası çiftini kullanabilir. Bir katılımcı, gelen RTP ya da RTCP paketinin kaynak bağlantı noktasının, giden RTP ya da RTCP paketleri için hedef bağlantı noktası olarak kullanılabileceğini VARSAYMAMALIDIR. RTP veri paketleri her iki yönde de gönderildiğinde, her katılımcının RTCP SR paketleri, diğer katılımcının RTCP alımı için belirttiği bağlantı noktasına GÖNDERİLMELİDİR. RTCP SR paketleri, giden veri için gönderici bilgilerini ve gelen veri için alım raporu bilgilerini birleştirir. Bir taraf etkin olarak veri göndermiyorsa (Bölüm 6.4’e bakınız), bunun yerine bir RTCP RR paketi gönderilir.

Katmanlı kodlama uygulamalarının (Bölüm 2.4’e bakınız) bitişik bağlantı noktası numaralarından oluşan bir küme kullanması ÖNERİLİR. Mevcut işletim sistemlerindeki yaygın bir eksiklik nedeniyle, aynı bağlantı noktasının birden fazla çok noktaya yayın adresiyle kullanılmasını engellediğinden ve tek noktaya yayında yalnızca bir izin verilebilir adres bulunduğundan, bağlantı noktası numaraları AYRI OLMALIDIR. Buna göre, n katmanı için veri bağlantı noktası P + 2n, denetim bağlantı noktası ise P + 2n + 1’dir. IP çok noktaya yayın kullanıldığında, adresler de AYRI OLMALIDIR; çünkü çok noktaya yayın yönlendirme ve grup üyeliği adres düzeyinde yönetilir. Ancak, bitişik IP çok noktaya yayın adreslerinin tahsis edileceği varsayılamaz; çünkü bazı gruplar farklı kapsamlar gerektirebilir ve bu nedenle farklı adres aralıklarından tahsis edilebilir.

Önceki paragraf, SDP belirtimi olan RFC 2327 [15] ile çelişmektedir; bu belirtim, adreslerle bağlantı noktalarının eşleştirilmesinin belirsiz olabileceği gerekçesiyle, aynı oturum tanımında hem birden fazla adresin hem de birden fazla bağlantı noktasının belirtilmesini yasa dışı saymaktadır. RFC 2327’nin bir gözden geçirilmiş sürümünde bu kısıtlamanın gevşetilmesi ve bire bir eşleme ima edilerek eşit sayıda adres ve bağlantı noktasının belirtilmesine izin verilmesi amaçlanmaktadır.

RTP veri paketleri bir uzunluk alanı ya da başka bir sınırlandırma içermez; bu nedenle RTP, bir uzunluk göstergesi sağlamak için alttaki protokol(ler)e güvenir. RTP paketlerinin azami uzunluğu yalnızca alttaki protokoller tarafından sınırlandırılır.

RTP paketleri, paketler yerine sürekli bir oktet akışı soyutlaması sağlayan bir alttaki protokol içinde taşınacaksa, bir çerçeveleme mekanizması sağlamak üzere RTP paketlerinin bir kapsüllemesi TANIMLANMALIDIR. Alttaki protokol dolgu içerebiliyorsa ve bu nedenle RTP yükünün kapsamı belirlenemiyorsa çerçeveleme de gereklidir. Çerçeveleme mekanizması burada tanımlanmamıştır.

Bir profil, RTP zaten çerçeveleme sağlayan protokoller içinde taşındığında bile, bir UDP paketi gibi tek bir alt katman protokol veri biriminde birden fazla RTP paketinin taşınmasına olanak vermek için bir çerçeveleme yöntemi BELİRLEYEBİLİR. Tek bir ağ ya da taşıma paketinde birden fazla RTP paketinin taşınması başlık yükünü azaltır ve farklı akışlar arasındaki eşzamanlamayı basitleştirebilir.

#12. Protokol Sabitlerinin Özeti

Bu bölüm, bu belirtimde tanımlanan sabitlerin bir özet listesini içerir.

RTP yük türü (PT) sabitleri bu belgede değil, profillerde tanımlanır. Bununla birlikte, RTP başlığında işaretçi bit(ler)i ve yük türünü içeren oktet, Ek A.1’de açıklanan başlık doğrulama yordamı için RTP paketlerini RTCP SR ve RR paket türlerinden ayırt edebilmek amacıyla ayrılmış 200 ve 201 (ondalık) değerlerinden KAÇINMAK ZORUNDADIR. Bu belirtimde gösterildiği gibi bir işaretçi biti ve 7 bitlik bir yük türü alanının standart tanımı için, bu kısıtlama yük türleri 72 ve 73’ün ayrıldığı anlamına gelir.

12.1 RTCP Paket Türleri

| Kısaltma | Adı | Değer | |--------:|------------------------|------:| | SR | gönderici raporu | 200 | | RR | alıcı raporu | 201 | | SDES | kaynak tanımı | 202 | | BYE | veda | 203 | | APP | uygulama tanımlı | 204 |

Bu tür değerleri, RTP paketleri ya da diğer ilgisiz paketlerle karşılaştırıldığında RTCP paketlerinin başlık geçerlilik denetimini iyileştirmek amacıyla 200–204 aralığında seçilmiştir. RTCP paket türü alanı RTP başlığının karşılık gelen okteti ile karşılaştırıldığında, bu aralık işaretçi bitinin 1 olmasına (ki veri paketlerinde genellikle değildir) ve standart yük türü alanının en yüksek bitinin 1 olmasına karşılık gelir (çünkü statik yük türleri genellikle alt yarıda tanımlanır). Bu aralık ayrıca, tüm sıfırlar ve tüm birler yaygın veri desenleri olduğundan, 0 ve 255’ten sayısal olarak belirli bir uzaklıkta olacak şekilde seçilmiştir.

Tüm bileşik RTCP paketleri SR ya da RR ile BAŞLAMAK ZORUNDA olduğundan, bu kodlar RTCP geçerlilik denetiminin maske ve değer ile mümkün olan en fazla sayıda biti sınamasına olanak tanımak için çift/tek bir çift olarak seçilmiştir.

Ek RTCP paket türleri IANA aracılığıyla kaydedilebilir (Bölüm 15’e bakınız).

12.2 SDES Türleri

| Kısaltma | Adı | Değer | |--------:|-------------------------------------|------:| | END | SDES listesinin sonu | 0 | | CNAME | kanonik ad | 1 | | NAME | kullanıcı adı | 2 | | EMAIL | kullanıcının e-posta adresi | 3 | | PHONE | kullanıcının telefon numarası | 4 | | LOC | coğrafi kullanıcı konumu | 5 | | TOOL | uygulama ya da aracın adı | 6 | | NOTE | kaynak hakkında not | 7 | | PRIV | özel uzantılar | 8 |

Ek SDES türleri IANA aracılığıyla kaydedilebilir (Bölüm 15’e bakınız).

#13. RTP Profilleri ve Yük Biçimi Belirtimleri

Belirli bir uygulama için RTP’nin eksiksiz bir belirtimi, burada açıklanan iki tür eşlikçi belgeden bir ya da daha fazlasını gerektirir: profiller ve yük biçimi belirtimleri.

RTP, gereksinimleri bir miktar farklılık gösteren çeşitli uygulamalar için kullanılabilir. Bu gereksinimlere uyum sağlama esnekliği, ana protokol belirtiminde birden çok seçeneğe izin verilmesi ve ardından belirli bir ortam ve uygulama sınıfı için uygun seçeneklerin seçilmesi ya da uzantıların ayrı bir profil belgesinde tanımlanmasıyla sağlanır. Tipik olarak bir uygulama, belirli bir RTP oturumunda yalnızca tek bir profil altında çalışır; bu nedenle RTP protokolünün kendisi içinde hangi profilin kullanımda olduğuna dair açık bir gösterge yoktur. Ses ve video uygulamaları için bir profil, eşlikçi RFC 3551’de bulunabilir. Profiller genellikle "RTP Profile for ..." başlığını taşır.

İkinci tür eşlikçi belge, H.261 kodlu video gibi belirli bir yük veri türünün RTP içinde nasıl taşınacağını tanımlayan bir yük biçimi belirtimidir. Bu belgeler genellikle "RTP Payload Format for XYZ Audio/Video Encoding" başlığını taşır. Yük biçimleri birden fazla profil altında yararlı olabilir ve bu nedenle herhangi bir belirli profilden bağımsız olarak tanımlanabilir. Gerekirse, profil belgeleri bu biçimin bir yük türü değerine varsayılan bir eşlemesini atamaktan sorumludur.

Bu belirtim kapsamında, aşağıdaki öğeler bir profil içinde tanımlanabilecek olası konular olarak belirlenmiştir; ancak bu listenin kapsamlı olması amaçlanmamıştır:

  • RTP veri başlığı: RTP veri başlığında işaretçi biti ve yük türü alanını içeren oktet, örneğin daha fazla ya da daha az işaretçi biti olacak şekilde (Bölüm 5.3, s. 18), farklı gereksinimlere uyacak biçimde bir profil tarafından YENİDEN TANIMLANABİLİR.
  • Yük türleri: Bir yük türü alanının içerildiği varsayıldığında, profil genellikle bir dizi yük biçimi (ör. ortam kodlamaları) ve bu biçimlerin yük türü değerlerine varsayılan statik bir eşlemesini tanımlar. Yük biçimlerinin bazıları ayrı yük biçimi belirtimlerine atıfla tanımlanabilir. Tanımlanan her yük türü için, profil kullanılacak RTP zaman damgası saat hızını BELİRTMEK ZORUNDADIR (Bölüm 5.1, s. 14).
  • RTP veri başlığı eklemeleri: Yük türünden bağımsız olarak, profilin uygulama sınıfı genelinde ek işlevsellik gerekiyorsa, sabit RTP veri başlığına ek alanlar EKLENEBİLİR (Bölüm 5.3, s. 18).

RTP veri başlığı uzantıları: RTP veri başlığı uzantı yapısının ilk 16 bitinin içeriği, uygulamaya özgü uzantılar için bu mekanizmanın profil altında kullanılmasına izin verilecekse TANIMLANMALIDIR (Bölüm 5.3.1, s. 18).

RTCP paket türleri: Yeni uygulama sınıfına özgü RTCP paket türleri TANIMLANABİLİR ve IANA’ya kaydedilebilir.

RTCP rapor aralığı: Bir profil, RTCP rapor aralığının hesaplanmasında kullanılan sabitler için Bölüm 6.2’de önerilen değerlerin kullanılacağını BELİRTMELİDİR. Bunlar, oturum bant genişliğinin RTCP payı, asgari rapor aralığı ve göndericiler ile alıcılar arasındaki bant genişliği bölüşümüdür. Bir profil, ölçeklenebilir biçimde çalıştıkları gösterilmişse alternatif değerler BELİRLEYEBİLİR.

SR/RR uzantısı: Gönderici ya da alıcılar hakkında düzenli olarak raporlanması gereken ek bilgiler varsa, RTCP SR ve RR paketleri için bir uzantı bölümü TANIMLANABİLİR (Bölüm 6.4.3, s. 42 ve 43).

SDES kullanımı: Profil, gönderilecek RTCP SDES öğeleri için göreli öncelikleri BELİRLEYEBİLİR ya da tamamen hariç tutabilir (Bölüm 6.3.9); CNAME öğesi için alternatif bir sözdizimi ya da anlambilim (Bölüm 6.5.1); LOC öğesinin biçimi (Bölüm 6.5.5); NOTE öğesinin anlambilimi ve kullanımı (Bölüm 6.5.7); ya da IANA’ya kaydedilecek yeni SDES öğe türleri tanımlayabilir.

Güvenlik: Bir profil, uygulamalar tarafından sunulması gereken güvenlik hizmetlerini ve algoritmalarını BELİRLEYEBİLİR ve bunların uygun kullanımına ilişkin rehberlik SAĞLAYABİLİR (Bölüm 9, s. 65).

Dizeden anahtara eşleme: Bir profil, kullanıcı tarafından sağlanan bir parolanın ya da parola ifadesinin bir şifreleme anahtarına nasıl eşlendiğini BELİRLEYEBİLİR.

Tıkanıklık: Bir profil, o profile uygun tıkanıklık kontrol davranışını BELİRTMELİDİR.

Alttaki protokol: RTP paketlerini taşımak için belirli bir alttaki ağ ya da taşıma katmanı protokolünün kullanımı GEREKLİ KILINABİLİR.

Taşıma eşlemesi: RTP ve RTCP’nin, Bölüm 11, s. 68’de tanımlanan standart eşlemenin dışında, taşıma düzeyi adreslere (ör. UDP bağlantı noktaları) bir eşlemesi BELİRTİLEBİLİR.

Kapsülleme: RTP paketlerinin tek bir alt katman paketinde birden fazla RTP veri paketini taşımasına olanak vermek ya da bunu zaten yapmayan alttaki protokoller üzerinde çerçeveleme sağlamak için bir RTP kapsüllemesi TANIMLANABİLİR (Bölüm 11, s. 69).

Her uygulama için yeni bir profil gerekmesi beklenmez. Tek bir uygulama sınıfı içinde, uygulamalar arası birlikte çalışabilirliği kolaylaştırmak amacıyla, her biri genellikle yalnızca tek bir profil altında çalışacağından, yeni bir profil yapmak yerine mevcut bir profili genişletmek daha uygun olacaktır. Ek yük türü değerlerinin ya da RTCP paket türlerinin tanımlanması gibi basit uzantılar, IANA aracılığıyla kaydedilerek ve açıklamaları profile bir ek belgede ya da bir yük biçimi belirtiminde yayımlanarak gerçekleştirilebilir.

#14. Güvenlikle İlgili Hususlar

RTP, dayandığı alt protokollerle aynı güvenlik zafiyetlerinden muzdariptir. Örneğin, bir sahtekâr kaynak veya hedef ağ adreslerini taklit edebilir ya da başlığı veya yükü değiştirebilir. RTCP kapsamında, CNAME ve NAME bilgileri başka bir katılımcının kimliğine bürünmek için kullanılabilir. Ayrıca RTP, gönderilen verinin tüm alıcılarını gönderenin bilmesini sağlayacak doğrudan bir yöntem sunmayan ve dolayısıyla herhangi bir gizlilik ölçüsü sağlamayan IP çoklu yayını (multicast) üzerinden gönderilebilir. Haklı olarak ya da değil, kullanıcılar ses ve video iletişiminde gizlilik konularına, daha geleneksel ağ iletişim biçimlerine kıyasla daha duyarlı olabilirler [33]. Bu nedenle, RTP ile birlikte güvenlik mekanizmalarının kullanılması önemlidir. Bu mekanizmalar Bölüm 9'da ele alınmaktadır.

RTP düzeyi çeviriciler veya mikserler, RTP trafiğinin güvenlik duvarlarının arkasındaki ana bilgisayarlara ulaşmasını sağlamak için kullanılabilir. Bu belgenin kapsamı dışında kalan uygun güvenlik duvarı güvenlik ilkeleri ve uygulamaları, bu aygıtların tasarım ve kurulumunda ve güvenlik duvarı arkasında kullanılmak üzere RTP uygulamalarının kabulünde izlenmelidir.

#15. IANA Hususları

Ek RTCP paket türleri ve SDES öğe türleri, Internet Assigned Numbers Authority (IANA) aracılığıyla kaydedilebilir. Bu numara alanları küçük olduğundan, yeni değerlerin sınırsız kaydına izin vermek ihtiyatlı olmaz. İsteklerin gözden geçirilmesini kolaylaştırmak ve yeni türlerin birden fazla uygulama arasında ortak kullanımını teşvik etmek için, yeni değerlerin kaydı talepleri bir RFC'de veya başka bir kalıcı ve kolayca erişilebilir başvuruda, örneğin başka bir işbirlikçi standartlar kuruluşunun (örn. ITU-T) ürünü olan bir belgede dokümante edilmelidir. Diğer talepler de bir "atanmış uzman"ın tavsiyesi doğrultusunda kabul edilebilir.

(Mevcut uzmanın iletişim bilgileri için IANA ile iletişime geçin.)

RTP profil belirtimleri, profil başlığının kısa bir kısaltması olan xxx yerine geçmek üzere "RTP/xxx" biçiminde bir profil adı için IANA'ya kayıt YAPMALIDIR. Bu adlar, Session Description Protocol (SDP), RFC 2327 [15] gibi daha üst düzey denetim protokolleri tarafından taşıma yöntemlerine atıfta bulunmak için kullanılır.

#16. Fikri Mülkiyet Hakları Beyanı

IETF, bu belgede açıklanan teknolojinin uygulanması veya kullanımıyla ilgili olduğu iddia edilebilecek herhangi bir fikri mülkiyet veya diğer hakların geçerliliği ya da kapsamı konusunda veya bu tür haklar kapsamında herhangi bir lisansın mevcut olup olmadığı konusunda hiçbir tutum almamaktadır; ayrıca bu tür hakları belirlemek için herhangi bir çaba gösterdiğini de beyan etmez. IETF'nin standartlar yolundaki ve standartlarla ilişkili dokümantasyondaki haklara ilişkin prosedürleri hakkında bilgi BCP-11'de bulunabilir. Yayınlanmak üzere sunulan hak iddialarının kopyaları ve sağlanacağı belirtilen lisanslara ilişkin herhangi bir güvence veya bu belirtimin uygulayıcıları ya da kullanıcıları tarafından bu tür mülkiyet haklarının kullanımı için genel bir lisans ya da izin elde etme girişiminin sonucu, IETF Sekretaryası'ndan temin edilebilir.

IETF, bu standardın uygulanması için gerekli olabilecek teknolojiyi kapsayabilecek telif hakları, patentler veya patent başvuruları ya da diğer mülkiyet hakları hakkında bilgi sahibi olan ilgili tarafları, bu bilgileri dikkatine sunmaya davet eder. Lütfen bilgileri IETF İcra Direktörü'ne iletin.

#17. Teşekkürler

Bu memorandum, Stephen Casner ve Colin Perkins başkanlığındaki IETF Audio/Video Transport çalışma grubundaki tartışmalara dayanmaktadır. Mevcut protokolün kökenleri Network Voice Protocol ve Packet Video Protocol'e (Danny Cohen ve Randy Cole) ve vat uygulaması tarafından uygulanan protokole (Van Jacobson ve Steve McCanne) uzanmaktadır. Rastgele tanımlayıcı üreteci için fikirler Christian Huitema tarafından sağlanmıştır. Zamanlayıcı yeniden değerlendirme algoritmasının kapsamlı analizi ve simülasyonu Jonathan Rosenberg tarafından yapılmıştır. Katmanlı kodlamalar için eklemeler Michael Speer ve Steve McCanne tarafından belirtilmiştir.

#Ek A - Algoritmalar

RTP gönderici ve alıcı algoritmalarının bazı yönleri için C kodu örnekleri sunuyoruz. Belirli işletim ortamlarında daha hızlı olan veya başka avantajlara sahip başka uygulama yöntemleri de olabilir. Bu uygulama notları yalnızca bilgilendirme amaçlıdır ve RTP belirtimini açıklığa kavuşturmayı amaçlar.

Aşağıdaki tanımlar tüm örnekler için kullanılır; açıklık ve kısalık adına, yapı tanımları yalnızca 32 bit büyük uçlu (en anlamlı oktet önce) mimariler için geçerlidir. Bit alanlarının, ek dolgu olmaksızın büyük uçlu bit sırasına göre sıkı biçimde paketlendiği varsayılmaktadır. Taşınabilir bir uygulama oluşturmak için değişiklikler gerekecektir.

/*
 * rtp.h  --  RTP header file
 */
#include <sys/types.h>

/*
 * The type definitions below are valid for 32-bit architectures and
 * may have to be adjusted for 16- or 64-bit architectures.
 */
typedef unsigned char  u_int8;
typedef unsigned short u_int16;
typedef unsigned int   u_int32;
typedef          short int16;

/*
 * Current protocol version.
 */
#define RTP_VERSION    2

#define RTP_SEQ_MOD (1<<16)
#define RTP_MAX_SDES 255      /* maximum text length for SDES */

typedef enum {
    RTCP_SR   = 200,
    RTCP_RR   = 201,
    RTCP_SDES = 202,
    RTCP_BYE  = 203,
    RTCP_APP  = 204
} rtcp_type_t;

typedef enum {
    RTCP_SDES_END   = 0,
    RTCP_SDES_CNAME = 1,
    RTCP_SDES_NAME  = 2,
    RTCP_SDES_EMAIL = 3,
    RTCP_SDES_PHONE = 4,
    RTCP_SDES_LOC   = 5,
    RTCP_SDES_TOOL  = 6,
    RTCP_SDES_NOTE  = 7,
    RTCP_SDES_PRIV  = 8
} rtcp_sdes_type_t;

/*
 * RTP data header
 */
typedef struct {
    unsigned int version:2;   /* protocol version */
    unsigned int p:1;         /* padding flag */
    unsigned int x:1;         /* header extension flag */
    unsigned int cc:4;        /* CSRC count */
    unsigned int m:1;         /* marker bit */
    unsigned int pt:7;        /* payload type */
    unsigned int seq:16;      /* sequence number */
    u_int32 ts;               /* timestamp */
    u_int32 ssrc;             /* synchronization source */
    u_int32 csrc[1];          /* optional CSRC list */
} rtp_hdr_t;

/*
 * RTCP common header word
 */
typedef struct {
    unsigned int version:2;   /* protocol version */
    unsigned int p:1;         /* padding flag */
    unsigned int count:5;     /* varies by packet type */
    unsigned int pt:8;        /* RTCP packet type */
    u_int16 length;           /* pkt len in words, w/o this word */
} rtcp_common_t;

/*
 * Big-endian mask for version, padding bit and packet type pair
 */
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)

/*
 * Reception report block
 */
typedef struct {
    u_int32 ssrc;             /* data source being reported */
    unsigned int fraction:8;  /* fraction lost since last SR/RR */
    int lost:24;              /* cumul. no. pkts lost (signed!) */
    u_int32 last_seq;         /* extended last seq. no. received */
    u_int32 jitter;           /* interarrival jitter */
    u_int32 lsr;              /* last SR packet from this source */
    u_int32 dlsr;             /* delay since last SR packet */
} rtcp_rr_t;

/*
 * SDES item
 */
typedef struct {
    u_int8 type;              /* type of item (rtcp_sdes_type_t) */
    u_int8 length;            /* length of item (in octets) */
    char data[1];             /* text, not null-terminated */
} rtcp_sdes_item_t;

/*
 * One RTCP packet
 */
typedef struct {
    rtcp_common_t common;     /* common header */
    union {
        /* sender report (SR) */
        struct {
            u_int32 ssrc;     /* sender generating this report */
            u_int32 ntp_sec;  /* NTP timestamp */
            u_int32 ntp_frac;
            u_int32 rtp_ts;   /* RTP timestamp */
            u_int32 psent;    /* packets sent */
            u_int32 osent;    /* octets sent */
            rtcp_rr_t rr[1];  /* variable-length list */
        } sr;

        /* reception report (RR) */
        struct {
            u_int32 ssrc;     /* receiver generating this report */
            rtcp_rr_t rr[1];  /* variable-length list */
        } rr;

        /* source description (SDES) */
        struct rtcp_sdes {
            u_int32 src;      /* first SSRC/CSRC */
            rtcp_sdes_item_t item[1]; /* list of SDES items */
        } sdes;

        /* BYE */
        struct {
            u_int32 src[1];   /* list of sources */
            /* can't express trailing text for reason */
        } bye;
    } r;
} rtcp_t;

typedef struct rtcp_sdes rtcp_sdes_t;

/*
 * Per-source state information
 */
typedef struct {
    u_int16 max_seq;        /* highest seq. number seen */
    u_int32 cycles;         /* shifted count of seq. number cycles */
    u_int32 base_seq;       /* base seq number */
    u_int32 bad_seq;        /* last 'bad' seq number + 1 */
    u_int32 probation;      /* sequ. packets till source is valid */
    u_int32 received;       /* packets received */
    u_int32 expected_prior; /* packet expected at last interval */
    u_int32 received_prior; /* packet received at last interval */
    u_int32 transit;        /* relative trans time for prev pkt */
    u_int32 jitter;         /* estimated jitter */
    /* ... */
} source;

A.1 RTP Veri Başlığı Geçerlilik Denetimleri

Bir RTP alıcısı, gelen paketlerde RTP başlığının geçerliliğini denetlemelidir; çünkü bu paketler şifrelenmiş olabilir veya yanlış adreslenmiş, farklı bir uygulamadan geliyor olabilir. Benzer şekilde, Bölüm 9'da açıklanan yönteme göre şifreleme etkinleştirilmişse, gelen paketlerin doğru şekilde çözüldüğünü doğrulamak için başlık geçerlilik denetimi gereklidir; ancak başlık geçerlilik denetiminin başarısız olması (örn. bilinmeyen yük türü) mutlaka şifre çözme hatasına işaret etmeyebilir.

Daha önce hiç duyulmamış bir kaynaktan gelen bir RTP veri paketi üzerinde yalnızca zayıf geçerlilik denetimleri mümkündür:

  • RTP sürüm alanı 2'ye eşit olmalıdır.
  • Yük türü biliniyor olmalıdır ve özellikle SR veya RR'ye eşit olmamalıdır.
  • P biti ayarlıysa, paketin son okteti geçerli bir oktet sayısı içermelidir; özellikle, toplam paket uzunluğundan başlık boyutu çıkarıldığında kalan değerden küçük olmalıdır.
  • Profil başlık uzantısı mekanizmasının kullanılabileceğini belirtmiyorsa X biti sıfır olmalıdır. Aksi halde, uzantı uzunluğu alanı, sabit başlık uzunluğu ve dolgu çıkarıldıktan sonra kalan toplam paket boyutundan küçük olmalıdır.
  • Paketin uzunluğu, CC ve yük türüyle tutarlı olmalıdır (yüklerin bilinen bir uzunluğu varsa).

Son üç denetim bir miktar karmaşıktır ve her zaman mümkün değildir; geriye yalnızca toplamda birkaç bitten oluşan ilk iki denetim kalır. Paketteki SSRC tanımlayıcısı daha önce alınmışsa, paket büyük olasılıkla geçerlidir ve sıra numarasının beklenen aralıkta olup olmadığının denetlenmesi ek doğrulama sağlar. SSRC tanımlayıcısı daha önce görülmemişse, bu tanımlayıcıyı taşıyan veri paketleri, ardışık sıra numaralarına sahip küçük bir sayı gelene kadar geçersiz kabul edilebilir. Bu geçersiz paketler ATILABİLİR ya da ortaya çıkan gecikme kabul edilebilirse doğrulama sağlandıktan sonra saklanıp teslim EDİLEBİLİR.

Aşağıda gösterilen update_seq yordamı, bir kaynağın yalnızca MIN_SEQUENTIAL adet paket sıralı olarak alındıktan sonra geçerli ilan edilmesini sağlar. Ayrıca yeni alınan bir paketin sıra numarası seq'i doğrular ve s'nin işaret ettiği yapı içinde paketin kaynağı için sıra durumunu günceller.

Yeni bir kaynak ilk kez duyulduğunda, yani SSRC tanımlayıcısı tabloda yoksa (Bkz. Bölüm 8.2) ve kaynak başına durum bunun için ayrıldığında, s->probation, bir kaynağı geçerli ilan etmeden önce gereken ardışık paket sayısına (parametre MIN_SEQUENTIAL) ayarlanır ve diğer değişkenler başlatılır:

init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;

Sıfırdan farklı bir s->probation, kaynağı henüz geçerli değil olarak işaretler; böylece Bölüm 6.2.1'de tartışıldığı üzere, durum uzun bir zaman aşımı yerine kısa bir zaman aşımından sonra atılabilir.

Bir kaynak geçerli kabul edildikten sonra, sıra numarası, s->max_seq'in en fazla MAX_DROPOUT kadar önünde ve en fazla MAX_MISORDER kadar gerisinde değilse geçerli kabul edilir. Yeni sıra numarası, RTP sıra numarası aralığına (16 bit) göre max_seq'in önündeyse ancak max_seq'ten küçükse, sarma gerçekleşmiştir ve sıra numarası çevrimlerinin (kaydırılmış) sayısı artırılır. Geçerli bir sıra numarasını belirtmek için bir değeri döndürülür.

Aksi halde, doğrulamanın başarısız olduğunu belirtmek için sıfır değeri döndürülür ve hatalı sıra numarası artı 1 saklanır. Alınan bir sonraki paket bir sonraki daha yüksek sıra numarasını taşıyorsa, bunun büyük olasılıkla uzun süreli bir kesinti ya da bir kaynak yeniden başlatması nedeniyle oluşan yeni bir paket dizisinin geçerli başlangıcı olduğu kabul edilir. Birden fazla tam sıra numarası çevrimi kaçırılmış olabileceğinden, paket kaybı istatistikleri sıfırlanır.

Parametreler için tipik değerler, saniyede 50 paket hızında 2 saniyelik maksimum sırasızlık süresi ve 1 dakikalık maksimum kesinti temel alınarak gösterilmiştir. Kesinti parametresi MAX_DROPOUT, yeniden başlatmadan sonraki yeni sıra numaralarının, yeniden başlatmadan önceki sıra numaraları için kabul edilebilir aralığa düşmeme olasılığını makul kılmak üzere 16 bitlik sıra numarası uzayının küçük bir kesri olmalıdır.

void init_seq(source *s, u_int16 seq)
{
    s->base_seq = seq;
    s->max_seq = seq;
    s->bad_seq = RTP_SEQ_MOD + 1;   /* so seq == bad_seq is false */
    s->cycles = 0;
    s->received = 0;
    s->received_prior = 0;
    s->expected_prior = 0;
    /* other initialization */
}

int update_seq(source *s, u_int16 seq)
{
    u_int16 udelta = seq - s->max_seq;
    const int MAX_DROPOUT = 3000;
    const int MAX_MISORDER = 100;
    const int MIN_SEQUENTIAL = 2;

/*

  • Kaynak, ardışık sıra numaralarına sahip MIN_SEQUENTIAL paket
  • alınana kadar geçerli sayılmaz.

/ if (s->probation) { / paket sırada / if (seq == s->max_seq + 1) { s->probation--; s->max_seq = seq; if (s->probation == 0) { init_seq(s, seq); s->received++; return 1; } } else { s->probation = MIN_SEQUENTIAL - 1; s->max_seq = seq; } return 0; } else if (udelta < MAX_DROPOUT) { / izin verilen boşlukla birlikte sırada / if (seq < s->max_seq) { /

  • Sıra numarası başa sardı - bir 64K döngü daha say.

/ s->cycles += RTP_SEQ_MOD; } s->max_seq = seq; } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { / sıra numarası çok büyük bir sıçrama yaptı / if (seq == s->bad_seq) { /

  • İki ardışık paket -- karşı tarafın bize bildirmeden
  • yeniden başlattığını varsay ve yeniden senkronize et
  • (yani bunun ilk paket olduğunu varsay).

/ init_seq(s, seq); } else { s->bad_seq = (seq + 1) & (RTP_SEQ_MOD - 1); return 0; } } else { / yinelenmiş veya yeniden sıralanmış paket */ } s->received++; return 1; }


Geçerlilik denetimi, ardışık olarak ikiden fazla paket gerektirecek şekilde daha güçlü yapılabilir. Dezavantajları, başlangıçtaki daha fazla sayıda paketin atılacak (veya bir kuyrukta geciktirilecek) olması ve yüksek paket kaybı oranlarının doğrulamayı engelleyebilmesidir. Ancak RTCP başlık doğrulaması görece güçlü olduğundan, veri paketlerinden önce bir kaynaktan bir RTCP paketi alınırsa, yalnızca iki paketin ardışık olmasının yeterli olması için sayaç ayarlanabilir. Başlangıçtaki veri kaybının birkaç saniye boyunca tolere edilebildiği durumlarda, bir uygulama, ilgili kaynaktan geçerli bir RTCP paketi alınana kadar o kaynaktan gelen tüm veri paketlerini atmayı SEÇEBİLİR.

Uygulamaya ve kodlamaya bağlı olarak, algoritmalar ek doğrulama için yük biçimi hakkında ek bilgiden yararlanabilir. Zaman damgası artışının tüm paketler için aynı olduğu yük türlerinde, zaman damgası değerleri, sıra numarası farkı kullanılarak (yük türünde bir değişiklik olmadığı varsayımıyla) aynı kaynaktan alınan önceki paketten tahmin edilebilir.

Güçlü bir "hızlı-yol" denetimi mümkündür; çünkü yüksek olasılıkla yeni alınan bir RTP veri paketinin başlığındaki ilk dört oktet, sıra numarasının bir artmış olması dışında, aynı SSRC’den gelen önceki paketle tamamen aynı olacaktır. Benzer şekilde, verinin genellikle aynı anda tek bir kaynaktan alındığı uygulamalarda, SSRC aramalarını hızlandırmak için tek girişli bir önbellek kullanılabilir.

## A.2 RTCP Başlık Geçerlilik Denetimleri

Aşağıdaki denetimler RTCP paketlerine uygulanmalıdır.

- RTP sürüm alanı 2’ye eşit olmalıdır.

- Bileşik bir paketteki ilk RTCP paketinin yük türü alanı SR veya RR’ye eşit olmalıdır.

- Dolgu biti (P), bileşik bir RTCP paketinin ilk paketi için sıfır olmalıdır; çünkü dolgu, gerekirse, yalnızca son pakete uygulanmalıdır.

- Tek tek RTCP paketlerinin uzunluk alanları, alındığı şekliyle bileşik RTCP paketinin toplam uzunluğunu vermelidir. Bu oldukça güçlü bir denetimdir.

Aşağıdaki kod parçası bu denetimlerin tümünü gerçekleştirir. Bilinmeyen paket türleri bulunabileceği ve yok sayılması gerektiği için, sonraki paketler için paket türü denetlenmez.

u_int32 len; / sözcük cinsinden bileşik RTCP paketinin uzunluğu / rtcp_t r; / RTCP başlığı / rtcp_t end; / bileşik RTCP paketinin sonu /

if (((u_int16 )r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { / paket biçiminde bir sorun var / } end = (rtcp_t )((u_int32 )r + len);

do r = (rtcp_t )((u_int32 )r + r->common.length + 1); while (r < end && r->common.version == 2);

if (r != end) { / paket biçiminde bir sorun var / }


## A.3 Beklenen ve Kaybedilen Paket Sayısının Belirlenmesi

Paket kaybı oranlarını hesaplamak için, her bir kaynaktan beklenen ve gerçekte alınan RTP paketlerinin sayısının bilinmesi gerekir; bu, aşağıdaki kodda `s` işaretçisi aracılığıyla başvurulan `struct source` içinde tanımlanan kaynak başına durum bilgisi kullanılarak yapılır. Alınan paket sayısı, geç gelen veya yinelenmiş paketler de dahil olmak üzere, paketler geldikçe yapılan basit bir sayımdır. Beklenen paket sayısı ise alıcı tarafından, alınan en yüksek sıra numarası (`s->max_seq`) ile alınan ilk sıra numarası (`s->base_seq`) arasındaki fark olarak hesaplanabilir. Sıra numarası yalnızca 16 bit olduğundan ve başa saracağından, en yüksek sıra numarasını, sıra numarası başa sarmalarının (kaydırılmış) sayısı (`s->cycles`) ile genişletmek gerekir. Hem alınan paket sayısı hem de döngü sayısı, Ek A.1’deki RTP başlık geçerlilik denetimi yordamı tarafından tutulur.

extended_max = s->cycles + s->max_seq; expected = extended_max - s->base_seq + 1;


Kaybedilen paket sayısı, beklenen paket sayısından gerçekte alınan paket sayısının çıkarılması olarak tanımlanır:

lost = expected - s->received;


Bu işaretli sayı 24 bit içinde taşındığından, başa sarmak yerine, pozitif kayıp için `0x7fffff` veya negatif kayıp için `0x800000` değerlerinde sınırlandırılmalıdır.

Son raporlama aralığı sırasında (önceki SR veya RR paketi gönderildiğinden beri) kaybedilen paketlerin oranı, aralık boyunca beklenen ve alınan paket sayılarındaki farklardan hesaplanır; burada `expected_prior` ve `received_prior`, önceki alım raporu üretildiğinde kaydedilen değerlerdir:

expected_interval = expected - s->expected_prior; s->expected_prior = expected; received_interval = s->received - s->received_prior; s->received_prior = s->received; lost_interval = expected_interval - received_interval; if (expected_interval == 0 || lost_interval <= 0) fraction = 0; else fraction = (lost_interval << 8) / expected_interval;


Ortaya çıkan kesir, ikili noktası sol kenarda olan 8 bitlik sabit noktalı bir sayıdır.

## A.4 RTCP SDES Paketlerinin Üretilmesi

Bu işlev, `type`, `value` ve `length` dizilerinde sağlanan `argc` öğeden oluşan bir SDES parçasını `b` arabelleğine oluşturur. `b` içinde bir sonraki kullanılabilir konuma bir işaretçi döndürür.

char rtp_write_sdes(char b, u_int32 src, int argc, rtcp_sdes_type_t type[], char value[], int length[]) { rtcp_sdes_t s = (rtcp_sdes_t )b; rtcp_sdes_item_t rsp; int i; int len; int pad;

/ SSRC başlığı / s->src = src; rsp = &s->item[0];

/ SDES öğeleri / for (i = 0; i < argc; i++) { rsp->type = type[i]; len = length[i]; if (len > RTP_MAX_SDES) { / geçersiz uzunluk, başka bir eylem gerekebilir / len = RTP_MAX_SDES; } rsp->length = len; memcpy(rsp->data, value[i], len); rsp = (rtcp_sdes_item_t *)&rsp->data[len]; }

/ bitiş işareti ile sonlandır ve bir sonraki 4-oktet sınırına doldur / len = ((char )rsp) - b; pad = 4 - (len & 0x3); b = (char )rsp; while (pad--) *b++ = RTCP_SDES_END;

return b; }


## A.5 RTCP SDES Paketlerinin Ayrıştırılması

Bu işlev bir SDES paketini ayrıştırır; SSRC tanımlayıcısı verilen bir oturum üyesi için bilgiye işaretçi bulmak üzere `find_member()` ve o üye için yeni SDES bilgisini saklamak üzere `member_sdes()` işlevlerini çağırır. Bu işlev, RTCP paketinin başlığına bir işaretçi bekler.

void rtp_read_sdes(rtcp_t r) { int count = r->common.count; rtcp_sdes_t sd = &r->r.sdes; rtcp_sdes_item_t rsp, rspn; rtcp_sdes_item_t end = (rtcp_sdes_item_t ) ((u_int32 )r + r->common.length + 1); source s;

while (--count >= 0) { rsp = &sd->item[0]; if (rsp >= end) break; s = find_member(sd->src);

for (; rsp->type; rsp = rspn) { rspn = (rtcp_sdes_item_t )((char )rsp + rsp->length + 2); if (rspn >= end) { rsp = rspn; break; } member_sdes(s, rsp->type, rsp->data, rsp->length); } sd = (rtcp_sdes_t ) ((u_int32 )sd + (((char )rsp - (char )sd) >> 2) + 1); } if (count >= 0) { / geçersiz paket biçimi / } }


## A.6 Rastgele 32-bitlik Bir Tanımlayıcı Üretilmesi

Aşağıdaki alt yordam, RFC 1321 [32]’de yayımlanan MD5 yordamlarını kullanarak rastgele bir 32-bit tanımlayıcı üretir. Sistem yordamları tüm işletim sistemlerinde bulunmayabilir, ancak hangi tür bilgilerin kullanılabileceğine dair ipuçları sunmalıdır. Uygun olabilecek diğer sistem çağrıları şunları içerir:

- `getdomainname()`,
- `getwd()`, veya
- `getrusage()`.

"Canlı" video veya ses örnekleri de rastgele sayılar için iyi bir kaynaktır; ancak kapalı bir mikrofonun veya körlenmiş bir kameranın kaynak olarak kullanılmasından kaçınmak için dikkatli olunmalıdır [17].

Bu veya benzeri bir yordamın, RTCP dönemini üreten rastgele sayı üretecinin başlangıç tohumunu (Ek A.7’de gösterildiği gibi) üretmek, sıra numarası ve zaman damgası için başlangıç değerlerini üretmek ve SSRC değerlerini üretmek için kullanılması önerilir. Bu yordamın CPU yoğun olması muhtemel olduğundan, öngörülebilirlik bir sorun olmadığı için RTCP dönemlerini doğrudan üretmek amacıyla kullanılması uygun değildir. Farklı `type` argüman değerleri sağlanmadıkça, sistem saatinin değeri değişene kadar bu yordamın tekrarlanan çağrılarda aynı sonucu ürettiğine dikkat edin.

/*

  • Rastgele bir 32-bit nicelik üret.

/ #include <sys/types.h> / u_long / #include <sys/time.h> / gettimeofday() / #include <unistd.h> / get..() / #include <stdio.h> / printf() / #include <time.h> / clock() / #include <sys/utsname.h> / uname() / #include "global.h" / RFC 1321'den / #include "md5.h" / RFC 1321'den */

#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final

static u_long md_32(char *string, int length) { MD_CTX context; union { char c[16]; u_long x[4]; } digest; u_long r; int i;

MDInit(&context); MDUpdate(&context, string, length); MDFinal((unsigned char )&digest, &context); r = 0; for (i = 0; i < 3; i++) { r ^= digest.x[i]; } return r; } / md_32 */

/*

  • Rastgele işaretsiz 32-bit nicelik döndür.
  • Yakın aralıklarla birkaç farklı değer üretmeniz gerekiyorsa
  • 'type' argümanını kullanın.

*/ u_int32 random32(int type) { struct { int type; struct timeval tv; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s;

gettimeofday(&s.tv, 0); uname(&s.name); s.type = type; s.cpu = clock(); s.pid = getpid(); s.hid = gethostid(); s.uid = getuid(); s.gid = getgid(); / ayrıca: sistem çalışma süresi /

return md_32((char )&s, sizeof(s)); } / random32 */


## A.7 RTCP İletim Aralığının Hesaplanması

Aşağıdaki işlevler, Bölüm 6.2’de açıklanan RTCP iletim ve alım kurallarını uygular. Bu kurallar birkaç işlevde kodlanmıştır:

- **rtcp_interval()** saniye cinsinden ölçülen deterministik hesaplanmış aralığı hesaplar. Parametreler Bölüm 6.3’te tanımlanmıştır.
- **OnExpire()** RTCP iletim zamanlayıcısının süresi dolduğunda çağrılır.
- **OnReceive()** bir RTCP paketi alındığında çağrılır.

Hem **OnExpire()** hem de **OnReceive()**, argüman olarak olay *e*’yi alır. Bu, o katılımcı için bir sonraki zamanlanmış olaydır; ya bir RTCP raporu ya da bir BYE paketidir. Aşağıdaki işlevlerin mevcut olduğu varsayılır:

- **Schedule(time t, event e)**, *e* olayını *t* zamanında gerçekleşecek şekilde zamanlar. *t* zamanı geldiğinde **OnExpire** işlevi *e* argümanıyla çağrılır.
- **Reschedule(time t, event e)**, daha önce zamanlanmış bir *e* olayını *t* zamanı için yeniden zamanlar.
- **SendRTCPReport(event e)** bir RTCP raporu gönderir.
- **SendBYEPacket(event e)** bir BYE paketi gönderir.
- **TypeOfEvent(event e)**, işlenen olay gönderilecek bir BYE paketi içinse `EVENT_BYE`, aksi halde `EVENT_REPORT` döndürür.
- **PacketType(p)**, paket *p* bir RTCP raporuysa (BYE değil) `PACKET_RTCP_REPORT`, bir BYE RTCP paketi ise `PACKET_BYE`, normal bir RTP veri paketi ise `PACKET_RTP` döndürür.
- **ReceivedPacketSize()** ve **SentPacketSize()**, başvurulan paketin oktet cinsinden boyutunu döndürür.
- **NewMember(p)**, paket *p*’yi gönderen katılımcı şu anda üye listesinde değilse 1, aksi halde 0 döndürür. Bu işlevin tam bir uygulama için yeterli olmadığına dikkat edin; çünkü bir RTP paketindeki her CSRC tanımlayıcısı ve bir BYE paketindeki her SSRC işlenmelidir.
- **NewSender(p)**, paket *p*’yi gönderen katılımcı şu anda üye listesinin gönderici alt listesinde değilse 1, aksi halde 0 döndürür.
- **AddMember()** ve **RemoveMember()**, katılımcıları üye listesine ekler ve listeden çıkarır.
- **AddSender()** ve **RemoveSender()**, katılımcıları üye listesinin gönderici alt listesine ekler ve listeden çıkarır.

Bu işlevlerin, göndericiler ve gönderici olmayanlar için RTCP bant genişliği oranlarının %25 ve %75 gibi sabit değerler yerine açık parametreler olarak belirtilebildiği bir uygulama için genişletilmesi gerekir. **rtcp_interval()** işlevinin genişletilmiş uygulaması, parametrelerden biri sıfırsa sıfıra bölmeyi önlemek zorunda olacaktır.

double rtcp_interval(int members, int senders, double rtcp_bw, int we_sent, double avg_rtcp_size, int initial) { /*

  • Bu uçtan gönderilen RTCP paketleri arasındaki minimum ortalama
  • süre (saniye cinsinden). Bu süre, oturumlar küçük olduğunda ve
  • büyük sayılar yasası trafiği yumuşatmaya yardımcı olmadığında
  • raporların "kümeleşmesini" önler. Ayrıca ağ bölünmesi gibi
  • geçici kesintiler sırasında rapor aralığının gülünç derecede
  • küçük hale gelmesini engeller.

/ double const RTCP_MIN_TIME = 5.; /

  • RTCP bant genişliğinin aktif göndericiler arasında paylaşılacak
  • kısmı. (Bu oran, tipik olarak bir veya iki aktif göndericinin
  • bulunduğu bir oturumda hesaplanan rapor süresinin yaklaşık
  • minimum rapor süresine eşit olması için seçilmiştir; böylece
  • alıcı raporlarını gereksiz yere yavaşlatmayız.) Alıcı payı,
  • gönderici payının 1 eksiği olmalıdır.

/ double const RTCP_SENDER_BW_FRACTION = 0.25; double const RTCP_RCVR_BW_FRACTION = (1 - RTCP_SENDER_BW_FRACTION); /

  • "Zamanlayıcı yeniden değerlendirmesinin" hedeflenen ortalamanın
  • altındaki bir değere yakınsamasını telafi etmek için.

*/ double const COMPENSATION = 2.71828 - 1.5;

double t; / aralık / double rtcp_min_time = RTCP_MIN_TIME; int n; / hesaplama için üye sayısı /

/*

  • Uygulama başlangıcındaki ilk çağrı, daha hızlı bildirim için
  • minimum gecikmenin yarısını kullanır; aynı zamanda
  • rastgeleleştirme ve diğer kaynaklar hakkında bilgi edinmek için
  • raporlama öncesinde bir miktar süre tanır; böylece rapor aralığı
  • doğru aralığa daha hızlı yakınsar.

/ if (initial) { rtcp_min_time /= 2; } /

  • Gönderici sayısı, kendi paylarının bu orandan fazla olacağı
  • kadar büyük değilse, RTCP bant genişliğinin bir kısmını
  • göndericilere ayır.

/ n = members; if (senders <= members RTCP_SENDER_BW_FRACTION) { if (we_sent) { rtcp_bw = RTCP_SENDER_BW_FRACTION; n = senders; } else { rtcp_bw = RTCP_RCVR_BW_FRACTION; n -= senders; } }

/*

  • Etkin uç sayısının ortalama paket boyutuyla çarpımı, her uç bir
  • rapor gönderdiğinde gönderilen toplam oktet sayısıdır. Bunun
  • etkin bant genişliğine bölünmesi, bant genişliği hedefini
  • karşılamak için bu paketlerin gönderilmesi gereken zaman
  • aralığını verir; minimum bir değer zorlanır. Bu zaman aralığında
  • bir rapor göndeririz; dolayısıyla bu süre raporlar arasındaki
  • ortalama süremizdir.

/ t = avg_rtcp_size n / rtcp_bw; if (t < rtcp_min_time) t = rtcp_min_time;

/*

  • Diğer uçlarla istenmeyen senkronizasyondan kaynaklanan trafik
  • patlamalarını önlemek için, gerçek bir sonraki rapor aralığını
  • 0.5t ile 1.5t arasında düzgün dağılımlı rastgele bir sayı
  • olarak seçeriz.

/ t = t (drand48() + 0.5); t = t / COMPENSATION; return t; }

void OnExpire(event e, int members, int senders, double rtcp_bw, int we_sent, double avg_rtcp_size, int initial, time_tp tc, time_tp tp, int pmembers) { /* Bu fonksiyon, şu anda bir RTCP raporu mu yoksa bir BYE paketi mi

  • gönderileceğine ya da iletimin yeniden zamanlanıp
  • zamanlanmayacağına karar vermekten sorumludur. Ayrıca pmembers,
  • initial, tp ve avg_rtcp_size durum değişkenlerini günceller. Bu
  • fonksiyon, Schedule() tarafından kullanılan olay zamanlayıcısı
  • sona erdiğinde çağrılmalıdır.

*/

double t; / Aralık / double tn; / Bir sonraki iletim zamanı /

/* BYE durumunda, gerekirse BYE iletimini yeniden zamanlamak için

  • "zamanlayıcı yeniden değerlendirmesi" kullanırız */

if (TypeOfEvent(e) == EVENT_BYE) { t = rtcp_interval(members, senders, rtcp_bw, we_sent, avg_rtcp_size, initial); tn = *tp + t; if (tn <= tc) { SendBYEPacket(e); exit(1); } else { Schedule(tn, e); }

} else if (TypeOfEvent(e) == EVENT_REPORT) { t = rtcp_interval(members, senders, rtcp_bw, we_sent, avg_rtcp_size, initial); tn = tp + t; if (tn <= tc) { SendRTCPReport(e); avg_rtcp_size = (1./16.) SentPacketSize(e) + (15./16.) (avg_rtcp_size); tp = tc;

/* Aralığı yeniden çekmeliyiz. Yukarıda hesaplananı

  • yeniden kullanmayın; çünkü bu, bir paketin
  • gönderilmesine neden olacak kadar küçük olması
  • koşuluna bağlıdır ve aynı şekilde dağıtılmış değildir */

t = rtcp_interval(members, senders, rtcp_bw, we_sent, avg_rtcp_size, initial);

Schedule(t + tc, e); initial = 0; } else { Schedule(tn, e); } pmembers = members; } }

void OnReceive(packet p, event e, int members, int pmembers, int senders, double avg_rtcp_size, double tp, double tc, double tn) { / Ne yapacağımız, gruptan ayrılıp bir BYE göndermeyi bekleyip

  • beklemediğimize (TypeOfEvent(e) == EVENT_BYE) ya da bir RTCP
  • raporu gönderip göndermediğimize bağlıdır. p, az önce alınan
  • paketi temsil eder. */

if (PacketType(p) == PACKET_RTCP_REPORT) { if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) { AddMember(p); members += 1; } avg_rtcp_size = (1./16.) ReceivedPacketSize(p) + (15./16.) (avg_rtcp_size); } else if (PacketType(p) == PACKET_RTP) { if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) { AddMember(p); members += 1; } if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) { AddSender(p); senders += 1; } } else if (PacketType(p) == PACKET_BYE) { avg_rtcp_size = (1./16.) ReceivedPacketSize(p) + (15./16.) (*avg_rtcp_size);

if (TypeOfEvent(e) == EVENT_REPORT) { if (NewSender(p) == FALSE) { RemoveSender(p); *senders -= 1; }

if (NewMember(p) == FALSE) { RemoveMember(p); *members -= 1; }

if (members < pmembers) { tn = tc + (((double)members) / (pmembers)) (tn - tc); tp = tc - (((double)members) / (pmembers)) (tc - tp);

/ Bir sonraki raporu tn zamanı için yeniden zamanla /

Reschedule(tn, e); pmembers = members; }

} else if (TypeOfEvent(e) == EVENT_BYE) { *members += 1; } } }


## A.8 Varışlar Arası Jitter'ın Tahmini

Aşağıdaki kod parçaları, alım raporlarının varışlar arası jitter alanına yerleştirilecek RTP veri paketleri varışlar arası zamanının istatistiksel varyansına yönelik bir tahmini hesaplamak için Bölüm 6.4.1'de verilen algoritmayı uygular. Girdiler, gelen paketten alınan zaman damgası `r->ts` ve aynı birimlerdeki geçerli zaman olan `arrival`'dır. Burada `s`, kaynak için durumu işaret eder; `s->transit`, önceki paket için göreli geçiş süresini, `s->jitter` ise tahmin edilen jitter'ı tutar. Alım raporunun jitter alanı zaman damgası birimlerinde ölçülür ve işaretsiz bir tamsayı olarak ifade edilir; ancak jitter tahmini kayan nokta olarak tutulur. Her veri paketi geldiğinde jitter tahmini güncellenir:

int transit = arrival - r->ts; int d = transit - s->transit; s->transit = transit; if (d < 0) d = -d; s->jitter += (1./16.) * ((double)d - s->jitter);


Bu üye için bir alım raporu bloğu (işaretçisi `rr`) oluşturulduğunda, geçerli jitter tahmini döndürülür:

rr->jitter = (u_int32) s->jitter;


Alternatif olarak, jitter tahmini tamsayı olarak tutulabilir, ancak yuvarlama hatasını azaltmak için ölçeklenir. Hesaplama aynıdır; yalnızca son satır farklıdır:

s->jitter += d - ((s->jitter + 8) >> 4);


Bu durumda, alım raporu için tahmin şu şekilde örneklenir:

rr->jitter = s->jitter >> 4;


---

## Ek B - RFC 1889'dan Değişiklikler

Bu RFC'nin büyük bölümü RFC 1889 ile aynıdır. Kabloda iletilen paket biçimlerinde değişiklik yoktur; yalnızca protokolün nasıl kullanıldığını belirleyen kural ve algoritmalarda değişiklikler vardır. En büyük değişiklik, RTCP paketlerinin ne zaman gönderileceğini hesaplayan ölçeklenebilir zamanlayıcı algoritmasındaki iyileştirmedir:

- Bölüm 6.2 ve 6.3'te belirtilen ve Ek A.7'de gösterilen RTCP iletim aralığını hesaplama algoritması, birçok katılımcının aynı anda bir oturuma katılması durumunda hedeflenen oranın üzerindeki iletimi en aza indirmek için *yeniden değerlendirme* ve katılımcı sayısı hızla düştüğünde hatalı katılımcı zaman aşımı olaylarının sıklığını ve süresini azaltmak için *ters yeniden değerlendirme* içerecek şekilde genişletilmiştir. Ters yeniden değerlendirme, pasif alıcı modundan aktif gönderici moduna geçerken RTCP SR göndermeden önceki gecikmeyi olası olarak kısaltmak için de kullanılır.

- Bölüm 6.3.7, birçok katılımcının aynı anda bir oturumdan ayrılması durumunda paket selini önlemek amacıyla bir RTCP BYE paketinin ne zaman gönderileceğini denetleyen yeni kuralları tanımlar.

- Bölüm 6.2.1'de, etkin olmayan katılımcılar için durumu tipik ağ bölünmelerini kapsayacak kadar uzun bir süre tutma gereksinimi kaldırılmıştır. Birçok katılımcının kısa bir süre için katıldığı ve BYE göndermediği bir oturumda bu gereksinim, katılımcı sayısının önemli ölçüde fazla tahmin edilmesine yol açardı. Bu revizyonda eklenen yeniden değerlendirme algoritması, bir bölünme iyileştiğinde aynı anda katılan çok sayıdaki yeni katılımcıyı telafi eder.

Bu iyileştirmelerin yalnızca oturum katılımcılarının sayısı büyük (binlerce) olduğunda ve katılımcıların çoğu aynı anda katılıp ayrıldığında belirgin bir etkiye sahip olduğu not edilmelidir. Bu durum, canlı bir ağda test etmeyi zorlaştırır. Bununla birlikte, algoritma performansını doğrulamak için kapsamlı bir analiz ve simülasyona tabi tutulmuştur. Ayrıca, geliştirilmiş algoritma RFC 1889'daki algoritma ile birlikte çalışacak şekilde tasarlanmıştır; böylece adım şeklinde katılım sırasında fazla RTCP bant genişliğindeki azalmanın derecesi, geliştirilmiş algoritmayı uygulayan katılımcıların oranıyla orantılıdır. İki algoritmanın birlikte çalışabilirliği canlı ağlarda deneysel olarak doğrulanmıştır.

Diğer işlevsel değişiklikler şunlardır:

- Bölüm 6.2.1, çok büyük oturumlara ölçeklenebilirliği sağlamak için uygulamaların katılımcıların SSRC tanımlayıcılarının yalnızca bir örneklemesini saklayabileceğini belirtir. Algoritmalar RFC 2762 [21]'de tanımlanmıştır.

- Bölüm 6.2'de, RTCP gönderici ve gönderici olmayan bant genişliklerinin, oturum bant genişliğinin katı bir yüzdesi yerine oturumun ayrı parametreleri olarak ayarlanabileceği ve sıfıra ayarlanabileceği belirtilmiştir. IP multicast kullanan RTP oturumları için RTCP'nin zorunlu olması gereksinimi gevşetilmiştir. Ancak, RTCP'nin kapatılmasının **ÖNERİLMEDİĞİ** yönünde bir açıklama da eklenmiştir.

- Bölüm 6.2, 6.3.1 ve Ek A.7'de, göndericilere adanmış RTCP bant genişliği verilen katılımcı oranının, sabit 1/4 yerine RTCP gönderici ve gönderici olmayan bant genişliği parametrelerine dayalı bir orana dönüştüğü belirtilmiştir. Gönderici olmadığında göndericilere bant genişliği ayrılmaması koşulu kaldırılmıştır; çünkü bunun geçici bir durum olması beklenir. Bu ayrıca, amaçlanmadığı durumlarda gönderici olmayanların gönderici RTCP bant genişliğini kullanmasını engeller.

- Yine Bölüm 6.2'de, minimum RTCP aralığının yüksek bant genişlikli oturumlar için daha küçük değerlere ölçeklenebileceği ve başlangıç RTCP gecikmesinin tekil iletim (unicast) oturumları için sıfıra ayarlanabileceği belirtilmiştir.

- Bir katılımcının zaman aşımına uğraması, aktif göndericiler için bile alıcı RTCP bant genişliği payı kullanılarak hesaplanan bir dizi RTCP rapor aralığı boyunca hareketsizliğe dayanmalıdır.

- Bölüm 7.2 ve 7.3, çeviricilerin ve karıştırıcıların artık iletmedikleri kaynaklar için BYE paketleri göndermesi gerektiğini belirtir.

- Katmanlı kodlamalar için kural değişiklikleri Bölüm 2.4, 6.3.9, 8.3 ve 11'de tanımlanmıştır. Bunların sonuncusunda, adres ve port atama kuralının SDP belirtimi RFC 2327 [15] ile çeliştiği not edilir; ancak bu kısıtlamanın RFC 2327'nin bir revizyonunda gevşetilmesi amaçlanmaktadır.

- Bölüm 11'de RTP ve RTCP için çift/tek port çiftlerinin kullanımına ilişkin gelenek, hedef portlara atıfta bulunacak şekilde netleştirilmiştir. İki port açıkça belirtilmişse çift/tek port çifti kullanma gereksinimi kaldırılmıştır. Tekil iletimli RTP oturumları için, iki uçta farklı port çiftleri kullanılabilir (Bölüm 3, 7.1 ve 11).

- RTP kullanan uygulamalarda tıkanıklık denetimi gereksinimini açıklamak için yeni bir Bölüm 10 eklenmiştir.

- Bölüm 8.2'de, kaynak taşıma adresi değiştirildiğinde yeni bir SSRC tanımlayıcısının **SEÇİLMESİ GEREKTİĞİ** yönündeki gereksinim, yeni bir SSRC tanımlayıcısının **SEÇİLEBİLECEĞİ** şeklinde gevşetilmiştir. Buna paralel olarak, bir SSRC çakışması iki başka katılımcı arasında meydana geldiğinde, bir uygulamanın mevcut kaynak adresi yerine yeni kaynak adresinden gelen paketleri tutmayı **SEÇEBİLECEĞİ** ve mobil varlıklar gibi bazı kaynakların bir RTP oturumu sırasında adres değiştirebileceği telefon uygulamaları gibi durumlarda bunu **YAPMASI GEREKTİĞİ** açıklığa kavuşturulmuştur.

- Bölüm 8.2'deki çakışma algılama ve çözüm algoritması için RFC 1889 baskısında yer alan sözde kodun girinti hatası, sözdiziminin sözde C diline çevrilmesiyle düzeltilmiş ve algoritma, hem RTP hem de RTCP'nin aynı kaynak port numarasından gönderilmesi kısıtını kaldıracak şekilde değiştirilmiştir.

- RTCP paketleri için dolgu (padding) mekanizmasının açıklaması netleştirilmiş ve dolgunun **YALNIZCA** bileşik bir RTCP paketinin son paketine uygulanması **GEREKTİĞİ** belirtilmiştir.

- Bölüm A.1’de `base_seq` ilklendirmesi `seq - 1` yerine `seq` olacak şekilde düzeltildi ve metin, hatalı sıra numarasına 1 eklenmiş değerin saklandığını belirtecek şekilde düzeltildi. Algoritma için `max_seq` ve diğer değişkenlerin ilklendirilmesi, bu ilklendirmenin `init_seq()` fonksiyonunun çağrılmasına ek olarak yapılması gerektiğini açıkça göstermek amacıyla metinden ayrıldı (ve RFC 1889’da belgenin kaynaktan çıktı biçimine işlenmesi sırasında kaybolan birkaç kelime geri getirildi).

- Bölüm A.3’te kaybolan paket sayısının sınırlandırılması, hem pozitif hem de negatif sınırları kullanacak şekilde düzeltildi.

- RTCP SR bölümündeki "göreli" NTP zaman damgasının tanımı artık bu zaman damgalarının, aynı makinede farklı zamanlarda başlatılan birden fazla uygulama için aynı olmayacak olan oturum geçen süresine değil, sistem çalışma süresi gibi en yaygın sisteme özgü saate dayanmasını tanımlamaktadır.

### İşlevsel Olmayan Değişiklikler

- Bir alıcının, anlamadığı yük türlerine sahip paketleri **MUST** yok sayması gerektiği belirtilmiştir.

- Şekil 2’de, kayan nokta NTP zaman damgası değeri düzeltildi, bir onaltılık sayıya eksik bazı baştaki sıfırlar eklendi ve UTC zaman dilimi belirtildi.

- NTP zaman damgalarının 2036 yılında sıfırlanmasının önemsizliği açıklanmıştır.

- RTCP paket türleri ve SDES türlerinin kaydı için politika, yeni bir Bölüm 15 olan *IANA Hususları* içinde netleştirildi. Deney yapanların ihtiyaç duydukları numaraları kaydedip daha sonra gereksiz olduğu anlaşılanları kayıttan çıkarmaları yönündeki öneri kaldırılarak bunun yerine APP ve PRIV kullanımı tercih edildi. Profil adlarının kaydı da belirtildi.

- UTF-8 karakter kümesi için referans, X/Open Ön Spesifikasyonundan RFC 2279’a değiştirildi.

- RFC 1597 için referans RFC 1918’e, RFC 2543 için referans ise RFC 3261’e güncellendi.

- RFC 1889’daki giriş bölümünün, uygulayıcıları İnternet’te dağıtımı sınırlamaya karşı uyaran son paragrafı, artık geçerli olmadığı düşünüldüğü için kaldırıldı.

- Kaynağa Özgü Çoklu Yayın (SSM) ile RTP kullanımına ilişkin normatif olmayan bir not Bölüm 6’ya eklendi.

- Bölüm 3’teki "RTP oturumu" tanımı, tek bir oturumun birden fazla hedef taşıma adresi kullanabileceğini (çevirmen veya karıştırıcı için her zaman geçerli olduğu gibi) kabul edecek şekilde genişletildi ve bir RTP oturumunun ayırt edici özelliğinin her birinin ayrı bir SSRC tanımlayıcı uzayına karşılık gelmesi olduğu açıklandı. "Oturum" kelimesiyle ilgili karışıklığı azaltmak için yeni bir "multimedya oturumu" tanımı eklendi.

- Bölüm 5.1’de, RTP başlığının zaman damgası alanının tanımının bir parçası olarak "örnekleme anı"nın anlamı daha ayrıntılı şekilde açıklandı.

- Metnin çeşitli yerlerinde, bazıları okuyuculardan gelen sorulara yanıt olarak, küçük açıklamalar yapıldı. Özellikle:

  - RFC 1889’da, Bölüm 2.2’nin ikinci cümlesinin ilk beş kelimesi belgenin kaynaktan çıktı biçimine işlenmesi sırasında kaybolmuştu, ancak artık geri getirilmiştir.

  - Bölüm 3’te "RTP ortam türü" için bir tanım eklendi; böylece Bölüm 5.2’de RTP oturumlarının çoklanmasının açıklaması, birden fazla ortamın çoklanması konusunda daha net hale getirildi. Bu bölüm ayrıca, aynı ortamın birden fazla kaynağının SSRC tanımlayıcılarına dayalı olarak çoklanmasının uygun olabileceğini ve bunun çoklu yayın oturumları için norm olduğunu artık açıklamaktadır.

  - "RTP dışı yollar" tanımı, RTP dışı yolları oluşturan diğer protokollere örnekler içerecek şekilde genişletildi.

  - Oturum bant genişliği parametresinin açıklaması Bölüm 6.2’de genişletildi; buna, kontrol trafiği bant genişliğinin veri trafiği için kullanılan oturum bant genişliğine ek olduğu açıklaması da dahildir.

  - Değişken paket süresinin jitter hesaplaması üzerindeki etkisi Bölüm 6.4.4’te açıklandı.

  - SDES öğeleri dizisinin sonlandırılması ve doldurulması yöntemi Bölüm 6.5’te netleştirildi.

  - Bölüm 6.5.1’de SDES CNAME açıklamasına IPv6 adres örnekleri eklendi ve diğer örnek alan adları yerine "example.com" kullanıldı.

  - Güvenlik bölümü, artık mevcut olduğu için IPSEC’e resmi bir referans ekledi ve bu spesifikasyonda tanımlanan gizlilik yönteminin esas olarak mevcut uygulamayı kodlamak amacıyla olduğunu belirtmektedir. Varsayılan algoritma yerine Triple-DES gibi daha güçlü şifreleme algoritmalarının kullanılması **RECOMMENDED** edilmektedir ve AES’e dayalı SRTP profilinin gelecekte doğru seçim olacağı belirtilmiştir. RTP başlığının bir ilklendirme vektörü olarak zayıflığına dair bir uyarı eklendi. Ayrıca, başlık sıkıştırmaya izin vermek için yalnızca yükün şifrelenmesinin gerekli olduğu da not edildi.

  - RTCP’nin kısmi şifrelenmesi yöntemi netleştirildi; özellikle, bileşik RTCP paketi bölündüğünde SDES CNAME’in yalnızca tek bir parçada taşındığı belirtildi.

  - Her raporlama aralığı için yalnızca bir bileşik RTCP paketinin gönderilmesi gerektiği ve raporların MTU’ya sığması için çok fazla aktif kaynak varsa, kaynakların bir alt kümesinin birden fazla aralık boyunca round-robin yöntemiyle seçilmesi gerektiği açıklığa kavuşturuldu.

  - Ek A.1’e, RTP başlığı doğrulaması sırasında paketlerin kaydedilebileceği ve başarı durumunda iletilebileceği yönünde bir not eklendi.

  - Bölüm 7.3 artık, SDES paketlerini birleştiren bir karıştırıcının daha uzun paketler nedeniyle daha fazla RTCP bant genişliği kullandığını ve RTCP’yi olduğu gibi ileten bir karıştırıcının doğal olarak tek bir kaynak hızından daha yüksek hızda paket gönderdiğini, ancak her iki davranışın da geçerli olduğunu açıklamaktadır.

  - Bölüm 13, bir RTP uygulamasının birden fazla profil kullanabileceğini ancak tipik olarak belirli bir oturumda yalnızca bir tane kullandığını netleştirmektedir.

  - **MUST**, **SHOULD**, **MAY** vb. terimler RFC 2119’da tanımlandığı şekilde kullanılmaktadır.

  - Kaynakça, normatif ve bilgilendirici referanslar olarak ikiye ayrıldı.

---

## Referanslar

### Normatif Referanslar

1. Schulzrinne, H. ve S. Casner, *"Minimal Kontrol ile Ses ve Video Konferansları için RTP Profili"*, RFC 3551, Temmuz 2003.
2. Bradner, S., *"RFC’lerde Gereksinim Düzeylerini Belirtmek için Kullanılan Anahtar Sözcükler"*, BCP 14, RFC 2119, Mart 1997.
3. Postel, J., *"Internet Protocol"*, STD 5, RFC 791, Eylül 1981.
4. Mills, D., *"Network Time Protocol (Sürüm 3) Spesifikasyonu, Gerçekleştirme ve Analiz"*, RFC 1305, Mart 1992.
5. Yergeau, F., *"ISO 10646 için Bir Dönüşüm Biçimi Olarak UTF-8"*, RFC 2279, Ocak 1998.
6. Mockapetris, P., *"Alan Adları – Kavramlar ve Olanaklar"*, STD 13, RFC 1034, Kasım 1987.
7. Mockapetris, P., *"Alan Adları – Gerçekleştirme ve Spesifikasyon"*, STD 13, RFC 1035, Kasım 1987.
8. Braden, R., *"Internet Ana Bilgisayarları için Gereksinimler – Uygulama ve Destek"*, STD 3, RFC 1123, Ekim 1989.

[9] Resnick, P., "Internet Message Format", RFC 2822, Nisan 2001.

## Bilgilendirici Referanslar

[10] Clark, D. ve D. Tennenhouse, "Yeni Nesil Protokoller için Mimari Değerlendirmeler", *SIGCOMM İletişim Mimarileri ve Protokolleri Sempozyumu* içinde, (Philadelphia, Pennsylvania), s. 200--208, *IEEE Computer Communications Review*, Cilt 20(4), Eylül 1990.

[11] Schulzrinne, H., "Ses ve video konferansları ile diğer çok katılımcılı gerçek zamanlı uygulamalar için bir taşıma protokolü tasarlamadaki konular", süresi dolmuş Internet Taslağı, Ekim 1993.

[12] Comer, D., *TCP/IP ile Ağlararası İletişim*, cilt 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.

[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. ve E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Haziran 2002.

[14] Uluslararası Telekomünikasyon Birliği, "Hizmet kalitesi garanti edilmeyen yerel alan ağları için görsel telefon sistemleri ve ekipmanları", Tavsiye H.323, ITU Telekomünikasyon Standardizasyon Sektörü, Cenevre, İsviçre, Temmuz 2003.

[15] Handley, M. ve V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Nisan 1998.

[16] Schulzrinne, H., Rao, A. ve R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, Nisan 1998.

[17] Eastlake 3rd, D., Crocker, S. ve J. Schiller, "Güvenlik için Rastgelelik Önerileri", RFC 1750, Aralık 1994.

[18] Bolot, J.-C., Turletti, T. ve I. Wakeman, "Internet’te Çoklu Yayın Video Dağıtımı için Ölçeklenebilir Geri Bildirim Kontrolü", *SIGCOMM İletişim Mimarileri ve Protokolleri Sempozyumu* içinde, (Londra, İngiltere), s. 58--67, ACM, Ağustos 1994.

[19] Busse, I., Deffner, B. ve H. Schulzrinne, "RTP Tabanlı Multimedya Uygulamalarının Dinamik QoS Kontrolü", *Computer Communications*, cilt 19, s. 49--58, Ocak 1996.

[20] Floyd, S. ve V. Jacobson, "Periyodik Yönlendirme İletilerinin Senkronizasyonu", *SIGCOMM İletişim Mimarileri ve Protokolleri Sempozyumu* içinde (D. P. Sidhu, ed.), (San Francisco, California), s. 33--44, ACM, Eylül 1993. Ayrıca [34]’te.

[21] Rosenberg, J. ve H. Schulzrinne, "RTP’de Grup Üyeliğinin Örneklenmesi", RFC 2762, Şubat 2000.

[22] Cadzow, J., *Dijital Sinyal İşleme ve Veri Analizinin Temelleri*. New York, New York: Macmillan, 1987.

[23] Hinden, R. ve S. Deering, "Internet Protocol Sürüm 6 (IPv6) Adresleme Mimarisi", RFC 3513, Nisan 2003.

[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. ve E. Lear, "Özel Internetler için Adres Tahsisi", RFC 1918, Şubat 1996.

[25] Lear, E., Fair, E., Crocker, D. ve T. Kessler, "Network 10 Zararlı Kabul Edilmektedir (Bazı Uygulamalar Kodlanmamalıdır)", RFC 1627, Temmuz 1994.

[26] Feller, W., *Olasılık Teorisine ve Uygulamalarına Giriş*, cilt 1. New York, New York: John Wiley and Sons, üçüncü baskı, 1968.

[27] Kent, S. ve R. Atkinson, "Internet Protocol için Güvenlik Mimarisi", RFC 2401, Kasım 1998.

[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. ve D. Oran, "Secure Real-time Transport Protocol", Çalışma Taslağı, Nisan 2003.

[29] Balenson, D., "Internet Elektronik Postası için Gizlilik Geliştirmesi: Bölüm III", RFC 1423, Şubat 1993.

[30] Voydock, V. ve S. Kent, "Yüksek Düzey Ağ Protokollerinde Güvenlik Mekanizmaları", *ACM Computing Surveys*, cilt 15, s. 135--171, Haziran 1983.

[31] Floyd, S., "Tıkanıklık Kontrolü İlkeleri", BCP 41, RFC 2914, Eylül 2000.

[32] Rivest, R., "MD5 Mesaj Özeti Algoritması", RFC 1321, Nisan 1992.

[33] Stubblebine, S., "Multimedya Konferansları için Güvenlik Hizmetleri", *16. Ulusal Bilgisayar Güvenliği Konferansı* içinde, (Baltimore, Maryland), s. 391--395, Eylül 1993.

[34] Floyd, S. ve V. Jacobson, "Periyodik Yönlendirme İletilerinin Senkronizasyonu", *IEEE/ACM Transactions on Networking*, cilt 2, s. 122--136, Nisan 1994.

## Yazarların Adresleri

**Henning Schulzrinne**  
Bilgisayar Bilimleri Bölümü  
Columbia Üniversitesi  
1214 Amsterdam Avenue  
New York, NY 10027  
Amerika Birleşik Devletleri

E-posta: schulzrinne@cs.columbia.edu

**Stephen L. Casner**  
Packet Design  
3400 Hillview Avenue, Bina 3  
Palo Alto, CA 94304  
Amerika Birleşik Devletleri

E-posta: casner@acm.org

**Ron Frederick**  
Blue Coat Systems Inc.  
650 Almanor Avenue  
Sunnyvale, CA 94085  
Amerika Birleşik Devletleri

E-posta: ronf@bluecoat.com

**Van Jacobson**  
Packet Design  
3400 Hillview Avenue, Bina 3  
Palo Alto, CA 94304  
Amerika Birleşik Devletleri

E-posta: van@packetdesign.com

## Tam Telif Hakkı Bildirimi

Telif Hakkı (C) The Internet Society (2003). Tüm Hakları Saklıdır.

Bu belge ve bunun çevirileri kopyalanabilir ve başkalarına verilebilir; ayrıca bu belgeyi yorumlayan, açıklayan veya uygulanmasına yardımcı olan türev çalışmalar, yukarıdaki telif hakkı bildirimi ve bu paragraf tüm kopyalarda ve türev çalışmalarda yer almak koşuluyla, kısmen veya tamamen, herhangi bir kısıtlama olmaksızın hazırlanabilir, kopyalanabilir, yayımlanabilir ve dağıtılabilir. Ancak, bu belgenin kendisi, telif hakkı bildiriminin veya Internet Society ya da diğer Internet kuruluşlarına yapılan atıfların kaldırılması gibi yollarla, hiçbir şekilde değiştirilemez; yalnızca Internet standartlarının geliştirilmesi amacıyla gerekli olduğunda, bu durumda Internet Standartları sürecinde tanımlanan telif hakkı prosedürlerine uyulması koşuluyla veya İngilizce dışındaki dillere çevrilmesi gerektiğinde istisna uygulanır.

Yukarıda verilen sınırlı izinler süresizdir ve Internet Society veya onun halefleri ya da devralanları tarafından geri alınmayacaktır.

Bu belge ve burada yer alan bilgiler "OLDUĞU GİBİ" esasına göre sağlanmaktadır ve INTERNET SOCIETY İLE INTERNET ENGINEERING TASK FORCE, BURADA YER ALAN BİLGİLERİN KULLANIMININ HERHANGİ BİR HAKKI İHLAL ETMEYECEĞİNE DAİR HERHANGİ BİR GARANTİ DAHİL OLMAK ÜZERE, AÇIK VEYA ZIMNİ TÜM GARANTİLERİ, PAZARLANABİLİRLİK VEYA BELİRLİ BİR AMACA UYGUNLUK İÇİN ZIMNİ GARANTİLERLE SINIRLI OLMAMAK KAYDIYLA, REDDEDER.

## Teşekkür

RFC Editörü işlevi için finansman şu anda Internet Society tarafından sağlanmaktadır.

Uğur Toprakdeviren

Kendi öğrenme sürecimden notlar.

ugur@toprak.run