Rtp protokolü bağlantı noktaları. IP telefonda İnternet protokollerinin kullanımı

9. Protokol sabitlerinin listesi

10. Trafik profili ve formatının tanımı

11. Minimum kontrolle sesli ve görüntülü konferans için RTP profili

12. Kullanılan terimlerin ve kısaltmaların listesi

11.1. RTP ve RTCP paket biçimleri ve protokol parametreleri

11.2. Trafik türlerinin kaydı

11.3. ses kodlama

11.4. video kodlama

11.5. bağlantı noktası ataması

RTP protokolünü oluşturma ilkeleri

İş kontrol yöntemleri

RTP başlık formatı

Kaynak Rezervasyon Protokolü - LCV

Edebiyat

2.3.3. TCP protokolü

2.3.4. UDP protokolü

2.3.5. RTP ve RTCP protokolleri

1. Telefonun temel kavramları

2. Bir SIP / SDP / RTP protokolü paketinin açıklaması

3. Basılan düğmeler hakkında bilgi aktarımı

4. Ses ve faks iletimi

5. Dijital sinyal işleme (DSP). IP telefonda ses kalitesinin sağlanması, test örnekleri

Temel konseptler

Grup sesli konferansı

Video konferans

Karıştırıcıları ve çevirmenleri anlama

RTCP kontrol protokolü

RTCP Paket Hızı

ev / Eğitim/ Rtp protokolü bağlantı noktaları. IP telefonda İnternet protokollerinin kullanımı

Bu bölümde, RTP paketlerinin ağ ve aktarım protokolleri ile taşınmasının bazı yönleri tartışılmaktadır. Diğer protokol spesifikasyonları tarafından aksi belirtilmedikçe, paketler iletilirken aşağıdaki genel kurallar geçerlidir.

RTP, RTP veri akışları ve RTCP kontrol bilgileri arasında ayrım sağlamak için temel protokollere dayanır. UDP ve benzer protokoller için, RTP çift bir bağlantı noktası numarası kullanır ve ilgili RTCP akışı bir daha yüksek bağlantı noktası numarası kullanır.

RTP bilgi paketleri herhangi bir uzunluk alanı içermez, bu nedenle RTP, uzunluğun bir göstergesini sağlamak için temel bir protokole dayanır. RTP paketlerinin maksimum uzunluğu, yalnızca temel alınan protokollerle sınırlıdır.

Birden çok RTP paketi, bir UDP paketi gibi tek bir alt katman protokol veri biriminde taşınabilir. Bu, başlıkların fazlalığını azaltır ve farklı akışlar arasındaki senkronizasyonu basitleştirebilir.

Bu bölüm, RTP protokolü belirtiminde tanımlanan sabitlerin bir listesini içerir.

RTP trafik tipi sabitleri (PT - yük tipi) profillerde tanımlanır. Ancak, işaretleyici bit(ler)i ve trafik türü alanını içeren RTP başlık sekizlisi, RTP paketlerini RTCP SR ve RR paketlerinden ayırt etmek için 200 ve 201 (ondalık) ayrılmış değerleri İÇERMEMELİDİR. Bir belirteç biti ve yedi bit trafik türü alanına sahip standart bir biçim için bu sınırlama, 72 ve 73 trafik türlerinin kullanılmaması gerektiği anlamına gelir.

RTCP paket türleri için değerler (bkz. Tablo 1) için 200 ila 204 aralığında seçilir. daha iyi kontrol RTP paketleriyle karşılaştırıldığında RTCP paketlerinin başlığının doğruluğu. RTCP paket tipi alanı, RTP başlığının karşılık gelen sekizlisi ile karşılaştırıldığında, bu aralık, bir işaretleyici bitine (genellikle veri paketlerinde durum böyle değildir) ve standart trafik tipi alanının en anlamlı bitine eşittir. bir (statik olarak belirtilen trafik türleri genellikle en önemli basamakta sıfır olan PT değerlerine sahiptir). Bu aralık aynı zamanda 0 ve 255 değerlerinden daha da uzaklaşmak için seçilmiştir, çünkü tamamen sıfır veya bir olan alanlar çoğunlukla veriye özgüdür.

Diğer RTCP paket türleri, IANA Topluluğu tarafından tanımlanır. Geliştiriciler, deneysel araştırma yapmak için ihtiyaç duydukları değerleri kaydetme ve ardından bu değerlere olan ihtiyaç ortadan kalktığı için kaydı iptal etme yeteneğine sahiptir.

SDES paketinde izin verilen öğe türleri tabloda sunulmaktadır. 2. Diğer SDES hükümleri türleri, IANA Topluluğu tarafından belirlenir. Geliştiriciler, deneysel araştırma yaparken ihtiyaç duydukları değerleri kaydetme ve daha sonra bu değerlere artık ihtiyaç duyulmadığında kaydı silme yeteneğine sahiptir.

Yukarıda belirtildiği gibi (bkz. Bölüm 2), tam tanım Belirli bir uygulama için RTP protokolü, iki tür ek belge gerektirir: profilin açıklaması ve trafiğin biçimi.

RTP, çok farklı gereksinimlere sahip birçok uygulama sınıfı için kullanılabilir. Bu gereksinimlere uyum sağlama esnekliği, farklı profillerin kullanılmasıyla sağlanır (bkz.). Tipik olarak, bir uygulama yalnızca bir profil kullanır ve hangi profilin içinde olduğuna dair açık bir gösterge yoktur. şu an kullanımda - hayır.

İkinci türden ek bir belge - Trafik Biçimi Belirtimi - belirli bir trafik türünün (örneğin, H.261'e göre kodlanmış video sinyali) RTP'ye göre nasıl iletileceğini tanımlar. Aynı trafik formatı birden fazla profil için kullanılabilir ve bu nedenle profilden bağımsız olarak tanımlanabilir. Profil belgeleri sadece bu formata ve PT değerine uymakla yükümlüdür. .

Profil açıklamasında aşağıdaki öğeler tanımlanabilir, ancak bu liste ayrıntılı değildir.

RTP veri paketi başlığı. Bir işaretleyici biti ve bir trafik tipi alanı içeren bir RTP veri paketinin başlığındaki sekizli, örneğin daha fazla veya daha az işaret biti sağlamak için (bölüm 3.3) farklı gereksinimleri karşılamak için profile göre yeniden tanımlanabilir.

Trafik türleri. Bir profil tipik olarak çeşitli trafik formatlarını (örneğin medya kodlama algoritmaları) ve bu formatların ve PT değerlerinin varsayılan bir statik eşlemesini tanımlar. Trafik formatlarından bazıları, bireysel trafik formatı açıklamalarına atıfta bulunularak tanımlanabilir. Her belirli trafik türü için profil, kullanılacak gerekli RTP zaman damgası saat hızını belirtmelidir (Bölüm 3.1).

RTP veri paketi başlığı eklemeleri. Profilin uygulama sınıfında trafik türünden bağımsız olarak bazı ek işlevler gerekiyorsa, RTP veri paketinin sabit başlığına ek alanlar eklenebilir. .

RTP veri paketi başlık uzantıları. RTP Veri Paketi Başlığı Uzantı Yapısının ilk 16 bitinin içeriği, bu mekanizmanın kullanımına profil tarafından izin veriliyorsa belirtilecektir. .

RTCP paket türleri. Yeni uygulama sınıfına özel RTCP paket türleri tanımlanabilir (ve IANA tarafından kaydedilebilir).

RTCP raporlama aralığı. Profil, RTCP raporlama aralığının hesaplanmasında kullanılacak değerleri tanımlamalıdır: RTCP oturum bant genişliğinin oranı, minimum raporlama aralığı ve bant genişliğinin göndericiler ve alıcılar arasındaki bölünmesi.

SR / RR paketinin uzantısı. Düzenli olarak iletilmesi gereken ek kaynak veya hedef bilgisi varsa, RTCP SR ve RR paketleri için bir uzantı bölümü belirtilebilir.

SDES'i kullanma. Profil, devredilecek veya bırakılacak RTCP SDES öğeleri için göreli öncelikleri tanımlayabilir (bkz. bölüm 4.2.2); CNAME yan tümcesi için alternatif sözdizimi veya semantik (bölüm 4.4.1); LOC öğe formatı (bölüm 4.4.5); NOT deyiminin (bölüm 4.4.7) semantiği ve kullanımı ve IANA'ya kaydedilecek yeni SDES maddeleri.

Güvenlik. Profil, uygulamaların hangi güvenlik hizmetlerini ve algoritmaları kullanması gerektiğini tanımlayabilir ve bunların kullanımını kontrol edebilir (madde 7).

Şifre-anahtar eşleşmesi. Profil, kullanıcı tarafından girilen bir parolanın nasıl bir şifreleme anahtarına dönüştürüleceğini belirleyebilir.

Alt katman protokolü. RTP paketleri, belirli bir temel ağ veya taşıma katmanı protokolünün kullanılmasını gerektirebilir.

Taşıma uyumluluğu. UDP bağlantı noktaları gibi taşıma katmanı adreslerine madde 8'de belirtilen standart RTP ve RTCP yazışmaları dışında tanımlanabilir.

kapsülleme. RTP paket şekillendirme, birden fazla paketin iletilmesine izin vermek için tanımlanabilir. bilgi paketleri Bir alt katman protokol veri biriminde RTP (bölüm 8).

Geliştirdiğiniz her uygulama yeni bir profil gerektirmemelidir. Yeni bir tane oluşturmaktansa, mevcut bir profili bir uygulama sınıfı içinde genişletmek daha uygundur. Bu, her biri genellikle yalnızca bir profil altında çalıştığından, uygulamaların etkileşimini kolaylaştıracaktır. Ek PT değerleri veya RTCP paket türleri tanımlamak gibi basit uzantılar, bunları IANA'ya kaydederek ve açıklamalarını bir profil spesifikasyonunda veya bir trafik formatı spesifikasyonunda yayınlayarak gerçekleştirilebilir.

RFC 1890, bir grup sesli veya görüntülü konferansta gerçek zamanlı aktarım protokolü RTP sürüm 2'yi ve bununla ilişkili kontrol protokolü RTCP'yi kullanmak için bir profili açıklar; bu, minimum kontrolle sesli ve görüntülü konferanslar için RTP profili olarak adlandırılır (Ses ve Görüntü için RTP Profili). Minimum Kontrollü Video Konferanslar). Bu profil, RTP Sürüm 2 Protokol Spesifikasyonunda (RFC 1889) belirtilmeyen RTP özelliklerini tanımlar. Minimum kontrol, parametrelerin görüşülmesi veya sahiplik kontrolü için hiçbir desteğin gerekli olmadığı anlamına gelir (örneğin, RTCP tarafından sağlanan trafik türlerinin statik eşlemeleri ve sahiplik göstergeleri kullanılırken). Bu profilin ana hükümlerini ele alalım.

Bu bölüm, bir profilde tanımlanabilen veya değiştirilebilen bir dizi öğenin tanımını içerir.

RTP bilgi paketi başlığı. Sabit RTP bilgi paketi başlığının standart formatı (bir jeton biti) kullanılır.

Trafik türleri. Trafik türlerinin statik değerleri 11.3 ve 11.4 bölümlerinde tanımlanmıştır.

RTP bilgi paketi başlık eklemeleri. RTP bilgi paketi başlıklarına ek sabit alan eklenmez.

RTP bilgi paketi başlık uzantıları. Hiçbir RTP bilgi paketi başlık uzantısı tanımlanmamıştır, ancak bu profili kullanan uygulamalar bu uzantıları KULLANABİLİR. Yani uygulamalarda RTP başlığının X bitinin her zaman sıfır olduğu varsayılmamalıdır. Uygulamalar, başlık uzantısını yok sayacak şekilde hazırlanmalıdır. Gelecekte bir başlık uzantısı belirtilirse, birçok farklı uzantının tanımlanabilmesi için ilk 16 bitin içeriği belirtilmelidir.

RTCP paket türleri. Bu profil belirtiminde ek RTCP paket türleri tanımlanmamıştır.

RTCP raporlama aralığı. RTCP raporlama aralığı hesaplanırken RFC 1889'da önerilen sabitler KULLANILMALIDIR.

SR / RR paket uzantıları. RTCP SR ve RR paketleri için hiçbir uzantı tanımlanmamıştır.

SDES'i kullanma. Uygulamalar, açıklanan SDES maddelerinden herhangi birini kullanabilir. Kurallı ad bilgisi (CNAME) her raporlama aralığında gönderilirken, diğer öğeler yalnızca her beşinci raporlama aralığında gönderilmelidir.

Güvenlik. Varsayılan RTP güvenlik hizmetleri de bu profil tarafından varsayılan olarak tanımlanır.

Şifre-anahtar eşleşmesi. Kullanıcı tarafından girilen şifre, MD5 algoritması kullanılarak 16 sekizli bir özete dönüştürülür. Bir özetten, ilk N biti kullanılarak bir N bitlik anahtar elde edilir. Parolaların telefon, faks, teleks veya e-posta yoluyla iletilmesi sırasında bozulma olasılığını azaltmak için parolanın yalnızca ASCII harfleri, sayıları, kısa çizgileri ve boşlukları içerebileceği varsayılmaktadır. Şifre, şifreleme algoritmasının bir özelliğinden önce gelebilir. İlk eğik çizgiye (ASCII kodu 0x2f) kadar olan herhangi bir karakter, şifreleme algoritmasının adı olarak yorumlanır. Eğik çizgi yoksa, varsayılan DES-CBC şifrelemesidir.

Kapatma algoritması uygulanmadan önce kullanıcı tarafından girilen şifre kanonik forma dönüştürülür. Bunu yapmak için, parola, ISO / IEC 10646-1: 1993 Ek P'de tanımlandığı gibi UTF-8 kodlaması kullanılarak ISO 10646 karakter kümesine dönüştürülür (ASCII karakterleri herhangi bir dönüştürme gerektirmez); şifrenin başındaki ve sonundaki boşluklar kaldırılır; iki veya daha fazla boşluk bir boşlukla değiştirilir (ASCII veya UTF-8 0x20); tüm harfler küçük harflere dönüştürülür

Temel protokol. Profil, iki yönlü ve çok noktaya yayın modunda UDP üzerinden RTP kullanımını tanımlar.

Taşıma uyumluluğu. RTP ve RTCP taşıma katmanı adresleri arasında standart bir yazışma kullanılır.

kapsülleme. RTP paket kapsüllemesi tanımsız.

Bu profil, RTP ile kullanılan standart kodlama türlerini tanımlar. Diğer kodlama türleri, kullanımdan önce IANA'ya kaydedilmelidir. Yeni bir kodlama türü kaydedilirken aşağıdaki bilgiler sağlanmalıdır:

kodlama türünün kod adı ve RTP zaman damgasının saat hızı (gerekirse kompakt bir gösterim sağlamak için kod adı üç veya dört karakter uzunluğunda olmalıdır);
kodlama türünü değiştirme hakkına sahip olduğuna dair bir gösterge (örneğin, ISO, CCITT / ITU, diğer uluslararası standart kuruluşları, konsorsiyum, belirli şirket veya şirketler grubu);
herhangi bir çalışma parametresi;
(tercih sırasına göre) RFC, yayınlanmış makale, patent başvurusu, teknik rapor, kodek kaynağı veya referans gibi kodlama algoritmasının mevcut açıklamalarına bağlantılar;
özel kodlama türleri için iletişim bilgileri (posta adresi ve e-posta adresi);
gerekirse, bu profilin trafik türünü belirtmek için değer (aşağıya bakın).
RTP ile kullanılacak tüm kodlama türlerinin statik olarak atanması gerekmediğini unutmayın. Bu makalede ele alınmayan RTP olmayan araçlar, 96 ila 127 aralığındaki bir trafik türü (PT) değeri ile bir kodlama türü arasında dinamik olarak eşlemek için kullanılabilir.
Trafik türleri için kullanılabilir değer alanı oldukça küçüktür. Yeni trafik türleri, yalnızca aşağıdaki koşullar yerine getirildiğinde statik olarak (kalıcı olarak) atanır:
kodlama topluluğa büyük ilgi gösteriyor İnternet ağları;
mevcut kodlamalarla karşılaştırılabilir avantajlar sunar ve/veya mevcut, yaygın olarak kullanılan konferans veya multimedya sistemleriyle birlikte çalışabilirlik için gereklidir;
açıklama bir kod çözücü oluşturmak için yeterlidir.

Duraklamalar sırasında paket göndermeyen uygulamalar için, ilk aktif konuşma paketi (duraklamadan sonraki ilk paket), RTP taşıyıcı paketinin başlığında bire ayarlanmış bir belirteç biti ile ayırt edilir. Susturulmamış uygulamalar bu biti sıfıra ayarlar.

RTP zaman damgasını oluşturmak için kullanılan RTP saati, kanal sayısından ve kodlama türünden bağımsızdır; saniyedeki örnekleme periyotlarının sayısına eşittir. N-kanal kodlaması için (stereo, dörtlü, vb.), her örnekleme periyodu (saniyenin 1/8000'i diyelim) N numune üretir. Saniyede üretilen toplam örnek sayısı, örnekleme hızının kanal sayısının çarpımına eşittir.

Birden fazla ses kanalı kullanırken, ilkinden başlayarak soldan sağa doğru numaralandırılırlar. RTP ses paketlerinde, daha düşük numaralı kanallardan gelen veriler, daha yüksek numaralı kanallardan gelen verilerden önce gelir. İkiden fazla kanal için, sonraki sistemler atamalar:

l - sol;
r - sağ;
c - merkezi;
S - çevresel;
F - ön;
R - geri.

Kanal Sayısı	sistem adı	Kanal numaraları
Kanal Sayısı	sistem adı	1	2	3	4	5	6
2	müzik seti	ben	r
3		ben	r	C
4	dörtlü	fl	Cum	rl	sağ
4		ben	C	r	S
5		fl	Cum	Fc	Sl	Bay
6		ben	lc	C	r	rc	S

Aynı örnekleme zamanına ait tüm kanalların örnekleri aynı paket içinde olmalıdır. Farklı kanallardan örneklerin serpiştirilmesi, kodlamanın türüne bağlıdır.

Örnekleme hızı çeşitli seçeneklerden seçilmelidir: 8000, 11025, 16000, 22050, 24000, 32000, 44100 ve 48000 Hz (Apple Macintosh bilgisayarların 22050 ve 11025 s'ye dönüştürülebilen 22254.54 ve 11127.27 kendi örnekleme oranları vardır. 20 ms'lik bir çerçevede dört veya iki örnek atlayarak kabul edilebilir kalite). Bununla birlikte, çoğu ses kodlama algoritması, daha sınırlı bir dizi örnekleme hızı için tanımlanır. Alıcılar çok kanallı ses almaya hazır olmalıdır, ancak mono'yu da seçebilir.

Bir ses sinyalinin paketlenmesi için, kodlama açıklamasında aksi belirtilmedikçe, varsayılan paketleme aralığı 20 ms olacaktır. Paketleme aralığı, minimum uçtan uca gecikmeyi tanımlar. Daha uzun paketler, başlık için nispeten daha az bayta sahiptir, ancak daha fazla gecikmeye neden olur ve paket kaybını daha önemli hale getirir. Dersler veya önemli bant genişliği kısıtlamaları olan kanallar gibi etkileşimli olmayan uygulamalar için daha yüksek paketleme gecikmesi kabul edilebilir. Alıcı, 0 ila 200 ms gecikmeli bir ses sinyaline sahip paketleri almalıdır. Bu sınırlama, alıcı için kabul edilebilir bir arabellek boyutu sağlar.

Örnek tabanlı kodlamalarda, her bir sinyal örneği sabit sayıda bit ile temsil edilir. Sıkıştırılmış ses verileri içinde, tek tek örnek kodlar sekizli sınırlarını aşabilir. Bir ses paketinde iletilen sinyalin süresi, paketteki örnek sayısı ile belirlenir.

Her örnek için bir veya daha fazla sekizli üreten örnek tabanlı kodlama türleri için, aynı anda örneklenen farklı kanallardan örnekler bitişik sekizlilere paketlenir. Örneğin, stereo sesi kodlamak için sekizli sıra şöyledir: sol kanal, ilk örnek; sağ kanal, ilk sayım; sol kanal, ikinci sayım; sağ kanal, ikinci sayı vb. Çoklu sekizli kodlamada, en önemli sekizli ilk olarak iletilir. Her numune için bir sekizliden daha az üreten numune tabanlı kodlamaların paketlenmesi, kodlama algoritması tarafından belirlenir.

Çerçeve tabanlı bir kodlama algoritması, sabit uzunluktaki bir ses bloğunu, genellikle yine sabit uzunlukta olan başka bir sıkıştırılmış veri bloğuna dönüştürür. Çerçeve tabanlı kodlamalar için gönderici, bu tür birden çok çerçeveyi tek bir mesajda birleştirebilir.

Çerçeve tabanlı kodekler için kanal sıralaması tüm bloğa özeldir. Yani, stereo ses için sol ve sağ kanalların örnekleri bağımsız olarak kodlanır; burada sol kanal için kodlama çerçevesi, sağ kanal için çerçeveden önce gelir.

Tüm çerçeve yönelimli ses kodekleri, tek bir paket içinde iletilen ardışık birden çok çerçeveyi kodlayabilmeli ve kodunu çözebilmelidir. Çerçeve yönelimli kodekler için çerçeve boyutu belirtildiğinden, aynı kodlama için ayrı bir gösterim kullanmaya gerek yoktur, ancak paket başına farklı sayıda çerçeve ile.

Tablo Şekil 3, ses sinyalleri için bu profil tarafından tanımlanan trafik türlerinin (PT) değerlerini, bunların efsane ve ana özellikler kodlama algoritmaları

Tablo Şekil 4, bu profil tarafından tanımlanan kodlama türlerinin (PT), kodlama algoritmalarının sembollerinin ve video kodlama algoritmalarının teknik özelliklerinin yanı sıra atanmamış, ayrılmış ve dinamik olarak ayarlanmış PT değerlerini gösterir.

96 ila 127 aralığındaki trafik türü değerleri, bu makalede ele alınmayan konferans kontrol protokolü aracılığıyla dinamik olarak belirlenebilir. Örneğin, oturum dizini belirli bir oturum için trafik tipi 96'nın 8000 Hz'de çift kanallı PCMU kodlamasını gösterdiğini belirtebilir. "Ayrılmış" olarak işaretlenen trafik türü değerleri aralığı, RTCP ve RTP paketlerinin güvenilir bir şekilde ayırt edilebilmesi için kullanılmaz .

Herhangi bir zaman noktasındaki bir RTP kaynağı, yalnızca bir tür trafik verir; trafik serpiştirme farklı şekiller bir oturumda RTP'ye izin verilmez. Farklı trafik türlerini taşımak için birkaç RTP oturumu paralel olarak kullanılabilir. Bu profilde tanımlanan trafik türleri ya sese ya da videoya atıfta bulunur, ancak ikisini birden değil. Ancak, örneğin ses ve videoyu trafik biçiminde uygun ayırma ile birleştiren birleşik trafik türlerinin tanımlanmasına izin verilir.

Bu profili kullanan ses uygulamaları en azından 0 (PCMU) ve 5 (DVI4) trafik türlerini gönderip alabilmelidir. Bu, format anlaşması olmadan birlikte çalışabilirliği sağlar.

RTP protokolü açıklamasında tanımlandığı gibi, RTP verileri çift sayılı bir UDP bağlantı noktası üzerinden gönderilmeli ve karşılık gelen RTCP paketleri tek sayılı bir bağlantı noktası üzerinden gönderilmelidir.

Bu profili kullanan uygulamalar, bu tür herhangi bir UDP bağlantı noktası çiftini kullanabilir. Örneğin, bir çift bağlantı noktası, oturum yönetim programı tarafından rastgele atanabilir. Tek bir sabit bağlantı noktası numarası çifti belirtilemez, çünkü bazı durumlarda bu profili kullanan birkaç uygulama aynı ana bilgisayarda doğru şekilde çalışmalıdır ve bazı işletim sistemleri birden çok işlemin farklı çok noktaya yayın adresleriyle aynı UDP bağlantı noktasını kullanmasına izin vermez.

Ancak, varsayılan bağlantı noktası numaraları 5004 ve 5005 olabilir. Birden çok profil kullanan uygulamalar, bu bağlantı noktası çiftini o profilin göstergesi olarak seçebilir. Ancak uygulamalar ayrıca açıkça belirtilmesi için bir bağlantı noktası çifti gerektirebilir.

ASCII (Amerikan Bilgi Değişimi Standart Kodu), bilgi alışverişi için Amerikan standart kodudur. 7 bitlik sunum kodu metin bilgisiçoğu bilgisayar sisteminde bazı değişikliklerle kullanılır
CBC (şifre blok zinciri) - şifreli blok zinciri, DES veri şifreleme standart modu
CELP (kod uyarılı doğrusal tahmin), kod uyarılı doğrusal tahmin kullanan bir ses kodlama türüdür.
CNAME (kurallı ad) - kurallı ad
CSRC (katkıda bulunan kaynak) - dahil edilen kaynak. RTP karıştırıcısı tarafından üretilen birleşik akışa katkıda bulunan RTP paket akışının kaynağı. Karıştırıcı, bu paketin oluşumuna katılan kaynakların SSRC tanımlayıcılarının bir listesini RTP paket başlığına ekler. Bu listeye CSRC listesi denir. Örnek: Mikser, tüm ses paketleri aynı SSRC ID'sini içerse bile (mikser gibi) alıcıyı mevcut mesaj kaynağına yönlendirerek, sesleri karıştırılmış ve giden paketi oluşturmak için kullanılmış olan şu anda konuşan telekonferans katılımcılarının kimliklerini iletir.
DES (Veri Şifreleme Standardı) - veri şifreleme standardı
IANA (Internet Assigned Numbers Authority) - Internet Assigned Numbers Community
IMA (Etkileşimli Multimedya Derneği) - Etkileşimli Multimedya Derneği
IP (İnternet Protokolü) - arasında ağ protokolü, ağ katmanı protokolü, datagram protokolü. Paketlerin hedeflerine giderken birden fazla ağı geçmesine izin verir
IPM (IP Çok Noktaya Yayın) - IP protokolünü kullanarak çok noktaya yayın
LD-CELP (düşük gecikmeli kod uyarımlı doğrusal tahmin) - düşük gecikmeli kod uyarımlı doğrusal tahmin kullanan bir konuşma kodlama algoritması
LPC (doğrusal tahmine dayalı kodlama) - doğrusal tahmine dayalı kodlama
NTP (Ağ Zaman Protokolü), 1 Ocak 1900'deki sıfır saate göre saniye cinsinden zamanın geri sayımıdır. Tam NTP zaman damgası biçimi, ilk 32 bitinde bir tamsayı kısmı ve son 32 bitinde bir kesirli kısmı olan 64 bitlik işaretsiz sabit noktalı bir sayıdır. Bazı durumlarda, tam formattan yalnızca ortadaki 32 bitin alındığı daha kompakt bir gösterim kullanılır: tamsayı kısmının alt 16 biti ve kesirli kısmın üst 16 biti.
RPE / LTP (artık darbe uyarma / uzun vadeli tahmin) - diferansiyel darbe uyarma ve uzun vadeli tahmin içeren bir konuşma kodlama algoritması
RTCP (Gerçek Zamanlı Kontrol Protokolü) - gerçek zamanlı veri iletim kontrol protokolü
RTP (Gerçek Zamanlı Aktarım Protokolü) - gerçek zamanlı aktarım protokolü
SSRC (senkronizasyon kaynağı) - senkronizasyon kaynağı. Ağ adresinden bağımsız olarak RTP başlığında taşınan 32 bit sayısal SSRC tanımlayıcısı tarafından tanımlanan RTP paket akışının kaynağı. Aynı eşitleme kaynağına sahip tüm paketler, aynı zamanlama ve sıra numarası alanını kullanır, bu nedenle alıcı, eşzamanlama kaynağıyla oynatma için paketleri gruplandırır. Senkronizasyon kaynağı örneği: bir sinyal kaynağından alınan paket akışının göndericisi mikrofon tipi, video kamera veya RTP karıştırıcı. Senkronizasyon kaynağı, zaman içinde veri biçimini değiştirebilir, örneğin, ses kodlaması... SSRC tanımlayıcısı, belirli bir RTP oturumu içinde genel olarak benzersiz olarak kabul edilen rastgele seçilmiş bir değerdir. Telekonferans katılımcısının bir multimedya iletişim oturumundaki tüm RTP oturumları için aynı SSRC'yi kullanması gerekmez; SSRC kimlik toplaması, RTCP aracılığıyla sağlanır. Bir katılımcı, örneğin birden çok video kameradan bir RTP oturumunda birden çok akış oluşturursa, her akışın ayrı bir SSRC tarafından tanımlanması gerekir.
TCP (İletim Kontrol Protokolü), IP ile birlikte kullanılan bir taşıma katmanı protokolüdür.
UDP (Kullanıcı Datagram Protokolü), bağlantısız bir taşıma katmanı protokolüdür. UDP, yalnızca ağdaki bir veya daha fazla istasyona gönderilecek bir paket sağlar. Veri iletiminin doğrulanması ve bütünlüğünün sağlanması (garantili teslimat) daha üst düzeyde gerçekleştirilir
ADPCM - Uyarlanabilir Diferansiyel Darbe Kodu Modülasyonu
titreşim - sinyalin titreşimi, faz veya frekans sapmaları; IP telefonuyla ilgili olarak - ağdaki datagramların gecikmesindeki düzensizlikler
ZPD - veri iletim bağlantısı (Referans Etkileşim Modelinin ikinci seviyesi açık sistemler)
IVS - bilgi ve bilgisayar ağları
mikser - bir veya daha fazla kaynaktan RTP paketleri alan, muhtemelen veri formatını değiştiren, paketleri birleştiren bir ara sistem yeni paket RTP ve sonra iletir. Birçok sinyal kaynağı genellikle senkronize olmadığı için, karıştırıcı bileşen akışlarının zamanlamasını ayarlar ve birleşik akış için kendi zamanlamasını oluşturur. Böylece, mikser tarafından üretilen tüm bilgi paketleri, mikserin senkronizasyon kaynağına sahip olduğu şeklinde tanımlanır.
monitör (monitör) - RTP oturumunda katılımcılar tarafından gönderilen RTCP paketlerini, özellikle alım raporlarını alan ve dağıtımı kontrol etmek, hataları ve uzun vadeli istatistikleri tespit etmek için mevcut hizmet kalitesini değerlendiren bir uygulama. Genellikle monitörün işlevleri, oturumda kullanılan uygulamalarla ilgilidir, ancak monitör, başka şekilde kullanılmayan, RTP veri paketleri göndermeyen veya almayan ayrı bir uygulama da olabilir. Bu tür uygulamalara üçüncü taraf monitörler denir.
ITU-T - Uluslararası Telekomünikasyon Birliği Telekomünikasyon Standardizasyon Sektörü
uç sistem - RTP paketlerinde iletilen içeriği üreten ve / veya alınan RTP paketlerinin içeriğini tüketen bir uygulama. Son sistem, her RTP oturumunda bir veya daha fazla (ancak genellikle yalnızca bir) saat kaynağı olarak hareket edebilir.
RTCP paketi — RTP bilgi paketlerine benzer şekilde başlığın sabit bir bölümünden ve ardından RTCP paketinin tipine bağlı olarak değişen yapısal öğelerden oluşan bir kontrol paketi. Tipik olarak, birden çok RTCP paketi, tek bir temel protokol paketinde birleşik bir RTCP paketi olarak birlikte gönderilir; bu, her RTCP paketinin sabit başlığındaki uzunluk alanı tarafından sağlanır.
RTP paketi, sabit bir RTP başlığından, muhtemelen dahil edilen kaynakların, uzantıların ve trafiğin boş bir listesinden oluşan bir protokol veri birimidir. Genellikle bir alt katman protokol paketi bir RTP paketi içerir, ancak birkaç tane olabilir.
bağlantı noktası, tek bir ana bilgisayardaki birden çok hedefi ayırt etmek için aktarım düzeyi protokolleri tarafından kullanılan bir soyutlamadır. Bağlantı noktası numarası ile tanımlanır. Bu nedenle, bağlantı noktası numarası, gönderilen verilerin amaçlandığı belirli uygulamayı tanımlayan bir sayıdır. Bu numara, üst katmanda hangi protokolün (örneğin, TCP veya UDP) kullanıldığına ilişkin bilgilerle birlikte, İnternet üzerinden gönderilen datagramlardaki diğer hizmet bilgileri arasında yer alır. Taşıma tarafından kullanılan taşıma seçicileri (TSEL) OSI katmanı, bağlantı noktalarına eşdeğerdir
profil (profil) - işlevlerinin özelliklerini belirleyen bir uygulama sınıfı için RTP ve RTCP protokolleri için bir dizi parametre. Profil, RTP veri paketi başlığındaki belirteç biti ve trafik türü alanlarının kullanımını, trafik türlerini, RTP veri paketi başlık eklemelerini, ilk 16 bit RTP veri paketi başlık uzantısını, RTCP paket türlerini, RTCP raporlama aralığını, SR / RR paketini tanımlar. iletişim güvenliğini sağlamak için uzantı, kullanım SDES paketleri, hizmetleri ve algoritmaları ve alt katman protokolünü kullanmanın özellikleri
RTP oturumu (RTP oturumu) - RTP protokolü aracılığıyla etkileşime giren birçok katılımcının iletişimi. Her katılımcı için oturum, belirli bir çift hedef taşıma adresi (bir ağ adresi artı RTP ve RTCP için birkaç bağlantı noktası). Bir aktarım hedef adresi çifti tüm katılımcılar için ortak olabilir (IPM durumunda olduğu gibi) veya her biri için farklı olabilir (çift yönlü iletişimde olduğu gibi bireysel ağ adresi ve ortak bir çift bağlantı noktası). Bir multimedya oturumunda, her trafik türü, kendi RTCP paketleriyle ayrı bir RTP oturumunda gönderilir. Çok noktaya yayın RTP oturumları, farklı bağlantı noktası çifti numaraları ve/veya farklı çok noktaya yayın adresleri ile ayırt edilir
RTP olmayan araçlar — Kabul edilebilir bir hizmet sağlamak için RTP'ye ek olarak ihtiyaç duyulabilecek protokoller ve mekanizmalar. Konferans yönetim uygulaması özellikle multimedya konferans için çok noktaya yayın adresleri ve şifreleme anahtarları tahsis edebilir, kullanılacak şifreleme algoritmasını müzakere edebilir ve RTP trafik türü değerleri ile temsil ettikleri trafik biçimleri arasında dinamik eşlemeler belirleyebilir. önceden tanımlanmış değer. trafik türü). İçin basit uygulamalar ayrıca kullanılabilir E-posta veya konferans veritabanı
çevirmen - senkronizasyon kaynağı tanımlayıcısını değiştirmeden RTP paketlerini ileten bir ara sistem. Çevirmen örnekleri: Karıştırmadan kod dönüştürme yapan cihazlar, çok yönlü veya çift yönlü çoğaltıcılar, güvenlik duvarlarında uygulama katmanı uygulamaları
aktarım adresi - IP adresi ve UDP bağlantı noktası numarası gibi aktarım katmanının uç noktasını tanımlayan ağ adresi ve bağlantı noktası numarasının birleşimi. Paketler, kaynak taşıma adresinden hedef taşıma adresine iletilir.
RTP trafiği - ses örnekleri veya sıkıştırılmış video verileri gibi bir RTP paketinde iletilen multimedya verileri
PSTN - genel anahtarlamalı telefon ağları

En acil sorun, giderek artan bir şekilde, adres biçiminde bir değişiklik gerektiren adres alanı eksikliği haline geliyor.

Diğer bir sorun, IP ağlarının temeli olan yönlendirmenin ölçeklenebilirliğinin olmamasıdır. Ağın hızlı büyümesi, bugün halihazırda onlarca veya yüz binlerce giriş içeren yönlendirme tablolarını sürdürmek ve paket parçalanma sorununu çözmek zorunda olan yönlendiricilerde tıkanıklığa neden olur. Özellikle IP protokolünü yükselterek yönlendiricilerin çalışmasını kolaylaştırmak mümkündür.

Doğrudan IP protokolüne yeni işlevlerin eklenmesiyle birlikte, paket başlığına yeni alanlar ekleyerek yeni protokollerle daha yakın etkileşiminin sağlanması tavsiye edilir.

Sonuç olarak, aşağıdaki ana hedefleri takip ederek IP protokolünün yükseltilmesine karar verildi:

yeni bir genişletilmiş adresleme düzeninin oluşturulması;
omurga yönlendiricilerinin işlevlerini azaltarak ağ ölçeklenebilirliğini geliştirmek;
veri korumasının sağlanması.

Adres alanını genişletme... IP protokolü, adres genişliğini 128'e çıkararak potansiyel adres eksikliği sorununu çözmektedir. Ancak, adres uzunluğundaki bu kadar önemli bir artış, büyük ölçüde adres eksikliği sorununu ortadan kaldırmak için değil, adres verimliliğini artırmak için yapılmıştır. Bu protokole dayalı ağlar. Ana hedef, adresleme sistemini yapısal olarak değiştirmek, işlevselliğini artırmaktı.

Adres hiyerarşisinin mevcut iki seviyesi (ağ numarası ve düğüm numarası) yerine IPv6, üç seviyeli ağ tanımlama ve bir seviye düğüm tanımlama anlamına gelen dört seviye kullanmayı önerir.

Şimdi adres, her dört basamakta bir iki nokta üst üste ile ayrılmış olarak onaltılık biçimde yazılır, örneğin:

FEDC: 0A96: 0: 0: 0: 0: 7733: 567A.

IPv4 ve IPv6'nın her iki sürümünü de destekleyen ağlar için, alttaki 4 bayt için geleneksel ondalık gösterimi ve üsttekiler için onaltılık gösterimi kullanmak mümkündür:

0: 0: 0: 0: FFFF 194.135.75.104.

IPv6 adresleme sistemi içinde, yerel kullanım için, yani İnternet dışındaki ağlar için ayrılmış bir adres alanı da vardır. İki tip var yerel adresler: önek değerinde farklılık gösteren alt ağa bağlanmamış düz ağlar (Bağlantı-Yerel) ve alt ağa bağlı ağlar (Site-Yerel) için.

Paket başlıklarının biçimini değiştirme. Bu, başlığın gerekli minimum bilgiyi içeren ana başlık ve eksik olabilecek ek başlıklara bölünmesini sağlayan "iç içe başlıklar" için yeni bir organizasyon şeması ile gerçekleştirilebilir. Bu yaklaşım, protokolü açık hale getirerek yeni isteğe bağlı başlıklar tanımlayarak protokolü genişletmek için zengin olanaklar sunar.

Temel 40 baytlık IPv6 datagram başlığı aşağıdaki formata sahiptir (Şekil 2.4).

Alan Trafik Sınıfı amaç olarak alana eşdeğerdir Servis tipi ve alan Atlama Sınırı- alan Yaşama zamanı IPv4 protokolü.

Alan Akış Etiketi paketlerin içeriğini analiz etmeye gerek kalmadan tek tek veri akışlarını izole etmenize ve özel olarak işlemenize olanak tanır. Bu, yönlendiriciler üzerindeki yükü azaltmak açısından çok önemlidir.

Alan Sonraki Başlık IPv4 Protokolü alanına benzer ve ana başlığı takip eden başlığın türünü tanımlar. Sonraki her ek başlık ayrıca bir Sonraki Başlık alanı içerir.

kontrol protokolü bilgi iletimi (İletim Kontrol Protokolü - TCP), bilgisayarlar arasında etkileşimli iletişimi desteklemek için geliştirilmiştir. TCP protokolü, ortak bir ağın parçası olan bilgisayarlardaki işlemler arasındaki veri alışverişinin güvenilirliğini ve güvenilirliğini sağlar.

Ne yazık ki, TCP iletim yeteneğine sahip değil multimedya bilgileri... Ana sebep, teslimat üzerinde kontrolün varlığıdır. İzleme, gecikmeye duyarlı daha fazla bilgi iletmek için çok uzun sürüyor. Ayrıca TCP, ağ tıkanıklığını önlemek için iletim hızını kontrol eden mekanizmalar sağlar. Bununla birlikte, ses ve video verileri, keyfi olarak değiştirilemeyen kesin olarak tanımlanmış bit hızları gerektirir.

TCP, bir yandan kullanıcı uygulamasının uygulama protokolüyle, diğer yandan da genellikle IP tarafından gerçekleştirilen "düşük düzeyli" paket yönlendirme ve adresleme işlevleri sağlayan protokolle etkileşime girer.

İnternetin her düğümünde TCP / IP ailesinin protokollerini uygulayan ağ yazılımının mantıksal yapısı Şekil 2'de gösterilmektedir. 2.5.

Dikdörtgenler verileri işleyen modülleri, dikdörtgenleri birbirine bağlayan çizgiler ise veri aktarım yollarını temsil eder. Şeklin altındaki yatay çizgi, fiziksel ortam örneği olarak kullanılan bir Ethernet ağını belirtir.

Pirinç. 2.5.

İki süreç arasında bağlantı kurmak için farklı bilgisayarlar ağ, yalnızca bilgisayarların İnternet adreslerini değil, aynı zamanda bu bilgisayarlardaki işlemlerin kullandığı TCP bağlantı noktalarının (soketlerin) numaralarını da bilmeniz gerekir. İnternetteki herhangi bir TCP bağlantısı, iki IP adresi ve iki TCP bağlantı noktası numarası ile benzersiz bir şekilde tanımlanır.

TCP, hasarlı, kayıp, çoğaltılmış veya sıra dışı paketleri işleyebilir. Bu, iletilen her pakete bir sıra numarası atamak için bir mekanizma ve paketlerin alındığını kontrol etmek için bir mekanizma aracılığıyla gerçekleştirilir.

TCP bir veri segmenti ilettiğinde, bu verilerin bir kopyası bir yeniden iletim kuyruğuna yerleştirilir ve bir onay için beklemek için bir zamanlayıcı başlatılır.

Kullanıcı Datagram Protokolü (UDP), birbirine bağlı bir bilgisayar ağları sisteminde bulunan bilgisayarların süreçleri arasında datagram alışverişi yapmak için kullanılır.

UDP, IP tabanlıdır ve IP'den çok farklı olmayan taşıma hizmetleri ile uygulama süreçleri sağlar. UDP protokolü, garanti edilmeyen veri teslimatı sağlar, yani alındığının onaylanmasını gerektirmez; ayrıca bu protokol, bilgi kaynağı ve alıcısı arasında yani UDP modülleri arasında bir bağlantı kurulmasını gerektirmez.

Gerçek zamanlı aktarım protokolü RTP, etkileşimli ses ve video gibi multimedya verilerinin gerçek zamanlı uçtan uca iletimini sağlar. Bu protokol, trafik tipi tanıma, paket sıra numaralandırma, zaman damgası ve iletim kontrolünü uygular.

RTP protokolünün eylemi, giden her pakete zaman damgası atamaya indirgenmiştir. Alıcı tarafta, paketlerin zaman damgaları, bunların hangi sırayla ve hangi gecikmelerle oynatılması gerektiğini gösterir. RTP ve RTCP desteği, alıcı düğümün alınan paketleri doğru sırada düzenlemesine, paket gecikme titreşiminin sinyal kalitesi üzerindeki etkisini azaltmasına ve gelen bilgilerin kullanıcılar tarafından doğru bir şekilde dinlenip görüntülenebilmesi için ses ve video arasındaki senkronizasyonu geri yüklemesine olanak tanır.

RTP'nin, verilerin zamanında iletilmesini garanti edecek herhangi bir mekanizmaya sahip olmadığını ve hizmet kalitesi ancak bunu sağlamak için temeldeki hizmetleri kullanır. Paket servis dışı kalmasını engellemez ancak omurganın tamamen güvenilir olduğu ve paketleri doğru sırada ilettiği anlamına gelmez. RTP'ye dahil edilen sıra numaraları, alıcının gönderici paketlerinin sırasını yeniden yapılandırmasına izin verir.

RTP, çok noktaya yayın temel alınan ağ tarafından destekleniyorsa, hem çift yönlü iletişimi hem de bir grup hedefe veri aktarımını destekler. RTP, bireysel uygulamaların gerektirdiği bilgileri sağlamak üzere tasarlanmıştır ve çoğu durumda uygulamanın işleyişine entegre edilmiştir.

RTP bir aktarım katmanı protokolü olarak kabul edilse de, genellikle başka bir aktarım katmanı protokolü olan UDP'nin (Kullanıcı Datagram Protokolü) üzerinde çalışır. Her iki protokol de taşıma katmanının işlevselliğine katkıda bulunur. RTP ve RTCP'nin altta yatan aktarım ve ağ katmanlarından bağımsız olduğu, dolayısıyla RTP / RTCP'nin diğer uygun aktarım protokolleri ile kullanılabileceği unutulmamalıdır.

Protokol veri blokları RTP / RTCP'ye paketler denir. RTP protokolüne uygun olarak oluşturulan ve multimedya verilerini iletmek için kullanılan paketlere veri paketleri denir ve RTCP protokolüne göre oluşturulan ve güvenilir çalışma için gerekli olan hizmet bilgilerini aktarmak için kullanılan paketlere denir. telekonferanslar kontrol paketleri denir. Bir RTP paketi, sabit bir başlık, isteğe bağlı bir değişken başlık uzantısı ve bir veri alanı içerir. Bir RTCP paketi, sabit bir kısım (RTP bilgi paketlerinin sabit kısmına benzer) ile başlar ve ardından değişken uzunluktaki yapı taşları gelir.

RTP protokolünü daha esnek hale getirmek ve çeşitli uygulamalar için kullanılabilir kılmak için, bazı parametreleri kasıtlı olarak tanımsız hale getirilmiştir, ancak bir profil konsepti sağlar. Profil, belirli bir uygulama sınıfı için RTP ve RTCP protokolleri için işlevlerinin özelliklerini belirleyen bir dizi parametredir. Profil şunları tanımlar: bireysel paket başlık alanlarının kullanımı, trafik türleri, başlık eklemeleri ve başlık uzantıları, paket türleri, hizmetler ve iletişim güvenlik algoritmaları, alt katman protokolünün kullanım özellikleri vb. Her uygulama genellikle yalnızca bir profille çalışır ve profil tipi uygun uygulama seçilerek ayarlanır. Bağlantı noktası numarasına, protokol tanımlayıcısına vb. göre profil türünün açık bir göstergesi yoktur.

Bu nedenle, eksiksiz bir uygulamaya özel RTP spesifikasyonu, bir profil açıklamasının yanı sıra ses veya video gibi belirli bir türdeki trafiğin RTP'de nasıl işleneceğini tanımlayan bir trafik formatı tanımını içeren ek belgeleri içermelidir.

Çok noktaya yayın sesli konferansı, çok kullanıcılı bir çok noktaya yayın adresi ve iki bağlantı noktası gerektirir. Bu durumda, ses verilerinin değişimi için bir bağlantı noktası gerekir ve diğeri RTCP kontrol paketleri için kullanılır. Çok noktaya yayın adresi ve bağlantı noktası bilgileri potansiyel katılımcılara iletilir telekonferanslar... Gizlilik gerekiyorsa, bilgi ve kontrol paketleri şifrelenebilir, bu durumda bunların da oluşturulması ve dağıtılmış anahtarşifreleme.

Her konferans katılımcısı tarafından kullanılan sesli konferans uygulaması, ses verilerini 20 ms gibi küçük parçalar halinde gönderir. Her ses verisi öbeğinden önce bir RTP başlığı gelir; RTP başlığı ve verileri dönüşümlü olarak bir UDP paketine dönüştürülür (kapsüllenir). RTP başlığı, paketteki verileri oluşturmak için ne tür ses kodlamasının (örneğin, PCM, ADPCM veya LPC) kullanıldığını gösterir. Bu, örneğin düşük bant genişliğine sahip bir iletişim hattı kullanan yeni bir katılımcı göründüğünde veya ağ tıkandığında, konferans sırasında kodlama türünü değiştirmeyi mümkün kılar.

İnternette, diğer paket anahtarlamalı veri ağlarında olduğu gibi, paketler bazen kaybolur ve yeniden sıralanır ve ayrıca farklı zamanlarda ertelenir. Bu olaylara karşı koymak için, RTP başlığı, alıcıların orijinal durumlarına yeniden eşitlenmesine izin veren bir zaman damgası ve sıra numarası içerir, böylece örneğin, ses sinyalinin bölümleri hoparlör tarafından her 20 ms'de bir sürekli olarak çalınır. Bu senkronizasyon yeniden yapılandırması, RTP paketlerinin her kaynağı için ayrı ayrı ve bağımsız olarak gerçekleştirilir. telekonferanslar... Sıra numarası, alıcı tarafından kayıp paketlerin sayısını tahmin etmek için de kullanılabilir.

Katılımcılardan beri telekonferanslar konferans sırasında girip çıkabiliyorsa, o anda kimin katıldığını ve konferans katılımcılarının ses verilerini ne kadar iyi aldığını bilmek faydalıdır. Bu amaçla, konferans sırasında ses uygulamasının her bir örneği, diğer tüm katılımcıların uygulamaları için kullanıcı adlarını belirterek paket alma konusunda periyodik olarak kontrol bağlantı noktasında (RTCP bağlantı noktası) mesajlar gönderir. Alma mesajı, mevcut konuşmacının ne kadar iyi duyulduğunu gösterir ve uyarlanabilir kodlayıcıları kontrol etmek için kullanılabilir. Kullanıcı adına ek olarak, bant genişliği kontrolü için diğer kimlik bilgileri de dahil edilebilir. Konferanstan ayrılırken site bir RTCP BYE paketi gönderir.

eğer telekonferanslar hem ses hem de video sinyalleri kullanılır, ayrı ayrı iletilirler. Her bir trafik türünün iletimi için, diğerinden bağımsız olarak, protokol belirtimi bir RTP oturumu kavramını tanıtmaktadır. Bir oturum, belirli bir hedef aktarım adresi çiftiyle tanımlanır (bir ağ adresi artı RTP ve RTCP için bir çift bağlantı noktası). Her trafik türü için paketler, iki farklı UDP bağlantı noktası çifti ve/veya çok noktaya yayın adresi kullanılarak iletilir. Sesli ve görüntülü iletişim oturumları arasında doğrudan RTP bağlantısı yoktur, ancak her iki oturuma katılan kullanıcının, oturumların bağlanabilmesi için her iki oturum için RTCP paketlerinde aynı kurallı adı kullanması gerekir.

Bu ayrımın bir nedeni, bazı konferans katılımcılarının isterlerse yalnızca bir tür trafik almasına izin verilmesi gerektiğidir. Ayrılmaya rağmen, her iki oturum için RTCP paketlerinde taşınan zamanlama bilgileri kullanılarak kaynak ortamın (ses ve video) eşzamanlı yeniden üretimi sağlanabilir.

Tüm siteler multimedya verilerini her zaman aynı biçimde alamaz. Aynı konumdaki katılımcıların, konferansta ağa geniş bant erişimi olan diğer katılımcıların çoğuna düşük hızlı bir hat üzerinden bağlandığı bir durumu düşünün. Herkesi daha dar bir bant genişliği ve daha düşük kaliteli ses kodlaması kullanmaya zorlamak yerine, dar bir bant genişliği alanına mikser adı verilen bir RTP katmanı iletişim tesisi yerleştirilebilir. Bu mikser, orijinal 20 ms'lik aralıkları geri yüklemek için gelen ses paketlerini yeniden senkronize eder, bu yeniden yapılandırılmış ses akışlarını tek bir akışta karıştırır, ses sinyalini dar bir bant genişliği için kodlar ve paket akışını düşük hızlı bir bağlantı üzerinden iletir. Bu durumda, paketler bir alıcıya veya farklı adreslere sahip bir grup alıcıya adreslenebilir. Alıcı uç noktalarında doğru göstergenin sağlanabilmesi için mesajların kaynağı RTP başlığı, karıştırıcılar için karışık pakette yer alan kaynakları tanımlamanın bir yolunu içerir.

Sesli konferans katılımcılarından bazıları geniş bantlı hatlarla bağlanabilir, ancak IP çok noktaya yayın (IPM) konferansı yoluyla erişilemeyebilir. Örneğin, IP paketlerinin iletilmesine izin vermeyecek bir uygulama katmanı güvenlik duvarının arkasında olabilirler. Bu gibi durumlarda, karıştırıcılara değil, çevirmenler adı verilen diğer RTP düzeyinde iletişim türlerine ihtiyaç vardır. İki çevirmenden biri güvenlik duvarının dışına kurulur ve dışarıdan güvenli bağlantı üzerinden alınan tüm çok noktaya yayın paketlerini güvenlik duvarının arkasındaki diğer çevirmene iletir. Güvenlik duvarının arkasındaki çevirmen bunları tekrar çok noktaya yayın paketleri olarak sitenin dahili ağıyla sınırlı çok kullanıcılı gruba iletir.

Karıştırıcılar ve çevirmenler bir dizi amaç için tasarlanabilir. Örnek: Bireylerin video görüntülerini bağımsız video akışlarına ölçeklendiren ve bunları bir grup sahnesini simüle ederek tek bir video akışında birleştiren bir video karıştırıcı.

RTP / RTCP paketlerinin tüm alanları ağ üzerinden bayt (sekizli) ile iletilir; en önemli bayt önce iletilir. Tüm başlık alanı verileri, uzunluğuna göre hizalanır. İsteğe bağlı olarak belirlenen sekizlilerin değeri sıfırdır.

kontrol protokolü RTCP (RTCP - Gerçek Zamanlı Kontrol Protokolü), periyodik paket iletimini temel alır yönetmek RTP ile aynı dağıtım mekanizmasını kullanan bir iletişim oturumundaki tüm katılımcılara. Alt katman protokolü, örneğin aşağıdakileri kullanarak bilgi ve kontrol paketlerinin çoğullanmasını sağlamalıdır. farklı sayılar UDP bağlantı noktaları. RTCP'nin dört ana işlevi vardır.

Ana işlevi, veri dağıtımının kalitesini değerlendirmek için geri bildirim sağlamaktır. Bir aktarım protokolü olarak RTCP'nin doğal bir işlevidir ve diğer aktarım protokollerinin akış denetimi ve tıkanıklık denetimi işlevleriyle ilişkilidir. Geri bildirim uyarlamalı kodlamayı yönetmek için doğrudan yararlı olabilir, ancak IP çok noktaya yayın ile yapılan deneyler, alıcı geri bildiriminin yayılma kusurlarını teşhis etmek için de önemli olduğunu göstermiştir. Tüm katılımcılara veri alımıyla ilgili geri bildirim raporları göndermek, sorunların yerel mi yoksa küresel mi olduğunu değerlendirmek için gözlem yapılmasına olanak tanır. Ağ servis sağlayıcıları gibi kuruluşlar için IPM dağıtım mekanizması ile geri bildirim bilgisi almak ve ağ sorunlarının teşhisinde üçüncü taraf bir monitör olarak hareket etmek de mümkündür. Bu geri bildirim özelliği, RTCP gönderici ve alıcı raporları ile sağlanır.
RTCP, taşıma katmanında "kurallı ad" (CNAME) adı verilen kalıcı bir RTP veri kaynağı tanımlayıcısı tutar. Bir çakışma algılanırsa veya program yeniden başlatılırsa SSRC Kimliği değişebileceğinden, alıcıların her katkıda bulunanları izlemek için kurallı CNAME'ye ihtiyacı vardır. Alıcılar ayrıca aşağıdakiler için CNAME gerektirir: kümeyi eşleme bilgi, örneğin ses ve video sinyallerini senkronize ederken, belirli bir katılımcıdan birden çok ilişkili RTP oturumuna akar.
İlk iki özellik, tüm eşlerin RTCP paketleri göndermesini gerektirir; bu nedenle, eşler arası ölçeklenebilirliğe izin vermek için RTP'nin hız azaltıcı olması gerekir. Her katılımcı tarafından gönderildiğinde telekonferanslar diğer tüm katılımcılara kontrol paketleri, her biri toplam katılımcı sayısını bağımsız olarak tahmin edebilir.
Dördüncü, isteğe bağlı bir RTCP işlevi, kullanıcı arayüzüne yansıtılacak olan oturum kontrol bilgilerini (örneğin, katılımcı kimliği) sağlamalıdır. Bu, büyük olasılıkla, üyelerin bir gruba sahiplik denetimi veya müzakeresi olmadan katılıp gruptan ayrıldığı "gevşek kontrol edilen" oturumlarda yararlı olacaktır.

Birden üçe kadar olan işlevler, IP çok noktaya yayında RTP kullanıldığında gereklidir ve diğer tüm durumlarda önerilir. RTP uygulama geliştiricilerinin, kullanıcıları barındıracak şekilde ölçeklenmeyen yalnızca çift yönlü mekanizmalardan kaçınmaları önerilir.

RTP, bir uygulamanın bir iletişim oturumunun temsil edilebilirliğini birkaç katılımcıdan birkaç bine otomatik olarak ölçeklendirmesine olanak tanır. Örneğin, sesli konferansta, veri trafiği temelde kendi kendini sınırlar çünkü aynı anda yalnızca bir veya iki kişi konuşabilir ve grup dağıtımında, katılımcı sayısına bakılmaksızın herhangi bir bağlantıdaki veri hızı nispeten sabit kalır. Ancak, yönetim trafiği kendi kendini sınırlamaz. Her katılımcıdan gelen alım raporları sabit bir oranda gönderilirse, katılımcı sayısındaki artışla yönetim trafiği lineer olarak büyüyecektir. Bu nedenle, kontrol paketlerinin iletim frekansını azaltmak için özel bir mekanizma sağlanmalıdır.

Her oturum için, veri trafiğinin, tüm katılımcılar tarafından paylaşılan, oturumun bant genişliği adı verilen toplu bir sınırı karşıladığı varsayılır. Bu bant genişliği ağ tarafından rezerve edilebilir ve sınırlandırılabilir. Oturum bant genişliği, medya kodlama türünden bağımsızdır, ancak kodlama türünün seçimi, iletişim oturumunun bant genişliği ile sınırlı olabilir. Oturum bant genişliği parametresinin, medya uygulamasını çağırdığında oturum yönetimi uygulaması tarafından sağlanması beklenir, ancak medya uygulamaları ayrıca, oturum için seçilen kodlama türü için tek gönderici veri bant genişliğine dayalı bir varsayılan ayarlayabilir.

Kontrol ve veri trafiği için bant genişliği hesaplamaları, temel taşıma ve ağ katmanı protokollerine (UDP ve IP gibi) dayanır. Veri Bağlantı Katmanı (DLC) başlıkları, bir paket iletilirken farklı RPC düzeyinde başlıklarla kapsüllenebileceğinden, hesaplamalarda dikkate alınmaz.

Kontrol trafiği, oturum bant genişliğinin küçük ve bilinen bir bölümüyle sınırlandırılmalıdır: aktarım protokolünün ana işlevi olan veri iletimini etkilemeyecek kadar küçük; yönetim trafiğinin protokole verilen bant genişliği spesifikasyonuna dahil edilebileceği bilinmektedir. kaynak rezervasyonu ve böylece her katılımcı kendi payını bağımsız olarak hesaplayabilir. Oturum bant genişliğinin RTCP'ye ayrılan kısmının %5'e ayarlanması gerektiği varsayılır. Tüm oturum katılımcıları, hesaplanan kontrol paketi aralığının aynı olması için aynı miktarda RTCP bant genişliği KULLANMALIDIR. Bu nedenle, bu sabitler her profil için ayarlanmalıdır.

Kontrol trafiği için ayrılan bant genişliğini katılımcılar arasında bölmek için bileşik RTCP paketleri gönderme arasındaki aralığı hesaplama algoritması aşağıdaki ana özelliklere sahiptir:

gönderenler, oturumlarda olduğu gibi kontrol trafiğinin bant genişliğinin en az 1/4'ünü paylaşır. büyük miktar alıcılar, ancak az sayıda gönderen; bağlantı kurulur kurulmaz, katılımcılar kısa bir süre içinde iletim yapan sitelerin CNAME'ini alırlar;
Katılımcı sayısının az olduğu ve trafiğin büyük sayılar yasasına göre düzgünleştirilmediği durumlarda, RTCP paketlerinin izin verilen bant genişliğini aşmasını önlemek için RTCP paketleri arasındaki tahmini aralığın en az 5 saniye olması gerekir;
RTCP paketleri arasındaki aralık, tüm katılımcıların kasıtsız senkronizasyonunu önlemek için yarı ile bir buçuk hesaplanan aralıklar arasında rastgele değişir. Bir oturuma katıldıktan sonra gönderilen ilk RTCP paketi, örneğin bir oturumun başladığını duyururken, aynı anda birden fazla sitede bir uygulama başlatılırsa, rastgele (minimum RTCP aralığının yarısına kadar) ertelenir;
iletilen kontrol bilgisi miktarındaki değişikliklere otomatik olarak uyum sağlamak için, alınan ve gönderilen tüm paketler kullanılarak bileşik RTCP paketinin ortalama boyutunun dinamik bir tahmini hesaplanır;
bu algoritma, paket iletiminin tüm katılımcılar için geçerli olduğu oturumlar için kullanılabilir. Bu durumda, oturum bant genişliği parametresi, bireysel gönderenin bant genişliğinin katılımcı sayısına göre ürünüdür ve RTP bant genişliği, uzunluğun bir göstergesini sağlamak için temeldeki protokole dayanır. RTP paketlerinin maksimum uzunluğu, yalnızca temel alınan protokollerle sınırlıdır.
Birden çok RTP paketi, bir UDP paketi gibi tek bir alt katman protokol veri biriminde taşınabilir. Bu, başlıkların fazlalığını azaltır ve farklı akışlar arasındaki senkronizasyonu basitleştirir.

İnternetin hızlı büyümesi, veri aktarımının hızına ve hacmine yeni talepler getirmektedir. Ağ kapasitesini artırmak tek başına tüm bu talepleri karşılamak için yeterli değildir; akıllı ve verimli trafik ve hat tıkanıklığı yönetimi yöntemleri gereklidir.

Gerçek zamanlı uygulamalarda, gönderici sabit bir hızda bir veri akışı oluşturur ve alıcı (veya alıcılar) bu verileri uygulamaya aynı oranda sağlamalıdır. Bu tür uygulamalar arasında örneğin sesli ve görüntülü konferans, canlı video, tıpta uzaktan teşhis, bilgisayar telefonu, dağıtılmış etkileşimli simülasyon, oyunlar, gerçek zamanlı izleme vb. bulunur.

En yaygın kullanılan taşıma protokolü TCP'dir. TCP çok çeşitli dağıtılmış uygulamaları destekleyebilirken, gerçek zamanlı uygulamalar için uygun değildir.

Yeni gerçek zamanlı aktarım protokolü bu sorunu çözmek için tasarlandı - RTP(Gerçek Zamanlı Aktarım Protokolü), verilerin belirli sınırlar içinde bir veya daha fazla hedefe gecikmeyle teslim edilmesini garanti eder, yani veriler gerçek zamanlı olarak oynatılabilir.

RTP, hiçbir tür paket teslimini, iletim doğruluğunu veya bağlantı güvenilirliği mekanizmalarını desteklemez. Tüm bu işlevler taşıma protokolüne atanır. RTP, UDP'nin üzerinde çalışır ve bir RTP oturumunda birden çok katılımcı arasında gerçek zamanlı veri aktarımını destekleyebilir.

Not

Her RTP katılımcısı için bir oturum, bir çift paket hedef aktarım adresi (bir ağ adresi - IP ve bir çift bağlantı noktası: RTP ve RTCP) tarafından belirlenir.

RTP paketleri aşağıdaki alanları içerir: Veriyi hangi katılımcıların oluşturduğunu gösteren gönderici tanımlayıcısı, verinin alıcı taraf tarafından doğru aralıklarla oynatılabilmesi için paketin oluşturulduğu zaman damgaları, aktarım sırası hakkında bilgi ve bilgi paket içeriğinin doğası hakkında, örneğin video kodlamanın türü hakkında (MPEG, Indeo, vb.). Bu tür bilgilerin mevcudiyeti, ilk gecikmenin değerini ve iletim arabelleğinin boyutunu tahmin etmeyi mümkün kılar.

Not

Tipik bir gerçek zamanlı ortamda gönderici, paketleri sabit bir hızda üretir. Düzenli aralıklarla gönderilirler, ağdan geçerler ve alındıklarında verileri gerçek zamanlı olarak oynatan alıcı tarafından alınırlar. Ancak, paketlerin ağ üzerinden iletiminin gecikme süresindeki değişiklikler nedeniyle düzensiz aralıklarla gelebilirler. Bu etkiyi telafi etmek için gelen paketler arabelleğe alınır, bir süre yapıştırılır ve ardından sabit bir oranda sağlanır. yazılımçıktı üreten. Bu nedenle, gerçek zamanlı protokolün çalışması için her paketin bir zaman damgası içermesi gerekir, böylece alıcı gelen verileri gönderen ile aynı hızda yeniden üretebilir.

RTP, iletilen verilerin yükünün biçimini tanımladığından (ve düzenlediğinden), senkronizasyon kavramı, RTP çeviri motorunun kısmen sorumlu olduğu - mikser - doğrudan bununla ilgilidir. Bir veya daha fazla kaynaktan RTP paketi akışları alan karıştırıcı, bunları birleştirir ve bir veya daha fazla alıcıya yeni bir RTP paketi akışı gönderir. Mikser, örneğin birden fazla ses kaynağını birleştirirken, verileri kolayca birleştirebilir ve biçimini değiştirebilir. Yeni sistemin oturuma katılmak istediğini, ancak ağa olan kanalının tüm RTP akışlarını desteklemek için yeterli kapasiteye sahip olmadığını varsayalım, ardından mikser tüm bu akışları alır, bir araya getirir ve sonuncuyu yeni üyeye aktarır. oturum. Birden fazla akış alırken, mikser sadece PCM değerlerini ekler. Karıştırıcı tarafından oluşturulan RTP başlığı, verileri pakette bulunan göndericinin tanımlayıcısını içerir.

Daha basit bir cihaz, bir çevirmen, gelen her RTP paketi için bir giden RTP paketi oluşturur. Bu mekanizma, paketteki verilerin biçimini değiştirebilir veya verileri bir etki alanından diğerine aktarmak için farklı bir dizi düşük seviyeli protokol kullanabilir. Örneğin, potansiyel bir alıcı, oturumdaki diğer katılımcılar tarafından kullanılan yüksek hızlı videoyu işleyemeyebilir. Çevirmen, videoyu daha düşük bit hızı gerektiren daha düşük kaliteli bir biçime dönüştürür.

RTP, yalnızca kullanıcı verilerini (genellikle çok noktaya yayın) oturumdaki tüm katılımcılara iletmek için kullanılır. RTP ile birlikte, asıl görevi RTP iletimi üzerinde kontrol sağlamak olan RTCP (Gerçek Zamanlı Aktarım Kontrol Protokolü) protokolü çalışır. RTCP, RTP (genellikle UDP) ile aynı temel taşıma protokolünü kullanır, ancak farklı bir bağlantı noktası numarası.

RTCP çeşitli işlevlere hizmet eder:

Aşırı yük durumunda hizmet kalitesinin ve geri bildirimin sağlanması ve izlenmesi. RTCP paketleri çok noktaya yayın paketleri olduğundan, oturumdaki tüm katılımcılar, diğer katılımcıların ne kadar iyi performans gösterdiğini ve aldığını takdir edebilir. Gönderici mesajları, alıcıların veri hızını ve iletim kalitesini ölçmesine olanak tanır. Alıcıların mesajları, paket kaybı ve aşırı titreşim dahil, karşılaştıkları sorunlar hakkında bilgiler içerir. Alıcılardan gelen geri bildirimler de dağıtım hatalarını teşhis etmek için önemlidir. Ağ yöneticisi, oturumdaki tüm katılımcıların mesajlarını analiz ederek, belirli bir sorunun bir katılımcıyla mı ilgili yoksa genel nitelikte mi olduğunu belirleyebilir. Gönderen uygulama, örneğin iletişim kanallarından birinin arızası nedeniyle sorunun bir bütün olarak sistemin özelliği olduğu sonucuna varırsa, kaliteyi düşürerek veya hatta video iletmeyi reddederek veri sıkıştırma oranını artırabilir - bu, verilerin düşük kapasiteli bağlantı üzerinden iletilmesine izin verir.
Gönderici kimliği. RTCP paketleri, gönderenin standart bir metin açıklamasını içerir. Rastgele seçilen bir eşitleme kaynağı kimliğinden ziyade veri paketlerinin oluşturucusu hakkında daha fazla bilgi sağlarlar. Ayrıca, kullanıcının farklı oturumlardan gelen akışları tanımlamasına yardımcı olurlar.
Oturum boyutu tahmini ve ölçekleme. Hizmet kalitesini ve tıkanıklığı yönetmek için geri bildirim sağlamak ve göndereni belirlemek için tüm katılımcılar periyodik olarak RTCP paketleri gönderir. Katılımcı sayısı arttıkça bu paketlerin iletim frekansı azalmaktadır. Az sayıda katılımcı ile en fazla her 5 saniyede bir RTCP paketi gönderilir. RFC-1889, katılımcıların toplam katılımcı sayısına göre RTCP paketlerinin sıklığını sınırladığı bir algoritmayı açıklar. Hedef, RTCP trafiğinin toplam oturum trafiğinin %5'ini geçmemesidir.

RTP, akış odaklı bir protokoldür. RTP paket başlığı, gerçek zamanlı iletim ihtiyaçları göz önünde bulundurularak oluşturulmuştur. Veri akışının alıcı uçta doğru bir şekilde birleştirilmesi için paketlerin sırası hakkında bilgi ve oynatma sırasında doğru çerçeve serpiştirme ve video ve ses gibi çoklu veri akışlarını senkronize etmek için bir zaman damgası içerir.

Her RTP paketinin bir ana başlığı ve muhtemelen uygulamaya özel ek alanları vardır.

TCP'yi bu uygulamalar için aktarım protokolü olarak kullanmak birkaç nedenden dolayı mümkün değildir:

Bu protokol yalnızca iki uç nokta arasında bağlantıya izin verir, bu nedenle çok noktaya yayın iletimi için uygun değildir.
TCP, gerçek zamanlı uygulama artık onları beklemediğinde gelen kayıp bölümlerin yeniden iletilmesine izin verir.
TCP, zamanlama bilgilerini segmentlere bağlamak için uygun bir mekanizmaya sahip değildir - gerçek zamanlı uygulamalar için ek bir gereklilik.

Yaygın olarak kullanılan bir başka taşıma katmanı protokolü olan LJDP, TCP'nin bazı sınırlamalarına sahip değildir, ancak aynı zamanda kritik zamanlama bilgisi sağlamaz.

Her gerçek zamanlı uygulama, gerçek zamanlı iletimi desteklemek için kendi mekanizmalarına sahip olsa da, birçok benzerlikleri vardır, bu da tek bir protokol tanımlamayı oldukça arzu edilir kılar.

Bu görev, verilerin belirli sınırlar dahilinde bir gecikmeyle bir veya daha fazla alıcıya teslim edilmesini garanti eden yeni gerçek zamanlı aktarım protokolünü - RTP'yi (Gerçek Zamanlı Aktarım Protokolü) çözmeyi amaçlamaktadır. gerçek zaman.

İncirde. 1, paket formatı, sıra numarası, kaynaklar, sınırlar ve yük türü gibi öğeleri tanımlayan bir dizi alanı içeren sabit bir RTP başlığını gösterir. Sabit başlığı, veriler hakkında ek bilgiler içeren diğer alanlar izleyebilir.

Pirinç. 1. Sabit RTP başlığı.

V(2 bit). Sürüm alanı. Geçerli sürüm ikinci.
r(1 bit). Alanı doldurun. Bu alan, yükün sonunda dolgu oktetlerinin varlığına işaret eder. Doldurma, uygulama yükün örneğin 32 bitin katı olmasını gerektirdiğinde kullanılır. Bu durumda, son sekizli, dolgu sekizlilerinin sayısını gösterir.
NS(1 bit). Başlık uzantısı alanı. Bu alan belirtildiğinde, deneysel RTP uzantılarında kullanılan ana başlığın ardından isteğe bağlı başka bir başlık gelir.
SS(4 bit). Gönderen sayısı alanı. Bu alan, ana başlığı takip eden tanımlayıcılarla birlikte, verileri pakette bulunan göndericilerin tanımlayıcılarının sayısını içerir.
m(1 bit). İşaret alanı. İşaret bitinin anlamı, yükün türüne bağlıdır. İşaret biti genellikle veri akışının sınırlarını belirtmek için kullanılır. Video durumunda, çerçevenin sonunu belirtir. Ses durumunda, bir sessizlik döneminden sonra konuşmanın başlangıcını belirtir.
RT(7 bit). Yük türü alanı. Bu alan, sıkıştırma ve şifreleme dahil olmak üzere yük türünü ve veri biçimini tanımlar. Sabit durumda, gönderici oturum başına yalnızca bir veri yükü türü kullanır, ancak Gerçek Zamanlı Aktarım Kontrol Protokolü tarafından sinyal verilirse değişen koşullara yanıt olarak bunu değiştirebilir.
Sıra numarası(16 bit). Sıra numarası alanı. Her kaynak, paketleri rastgele bir sayı ile numaralandırmaya başlar, ardından gönderilen her RTP veri paketi için birer birer artırılır. Bu, paket kaybını algılamanıza ve aynı zaman damgasına sahip paketlerin sırasını belirlemenize olanak tanır. Aynı video karesine ait paketler gibi, aynı anda mantıksal olarak oluşturulmuşlarsa, birkaç ardışık paket aynı zaman damgasına sahip olabilir.
zaman damgası(32 bit). Zaman damgası alanı. Bu alan, yük verisinin ilk sekizlisinin oluşturulduğu zamandaki noktayı içerir. Bu alanda belirtilen sürenin birimleri, yükün türüne bağlıdır. Değer, gönderenin yerel saati tarafından belirlenir.
Senkronizasyon Kaynağı (SSRC) Tanımlayıcı(32 bit). Senkronizasyon kaynak tanımlayıcı alanı: Oturum sırasında kaynağı benzersiz şekilde tanımlayan ve ağ adresinden bağımsız, rastgele oluşturulmuş bir sayı. Bu sayı, tek bir kaynaktan gelen veri bölümünün işlenmesinde önemli bir rol oynar.
Katkıda bulunan kaynak (CSRC) Tanımlayıcı(32 bit). Örneğin, bir mikser kullanarak ana akışa "karıştırılmış" kaynak tanımlayıcı alanlarının listesi. Karıştırıcı, bu RTP paketinin oluşturulmasında yer alan SSRC kaynak kimliklerinin tam listesini ekler. Bu listeye CSRC denir. Listedeki öğe sayısı: 0'dan 15'e. Katılımcı sayısı 15'ten fazlaysa, ilk 15 seçilir.Bir örnek, RTP paketlerinin tüm katılımcıların konuşmalarının toplandığı bir sesli konferanstır. kendi SSRC'si - CSRC listesini oluştururlar. Ayrıca, tüm konferansın ortak bir SSRC'si vardır.

RTCP protokolü, herhangi bir kontrol protokolü gibi, hem yapı hem de gerçekleştirdiği işlevler açısından çok daha karmaşıktır (örneğin, IP ve TCP'yi karşılaştırın). RTCP, RTP'ye dayalı olmasına rağmen, işlevlerini uygulamak için kullandığı birçok ek alan içerir.

Şu anda İnternet Mühendisliği Görev Gücü (IETF) tarafından incelenmekte olan Kaynak Rezervasyon Protokolü (RSVP), gecikmenin daha az kritik olduğu geleneksel verilerin aksine, gecikmeye duyarlı veriler için öncelikli sorunu ele almaktadır. RSVP, uç sistemlerin gerekli hizmet kalitesini, özellikle RTP aracılığıyla gerçek zamanlı trafik için kaynakları elde etmek için ağ kaynaklarını ayırmasına izin verir. RSVP öncelikle yönlendiricilerle ilgilenir, ancak uç noktalardaki uygulamaların belirli bir hizmet sınıfı veya öncelik düzeyi için gerekli bant genişliğini ayırmak için RSVP'yi nasıl kullanacaklarını da bilmesi gerekir.

RTP, açıklanan diğer standartlarla birlikte, video ve sesi geleneksel IP ağları üzerinden başarıyla aktarmanıza olanak tanır. RTP / RTCP / RSVP, gerçek zamanlı veri ağları için standartlaştırılmış bir çözümdür. Tek dezavantajı, yalnızca IP ağları için tasarlanmış olmasıdır. Ancak bu sınırlama geçicidir: ağlar bir şekilde bu yönde gelişecektir. Bu çözüm, gecikmeye duyarlı verilerin İnternet üzerinden iletilmesi sorununu çözmeyi vaat ediyor.

RTP protokolünün bir açıklaması RFC-1889'da bulunabilir.

VoIP'de RTP ve RTCP

RTP, IP telefon ağlarındaki ana aktarım protokolüdür. RTP (Gerçek Zamanlı Protokol), multimedya (ses, video), kodlanmış ve paketler halinde paketlenmiş, bilgilerin IP ağları üzerinden katı zaman dilimlerinde iletilmesi için oluşturulmuş gerçek zamanlı bir protokoldür. RTP segmentleri, OSI modelinin farklı seviyelerinde sırasıyla UDP ve IP üzerinden iletilir. Teslimatı garanti etmeyen UDP kullanımı, gerçek zamanlı medya iletiminin katı zamanlaması ve TCP'nin gerçek zamanlı olarak çalışamaması ile ilişkilidir. Bu nedenle, verilerin bir kısmının kaybolmasına rağmen, bu durumda teslimatın zamanında yapılması daha önemlidir.
V Genel görünüm protokolün OSI modelinin katmanları üzerindeki dağılımı aşağıdaki gibidir:
Taşıma katmanı: UDP üzerinden RTP
ağ: IP
Kanal: Ethernet
Fiziksel: Ethernet
RTP protokolünü kullanarak multimedya bilgilerini iletirken aşağıdaki kapsülleme kullanılır:

Minimum RTP segment boyutu 12 bayttır. İlk iki bit protokol versiyonunu tanımlar. Bugün RTPv.2 kullanılmaktadır. Sonraki P alanı da 2 bit uzunluğundadır ve aynı uzunlukta segmentler kullanıldığında veri alanında dolgu karakterlerinin varlığını gösterir. X alanı, genişletilmiş başlığın kullanılıp kullanılmayacağını belirler. 4-bit CC alanı daha sonra RTP başlığının sonundaki CSRC alanlarının sayısını, yani akışı oluşturan kaynakların sayısını tanımlar. Ardından, önemli verileri vurgulamak için kullanılan bir işaretleyici bit olan M alanı gelir. Sonraki PT alanı 7 bit uzunluğundadır. Yük türünü belirlemek için tasarlanmıştır - uygulama için gerekli veriler. Belirtilen kodu kullanarak uygulama, multimedya bilgilerinin türünü ve kod çözme yöntemini belirler.
Başlığın geri kalanı bir SequenceNumber alanından oluşur - paketlerin sırasını ve kayıplarını takip eden segmentin sıra numarası; Zaman Damgası alanları - yükteki ilk kodlanmış örneğin zamanını gösteren senkronizasyon kodu, bu işaret, gecikme varyasyonunun neden olduğu kalite kayıplarını ortadan kaldırmak için senkronizasyon kurtarma arabellekleri tarafından kullanılır; SSRC eşitleme kaynak alanları, çoğullama yetenekleri oluşturmak için bir RTP oturumunu diğerinden ayıran rastgele bir sayıdır. RTP başlığının kalıcı sabit bölümünden sonra, veri kaynaklarını tanımlayan 15'e kadar otuz iki bitlik CSRC alanı eklenebilir.
Bir RTP oturumu oluşturma prosedürünü açıklayalım. Protokol, trafiğin farklı şekiller ayrı iletişim oturumlarında iletilir. Bir oturum oluşturmak için, bir çift hedef taşıma adresi tanımlamak gerekir, yani. RTP ve RTCP için bir ağ adresi ve iki bağlantı noktası. Bu nedenle, bir video konferans için, ses ve videoyu farklı oturumlarda karşılık gelen farklı hedef bağlantı noktalarıyla iletmek gerekir. Aynı oturumda serpiştirmeyi kullanarak farklı trafik türlerinin iletilmesi aşağıdaki sorunlara neden olabilir:
- trafik türlerinden birini değiştirirken, oturumdaki hangi parametrenin yeni bir değerle değiştirilmesi gerektiğini belirlemek mümkün değildir;
- bir oturum oluşturmak için yalnızca bir zaman aralığı kullanılır ve heterojen trafik iletirken her türün kendi aralığı olacaktır ve bunlar farklı olacaktır;
- RTP karıştırıcı, farklı trafik türlerinin serpiştirilmiş akışlarını tek bir akışta birleştiremez;
- bir RTP oturumunda çeşitli trafik türlerinin iletimi aşağıdaki nedenlerle imkansızdır: farklı ağ yollarının kullanılması veya ağ kaynaklarının dağıtımı; gerektiğinde multimedya verilerinin bir alt kümesinin alınması, örneğin, video sinyalinin mevcut bant genişliğini aşması durumunda yalnızca ses; farklı trafik türleri için ayrı işlemler kullanan alıcı uygulamaları, ayrı RTP oturumları kullanırken tek veya çoklu işlem uygulamalarına izin verir.

Ancak, RTP (Gerçek Zamanlı Aktarım Protokolü) ve UDP (Kullanıcı Datagram Protokolü) kaliteyi garanti etmez, yani QoS (Hizmet Kalitesi) ile çalışmaz. Bu nedenle, RTP, bir RTP oturumunun durumu hakkında ek bilgi sağlayan Gerçek Zamanlı Aktarım Kontrol Protokolü (RTCP) tarafından desteklenir.
RTCP'nin dört ana işlevi vardır:
I. RTCP protokolünün temel amacı, veri iletiminin kalitesini sağlamak için geri bildirim sağlamaktır. Geri bildirim, uyarlamalı kodlama iletim uygulamalarında doğrudan yararlı olabilir. Ayrıca, IP çok noktaya yayın kullanırken, alıcıların mesajların (paketlerin) iletimindeki hataları teşhis etmesi son derece önemlidir. Alım raporlarıyla birlikte mesajların gönderilmesi, gönderen tarafın, eğer varsa, başarısız mesaj iletiminin nedenini belirlemesine olanak tanır.
II. RTCP, Kanonik Ad veya Kanonik Ad olarak adlandırılan kaynak RTP için değişmez bir taşıma katmanı tanımlayıcısı içerir. SSRC tanımlayıcısı çarpışma (çarpışma) durumunda değiştirilebildiğinden, alıcının her bir katılımcıyı takip edebilmesi için Cname değerine ihtiyacı vardır. Alıcı, aynı anda birden fazla oturum kurarken bir katılımcıdan gelen birçok veri akışını eşleştirmek için, örneğin sesli videoyu iletirken ses ve video kanallarını senkronize etmek için Cname'yi de kullanır.
III. Yukarıdaki iki özellik, tüm oturum katılımcılarının RTCP paketleri gönderdiğini varsayar, bu nedenle RTP'nin çok sayıda kullanıcıyla oturum oluşturması için iletim hızının kontrol edilmesi gerekir. Her katılımcı, kontrol paketlerini herkese gönderdiğinde, herhangi bir ortak, oturumdaki toplam katılımcı sayısını bağımsız olarak belirleyebilir. Bu, RTCP mesajlarının aktarım hızını hesaplamak için gereklidir.
IV. bu fonksiyon grafik kullanıcı arayüzü tarafından kullanılan katılımcı kimliği gibi minimum gerekli kontrol bilgilerini iletmeye hizmet eder. Bu özellik, kullanıcıların parametreler ve özellikler üzerinde uygun bir anlaşma olmaksızın girip çıktığı, gevşek bir şekilde kontrol edilen oturumlar için kullanılır. RTCP, tüm katılımcılarla iletişim için uygun bir kanal görevi görür, ancak bir uygulamanın tüm iletişim gereksinimlerini mutlaka desteklemez.
Çok noktaya yayın kullanan IP ağlarında, RTP oturumları kullanılırken bir, iki ve üç işlevler zorunludur. Diğer ağlarda ve ortamlarda aktarım yaparken de kullanılması önerilir. Bugün, RTP uygulamalarının geliştiricilerinin, yalnızca benzersiz bir modda değil, çok noktaya yayın modunda çalışmaya izin veren araçlar kullanması önerilir.
RTCP paket formatına bir göz atalım.
Protokol standardı, birkaç tür RTCP paketi tanımlar. RTCP, hizmet bilgilerini aktarmak için tasarlanmıştır:
sr: Gönderen raporu. Doğrudan aktif gönderici olan oturum katılımcılarının alım ve iletim istatistikleri için gereklidir;
rr: Alıcı raporu. Alıcı olmayan katılımcıların istatistikleri için gereklidir;
sdes: Kaynağı tanımlar, Cname'yi içerir;
bye: Seansın sonunu (çıkışını) belirtmek için kullanılır;
uygulama: Uygulamaya özel işlevler;
Her RTCP paketi, RTP paketleri tarafından kullanılan RTP protokolünde olduğu gibi sabit bir bölümden ve ardından paketin türüne bağlı olarak uzunlukları değişebilen, ancak 32 bitin katları olan alanlardan oluşur. Başlığın sabit kısmındaki hizalama gereksinimleri ve uzunluk alanı, RTCP paketlerini birleştirmek için tanıtıldı. UDP gibi düşük katmanlı bir taşıma protokolü üzerinden gönderilen bileşik bir RTCP paketi elde etmek için herhangi bir ayırıcı tanıtılmadan birden fazla RTCP paketi birbiriyle birleştirilebilir. Düşük katman protokolü toplam uzunluğu belirleyeceği ve bileşik paketin sonunu belirleyeceğinden, bireysel RTCP paketleri için belirli bir sayaç yoktur.

Gönderici mesajının RTCP paketinin formatı, yukarıdaki şekilde gösterildiği gibi aşağıdaki gibidir.

RTCP paketleri aşağıdaki doğrulama kontrollerine tabidir.
- RTP sürüm alanı 2'ye eşit olmalıdır.
- Kompozit paketteki ilk RTCP paketinin veri tipi alanı SR veya RR olacaktır.
- Dolgu yalnızca sonuncusunda mevcut olabileceğinden, bileşik bir RTCP paketinin ilk paketi için dolgu biti (P) sıfır olmalıdır.
- Bireysel RTCP paket alanlarının uzunluğu, birleşik paketin toplam uzunluğuna eklenmelidir.

Bir gün VoIP'nin (IP üzerinden ses) ne olduğunu ve tüm bu çılgın kısaltmaların ne anlama geldiğini çabucak bulmanız gerekiyorsa, umarım bu eğitim size yardımcı olacaktır. Ek telefon hizmetleri türlerini (çağrı aktarımı, sesli posta, konferans görüşmeleri vb.) yapılandırma konularının burada dikkate alınmadığını hemen not ediyorum.

Öyleyse, kesimin altında neyle ilgileneceğiz:

Temel konseptler telefon: cihaz türleri, bağlantı şemaları
SIP / SDP / RTP protokol paketi: nasıl çalışır
Basılan düğmeler hakkındaki bilgiler nasıl iletilir?
Ses ve fakslar nasıl iletilir?
IP telefonda dijital sinyal işleme ve ses kalitesi güvencesi

Genel olarak, yerel bir aboneyi normal bir telefon hattı üzerinden bir telefon sağlayıcısına bağlama şeması aşağıdaki gibidir:

Sağlayıcı tarafında (PBX) FXS (Döviz Borsası Abonesi) bağlantı noktasına sahip bir telefon modülü kuruludur. Evde veya ofiste, FXO (Döviz Bürosu) portu ve çevirici modülü olan bir telefon veya faks kurulur.

Tarafından dış görünüş FXS ve FXO bağlantı noktaları hiçbir şekilde farklılık göstermez, bunlar sıradan 6 pinli RJ11 konektörleridir. Ancak bir voltmetre yardımıyla bunları ayırt etmek çok kolaydır - FXS bağlantı noktasında her zaman bir miktar voltaj olacaktır: telefon açıkken 48/60 V veya arama sırasında 6-15 V. FXO'da, hatta bağlı değilse voltaj her zaman 0'dır.

Sağlayıcı tarafında bir telefon hattı üzerinden veri aktarmak için, SLIC (abone hattı arayüz devresi) modülünde ve abone tarafında - DAA (Doğrudan Erişim Düzenlemesi) modülü kullanılarak uygulanabilen ek mantık gereklidir.

Günümüzde kablosuz DECT telefonlar (Dijital Avrupa Kablosuz Telekomünikasyon) oldukça popülerdir. Tasarımları gereği sıradan telefonlara benzerler: ayrıca bir FXO bağlantı noktasına ve bir çevirici modülüne sahiptirler, ancak bir modül de eklenmiştir. kablosuz 1.9 GHz'de istasyonlar ve ahizeler.

Aboneler, PSTN, PSTN olarak da bilinen halka açık bir telefon ağı olan PSTN ağına (Genel Anahtarlamalı Telefon Ağı) bağlanır. PSTN ağı aşağıdakiler kullanılarak organize edilebilir: farklı teknolojiler: ISDN, optik, POTS, Ethernet. Normal bir analog / bakır hat kullanırken özel bir PSTN durumu - POTS (Plain Old Telephone Service) - basit bir eski telefon sistemi.

İnternetin gelişmesiyle telefon iletişimi geçiş yapmak yeni seviye... Sabit telefonlar, özellikle iş ihtiyaçları için giderek daha az kullanılmaktadır. DECT telefonlar biraz daha kullanışlıdır, ancak evin çevresiyle sınırlıdır. GSM telefonları daha da kullanışlıdır, ancak ülke içinde sınırlıdırlar (roaming pahalıdır). Ancak IP telefonlar için aynı zamanda yazılım telefonlarıdır (SoftPhone), İnternet erişimi dışında herhangi bir kısıtlama yoktur.

Skype, bir softphone'un en ünlü örneğidir. Pek çok şey yapabilir, ancak iki önemli dezavantajı vardır: kapalı mimari ve telefon dinlemenin hangi yetkililer tarafından bilindiği. İlki nedeniyle, kendi telefon mikro ağınızı oluşturmanın bir yolu yoktur. Ve ikincisi nedeniyle, özellikle kişisel ve ticari konuşmalar sırasında casusluk yapmak pek hoş değil.

Neyse ki, güzelliklerle kendi iletişim ağlarınızı oluşturmak için açık protokoller var - bunlar SIP ve H.323. Göreceli basitliği ve esnekliği ile açıklanabilecek H.323'e göre SIP protokolüne dayalı yazılım telefonları biraz daha fazladır. Ancak bazen bu esneklik tekerleklere büyük çubuklar sığdırabilir. Hem SIP hem de H.323, medyayı aktarmak için RTP protokolünü kullanır.

İki abonenin nasıl bağlandığını anlamak için SIP protokolünün temel ilkelerini ele alalım.

SIP (Oturum Başlatma Protokolü) bir oturum (sadece bir telefon değil) kurmak için kullanılan bir protokoldür.UDP üzerinden metin tabanlı bir protokoldür. TCP üzerinden SIP kullanmak da mümkündür, ancak bunlar nadir görülen durumlardır.

SDP (Oturum Açıklama Protokolü), iletilen verilerin türünü (ses ve video için, bunlar codec bileşenleri ve biçimleri, fakslar için - iletim hızı ve hata düzeltme) ve hedef adreslerini (IP ve bağlantı noktası) müzakere etmek için bir protokoldür. Aynı zamanda metin tabanlı bir protokoldür. SDP parametreleri, SIP paketlerinin gövdesinde iletilir.

RTP (Gerçek Zamanlı Aktarım Protokolü), bir ses / video veri aktarım protokolüdür. UDP üzerinden ikili bir protokoldür.

SIP paketlerinin genel yapısı:

Başlangıç Satırı: İstendiğinde SIP yöntemini (komutunu) veya yanıt verirken bir SIP yöntemi yürütmenin sonucunu gösteren bir alan.
Başlıklar: Başlangıç Satırına ek bilgiler, ÖZELLİK: DEĞER çiftlerini içeren satırlar olarak biçimlendirilir.
Gövde: ikili veya metin verileri. Genellikle SDP parametrelerini veya mesajlarını aktarmak için kullanılır.

Burada ortak bir prosedür - çağrı kurulumu için iki SIP paketi örneği verilmiştir:

Solda SIP INVITE paketinin içeriği, sağda - buna yanıt - SIP 200 OK.

Ana alanlar çerçevelerle vurgulanır:

Yöntem / İstek-URI, SIP yöntemini ve URI'yi içerir. Örnekte, bir oturum kuruldu - DAVET yöntemi, aboneye bir çağrı [e-posta korumalı]
Durum Kodu - önceki SIP komutuna yanıt kodu. Bu örnekte, komut başarıyla tamamlandı - kod 200, yani. abone 555 telefonu açtı.
Via - 777 abonesinin cevap beklediği adres. 200 OK mesajı için bu alan DAVET mesajından kopyalanır.
Kimden / Kime - Mesajı gönderen ve alıcının görünen adı ve adresi. 200 OK mesajı için bu alan DAVET mesajından kopyalanır.
Cseq, komutun sıra numarasını ve ait olduğu yöntemin adını içerir. bu mesaj... 200 OK mesajı için bu alan DAVET mesajından kopyalanır.
İçerik Türü, Gövde bloğunda iletilen veri türüdür, bu durumda SDP verisidir.
Bağlantı Bilgileri - İkinci abonenin RTP paketlerini (veya T.38 üzerinden faks iletimi durumunda UDPTL paketlerini) göndermesi gereken IP adresi.
Medya Açıklaması - ikinci abonenin belirtilen verileri iletmesi gereken bağlantı noktası. Bu durumda, bu ses (ses RTP / AVP) ve desteklenen veri türlerinin bir listesidir - PCMU, PCMA, GSM kodekleri ve DTMF sinyalleri.

Bir SDP mesajı, FIELD = VALUE çiftlerini içeren satırlardan oluşur. Ana alanlardan şunları not edebilirsiniz:

Ö- Köken, oturum düzenleyicinin adı ve oturum kimliği.
ile birlikte- Bağlantı Bilgileri, daha önce açıklanan alan.
m- Medya Açıklaması, daha önce açıklanan alan.
a- medya öznitelikleri, iletilen verilerin biçimini belirtin. Örneğin, sesin yönünü belirtin - alım veya iletim (sendrecv), kodekler için örnekleme oranını ve referans numarasını (rtpmap) belirtin.

RTP paketleri, belirli bir formatta kodlanmış ses / video verilerini içerir. Bu biçim PT (yük tipi) alanında belirtilir. Değer yazışma tablosu bu alanın belirli bir biçim için bkz. https: // wikipedia org wiki RTP sesli video profili.

Ayrıca RTP paketlerinde, benzersiz bir SSRC tanımlayıcısı (RTP akışının kaynağını belirler) ve bir zaman damgası (ses veya videonun tek tip oynatımı için kullanılan zaman damgası) belirtilir.

Bir SIP sunucusu (Yıldız işareti) aracılığıyla iki SIP abonesi arasındaki etkileşime bir örnek:

SIP telefonu açılır açılmaz, uzak sunucuya (SIP Registar) kaydettiği ilk şey, ona bir SIP REGISTER mesajı gönderir.

Bir abone arandığında, gövdesi ses / video aktarım parametrelerini (hangi kodeklerin desteklendiği, hangi IP ve bağlantı noktasına ses gönderileceği vb.) belirten bir SDP mesajı içeren bir SIP INVITE mesajı gönderilir.

Uzak abone telefonu açtığında sadece uzak aboneye ait olmak üzere SDP parametreleriyle de SIP 200 OK mesajı alıyoruz. Gönderilen ve alınan SDP parametrelerini kullanarak, bir RTP ses / video iletim oturumu veya bir T.38 faks iletim oturumu oluşturabilirsiniz.

Alınan SDP parametreleri bize uygun değilse veya ara SIP sunucusu, RTP trafiğini kendi içinden geçirmemeye karar verdiyse, REINVITE adı verilen SDP yeniden anlaşma prosedürü gerçekleştirilir. Bu arada, tam olarak bu prosedür nedeniyle, ücretsiz SIP proxy sunucularının bir dezavantajı vardır - her iki abone de aynı yerel ağdaysa ve proxy sunucusu NAT'ın arkasındaysa, RTP trafiğini yeniden yönlendirdikten sonra abonelerin hiçbiri duymaz bir diğeri.

Görüşme bittikten sonra telefonu kapatan abone SIP BYE mesajı gönderir.

Bazen bir oturum kurduktan sonra, bir konuşma sırasında ek hizmet türlerine (ADO) erişmeniz gerekir - arama bekletme, aktarma, sesli posta vb. - basılan düğmelerin belirli kombinasyonlarına tepki veren.

Dolayısıyla, normal bir telefon hattında bir numarayı çevirmenin iki yolu vardır:

Darbe - tarihsel olarak ilki, esas olarak çevirmeli çeviricili telefonlarda kullanıldı. Çevirme, aranan numaraya göre telefon hattının sıralı olarak kapanması ve açılması nedeniyle gerçekleşir.
Ton - DTMF kodlarıyla bir numara çevirme (Çift Tonlu Çoklu Frekans) - her telefon düğmesinin kendi iki sinüsoidal sinyal (ton) kombinasyonu vardır. Goertzel'in algoritmasını uygulayarak, basılan düğmeyi belirlemek oldukça kolaydır.

Bir arama sırasında, darbe yöntemi, basılan düğmeyi iletmek için uygun değildir. Bu nedenle, "0" iletmek yaklaşık 1 saniye sürer (100 ms'lik 10 darbe: 60 ms - hat sonu, 40 ms - hat kapanması) artı rakamlar arasında bir duraklama için 200 ms. Ek olarak, darbeli arama sırasında karakteristik tıklamalar sıklıkla duyulacaktır. Bu nedenle, sıradan telefonda, VAS'a yalnızca ton erişim modu kullanılır.

VoIP telefonunda, basılan düğmeler hakkındaki bilgiler üç şekilde iletilebilir:

DTMF Inband - bir ses tonunun oluşturulması ve bunun ses verileri (geçerli RTP kanalı) içinde iletilmesi - bu normal bir tonlu aramadır.
RFC2833 - basılan tuş, ses seviyesi ve süre hakkında bilgi içeren özel bir RTP paket telefon olayı oluşturulur. DTMF RFC2833 paketlerinin iletileceği RTP formatının numarası, SDP mesajının gövdesinde belirtilir. Örneğin: a = rtpmap: 98 telefon olayı / 8000.
SIP INFO - Basılan tuş, ses seviyesi ve süre hakkında bilgi içeren bir SIP INFO paketi oluşturulur.

Ses verileri içinde DTMF iletiminin (Inband) birkaç dezavantajı vardır - bunlar, ton üretirken/gömerken ve bunların algılanması sırasında ek kaynaklar, DTMF kodlarını bozabilen bazı kodeklerin sınırlamaları ve iletim sırasında zayıf güvenilirliktir (paketlerin bazıları kaybolursa, daha sonra algılama aynı tuşa iki kez basılarak gerçekleşebilir).

DTMF RFC2833 ve SIP INFO arasındaki temel fark: SIP proxy sunucusu, sunucunun kendisini atlayarak doğrudan aboneler arasında RTP iletimini etkinleştirirse (örneğin, yıldız işaretiyle canreinvite = evet), sunucu, bunun sonucunda RFC2833 paketlerini fark etmeyecektir. olurlar kullanılamayan hizmetlerŞUBAT. SIP paketleri her zaman SIP proxy sunucuları aracılığıyla iletilir, bu nedenle VAS her zaman çalışacaktır.

Daha önce de belirtildiği gibi, medya verilerini aktarmak için RTP protokolü kullanılır. RTP paketleri her zaman iletilen verinin (kodek) biçimini belirtir.

Ses iletimi için farklı bit hızı/kalite/karmaşıklık oranlarına sahip birçok farklı kodek vardır, açık ve kapalı olanları vardır. Herhangi bir softphone kesinlikle G.711 alaw / ulaw codec'lerini destekler, uygulamaları çok basittir, ses kalitesi kötü değildir, ancak 64 kbps bant genişliği gerektirirler. Örneğin, G.729 codec bileşeni yalnızca 8 kbps gerektirir, ancak çok işlemci yoğundur ve ayrıca ücretsiz değildir.

Faks iletimi için genellikle G.711 codec bileşeni veya T.38 protokolü kullanılır. G.711 faks iletimi, faks normal bir telefon hattı üzerinden gönderilmiş gibi, T.30 faks iletimi ile aynıdır, ancak aynı zamanda analog sinyal hattan alaw/ulaw-hukuk'a göre sayısallaştırılır. Buna Inband T.30 faks iletimi de denir.

T.30 faksları parametrelerini müzakere eder: iletim hızı, datagram boyutu, hata düzeltme tipi. T.38 protokolü, T.30 protokolüne dayanır, ancak Bant İçi iletimden farklı olarak, oluşturulan ve alınan T.30 komutları analiz edilir. Bu şekilde ham veriler değil, tanınan faks kontrol komutları iletilir.

T.38 komutlarını iletmek için UDPTL protokolü kullanılır, UDP tabanlı bir protokoldür, sadece T.38 için kullanılır. T.38 komutlarını aktarmak için TCP ve RTP protokollerini kullanmaya devam edebilirsiniz, ancak bunlar çok daha az kullanılır.

T.38'in ana avantajları, daha az ağ yükü ve Bant İçi faks iletimine kıyasla daha fazla güvenilirliktir.

T.38 modunda faks gönderme prosedürü aşağıdaki gibidir:

Herhangi bir kodlayıcı kullanılarak normal bir ses bağlantısı kurulur.
Gönderen faksa kağıt yüklendiğinde, faksı göndermeye hazır olduğunu belirtmek için periyodik olarak bir T.30 CNG (Arama Sesi) sinyali gönderir.
Alıcı tarafta, bir T.30 CED (Aranan Terminal Tanımlaması) sinyali üretilir - bu, faks almaya hazır olma durumudur. Bu sinyal, "Faks al" düğmesine basıldıktan sonra gönderilir veya faks bunu otomatik olarak yapar.
Gönderen tarafta, CED sinyali algılanır ve SIP REINVITE prosedürü gerçekleşir ve SDP mesajında T.38 tipi belirtilir: m = image 39164 udptl t38.

Faksların İnternet üzerinden T.38'de iletilmesi arzu edilir. Faksın ofis içinde veya sabit bir bağlantıya sahip nesneler arasında iletilmesi gerekiyorsa, Inband T.30 faks iletimi kullanılabilir. Bu durumda, bir faks göndermeden önce, ek bozulmalara neden olmamak için yankı iptal prosedürü devre dışı bırakılmalıdır.

David Hanes ve Gonzalo Salgueiro'nun Fax, Modem, and Text for IP Telephony adlı kitabı faks iletimi hakkında çok ayrıntılıdır.

Senkronizasyon Kaynağı (SSRC) Tanımlayıcı

Katkıda Bulunan Kaynak (CSRC) Tanımlayıcıları

Bir konuşma oturumu (SIP / SDP) kurmak için protokolleri ve RTP kanalı üzerinden ses iletme yöntemini bulduk. Geriye önemli bir konu kaldı - ses kalitesi. Bir yandan, ses kalitesi seçilen kodek tarafından belirlenir. Ancak öte yandan, ek DSP prosedürlerine (DSP - dijital sinyal işleme) hala ihtiyaç duyulmaktadır. Bu prosedürler VoIP telefonunun özelliklerini dikkate alır: her zaman yüksek kaliteli bir kulaklık kullanılmaz, İnternette paket düşüşleri olur, bazen paketler düzensiz gelir, ağ bant genişliği de lastik değildir.

Ses kalitesini iyileştirmek için temel prosedürler:

VAD(Ses etkinliği algılayıcı) - ses (aktif ses çerçevesi) veya sessizliği (etkin olmayan ses çerçevesi) içeren çerçeveleri algılama prosedürü. Bu ayırma, ağ üzerindeki yükü önemli ölçüde azaltabilir, çünkü sessizlik hakkındaki bilgilerin iletilmesi çok daha az veri gerektirir (sadece gürültü seviyesini iletmek veya hiçbir şey iletmemek yeterlidir).

Bazı codec bileşenleri halihazırda VAD prosedürleri içerir (GSM, G.729), diğerleri için (G.711, G.722, G.726) bunların uygulanması gerekir.

VAD, gürültü seviyesi bilgilerini iletmek üzere yapılandırılırsa, özel SID paketleri (Silence Insertion Descriptor) 13m RTP CN (Konfor Gürültüsü) formatında iletilir.

SID paketlerinin SIP proxy sunucuları tarafından bırakılabileceğini belirtmekte fayda var, bu nedenle doğrulama için SIP sunucularından geçen RTP trafiğinin iletiminin yapılandırılması tavsiye edilir.

CNG(konfor gürültüsü üretimi) - SID paketlerinden gelen bilgilere dayalı olarak rahat gürültü üretme prosedürü. Böylece, VAD ve CNG birlikte çalışır, ancak CNG'nin özellikle düşük hacimde çalışmasını fark etmek her zaman mümkün olmadığı için CNG prosedürü çok daha az talep görür.

PLC(paket kaybı gizleme) - paket kaybı durumunda bir ses akışını kurtarma prosedürü. %50 paket kaybında bile iyi bir PLC algoritması kabul edilebilir konuşma kalitesine ulaşır. Elbette çarpıtmalar olacak, ancak kelimeler çıkarılabilir.

Paket kaybını (Linux'ta) taklit etmenin en kolay yolu, netem modülü ile iproute paketindeki tc yardımcı programını kullanmaktır. Yalnızca giden trafiği şekillendirir.

%50 paket kaybıyla ağ öykünmesi başlatma örneği:

Tc qdisc change dev eth1 kök netem kaybı %50

Öykünmeyi devre dışı bırak:

Tc qdisc del dev eth1 kökü

titreşim tamponu- alınan paketler arasındaki aralık büyük ölçüde değiştiğinde ve en kötü durumda alınan paketlerin yanlış sıralanmasına yol açan titreşim etkisinden kurtulmak için bir prosedür. Ayrıca bu etki konuşmada kesintilere yol açar. Titreşim etkisini ortadan kaldırmak için, belirli bir aralıkta paketlerin orijinal gönderim sırasını geri yüklemek için yeterli boyutta bir paket arabelleği alıcı tarafta uygulamak gerekir.

Ayrıca tc yardımcı programını kullanarak titreşim etkisini taklit edebilirsiniz (beklenen paket varış anı ile gerçek an arasındaki aralık 500 ms'ye kadar olabilir):

tc qdisc dev eth1 kök netem gecikmesi ekle 500ms yeniden sırala 99%

LEC(Line Echo Canceller) - Uzak bölge kendi sesini duymaya başladığında yerel yankı iptal prosedürü. Özü, alınan sinyali iletilen sinyalden belirli bir katsayı ile çıkarmaktır.

Yankılar birkaç nedenden dolayı ortaya çıkabilir:

düşük kaliteli ses yolu nedeniyle akustik yankı (hoparlörden gelen ses mikrofona girer);
arasındaki empedans uyumsuzluğundan kaynaklanan elektriksel eko telefon seti ve SLIC modülü. Çoğu zaman bu, 4 telli ila 2 telli telefon hattında meydana gelir.

Sebebini bulmak zor değil (akustik veya elektriksel yankı): Yankı üreten abonenin mikrofonu kapatması gerekir. Eko yine de görünüyorsa, elektrikseldir.

VoIP ve DSP prosedürleri hakkında daha fazla bilgi için VoIP Ses ve Faks Sinyali İşleme kitabına bakın. Google Kitaplar'da bir önizleme mevcuttur.

Bu yüzeysel teorik VoIP'ye genel bakış Tamamlandı. İlgileniyorsanız, bir sonraki makalede bir mini PBX'in gerçek bir donanım platformunda pratik uygulamasına bir örnek düşünülebilir.

[!?] Soru ve yorumlarınızı bekliyoruz. Promwad elektronik tasarım merkezinde yazılım mühendisi olan Dmitry Valento makalesinin yazarı tarafından yanıtlanacaktır.

Etiketler:

yeni başlayanlar için
yeni başlayanlar için

Etiket ekle