Tünaydın!

Toplam: izleme sistemi, trafikte mevcut olan tüm RTP video akışlarının iletimini sürekli olarak "izleyen" ve ölçümler yapan, 10 gigabit Ethernet bağlantılarının n'inci sayısına müdahaleci olmayan bir modda bağlanan bir komplekstir. onları daha sonra üsse kaydetmek için belirli bir zaman aralığı. Veritabanından alınan verilere göre, tüm kameralar için düzenli olarak raporlar oluşturulur.

Ve bu kadar zor olan ne?

Bir çözüm bulma sürecinde, birkaç sorun hemen düzeltildi:

• Müdahaleci olmayan bağlantı. İzleme sistemi, bağlantıların çoğunun (RTSP aracılığıyla) zaten kurulmuş olduğu halihazırda çalışan kanallara bağlanır, sunucu ve istemci, değişimin hangi portlarda gerçekleştiğini zaten bilir, ancak bunu önceden bilmiyoruz. Yalnızca RTSP protokolü için iyi bilinen bir bağlantı noktası vardır, ancak UDP akışları keyfi bağlantı noktalarından geçebilir (ayrıca, genellikle çift/tek bağlantı noktası gereksinimini ihlal ettikleri ortaya çıktı, bkz. rfc3550). Bazı IP adreslerinden gelen bu veya bu paketin bir video akışına ait olduğu nasıl belirlenir? Örneğin, BitTorrent protokolü benzer şekilde davranır - bir bağlantı kurma aşamasında, istemci ve sunucu bağlantı noktaları üzerinde anlaşırlar ve ardından tüm UDP trafiği “sadece bir bit akışı” gibi görünür.
• Bağlı bağlantılar, video akışlarından daha fazlasını içerebilir. HTTP, BitTorrent ve SSH ve bugün kullandığımız diğer protokoller olabilir. Bu nedenle, sistemin video akışlarını trafiğin geri kalanından ayırmak için doğru bir şekilde tanımlaması gerekir. Bunu 8 on gigabit bağlantıyla gerçek zamanlı olarak nasıl yapabilirim? Tabii ki, genellikle% 100'e kadar doldurulmazlar, bu nedenle toplam trafik 80 gigabit / s değil, yaklaşık 50-60 olacaktır, ancak bu çok az değil.
• Ölçeklenebilirlik. Halihazırda çok sayıda video akışının olduğu yerde, video gözetimi uzun süredir etkili bir araç olarak kendini kanıtlamış olduğundan, bunlardan daha da fazlası olabilir. Bu, performans için bir marj ve bağlantılar için bir rezerv olması gerektiğini gösterir.

Uygun bir çözüm aranıyor...

Doğal olarak, kendi deneyimlerimizden en iyi şekilde yararlanmaya çalıştık. Karar verildiğinde, FPGA destekli Bercut-MX cihazında (daha basit olarak - MX) ethernet paketlerinin işlenmesine ilişkin bir uygulamamız zaten vardı. Bercut-MX yardımıyla Ethernet paketlerinin başlıklarından analiz için gerekli alanları alabildik. Ne yazık ki, "normal" sunucular kullanarak bu kadar büyük bir trafiği işleme konusunda hiçbir deneyimimiz yoktu, bu yüzden böyle bir çözüme biraz endişeyle baktılar ...

Yöntemi sadece RTP paketlerine uygulamak kaldı ve cebimizde altın anahtar olacak gibi görünüyor, ancak MX yalnızca trafiği işleyebilir, istatistikleri kaydetme ve saklama yeteneğine sahip değildir. FPGA'da bulunan bağlantıları (IP-IP-port-port kombinasyonları) depolamak için yeterli bellek yok, çünkü girişe giren 2x10 gigabit bağlantıda yaklaşık 15 bin video akışı olabilir ve her biri için “ "alınan paketlerin sayısını, kayıp paketlerin sayısını vb. hatırlayın ... Ayrıca, kayıpsız işleme tabi tutularak bu kadar hızlı ve bu miktarda veri üzerinde arama yapmak önemsiz bir görev haline gelir.

Bir çözüm bulmak için "daha derine inmemiz" ve kaliteyi ölçmek ve video akışlarını belirlemek için hangi algoritmaları kullanacağımızı bulmamız gerekiyordu.

Bir RTP paketinin alanları ile ne ölçülebilir?

Açıklamadan, RTP paketindeki kalite ölçümleri açısından aşağıdaki alanlarla ilgilendiğimiz görülebilir:

• sıra numarası - gönderilen her paketle artan 16 bitlik sayaç;
• zaman damgası - zaman damgası, h.264 için örnek boyutu 1/90000 s'dir (yani 90 kHz'lik bir frekansa karşılık gelir);
• işaretleyici bit rfc3550'de, genellikle bu bitin "önemli" olayları belirlemeye yönelik olduğu açıklanır ve aslında kameralar çoğunlukla bir video karesinin başlangıcını ve bu bit ile SPS / PPS bilgisine sahip özel paketleri işaretler.

Sıra numarasının aşağıdaki akış parametrelerini tanımlamanıza izin verdiği oldukça açıktır:

• paket kaybı (çerçeve kaybı);
• paketi yeniden gönderme (yineleme);
• varış sırasını değiştirme (yeniden sıralama);
• dizide büyük bir "boşluk" ile kamerayı yeniden yüklemek.

Zaman damgası şunları ölçmenizi sağlar:

• gecikme varyasyonu (jitter olarak da bilinir). Bu durumda alıcı tarafta 90 kHz'lik bir sayaç çalışmalıdır;
• prensip olarak, paketin geçişindeki gecikme. Ancak bunun için kamera zamanını zaman damgasıyla senkronize etmeniz gerekir ve bu, kameranın gönderen raporları (RTCP SR) iletmesi durumunda mümkündür, bu genellikle doğru değildir, çünkü gerçek hayatta, birçok kamera RTCP SR mesajını görmezden gelir (çalışma şansımız olan kameraların yaklaşık yarısı).

M-bit, kare hızını ölçmenizi sağlar. Doğru, h.264 protokolünün SPS/PPS çerçeveleri bir hataya neden olur, çünkü video kareleri değildir. Ancak, her zaman RTP başlığını takip eden NAL-birim başlığından gelen bilgiler kullanılarak seviyelendirilebilir.

Parametreleri ölçmek için ayrıntılı algoritmalar makalenin kapsamı dışındadır, onu incelemeyeceğim. İlgileniyorsanız, rfc3550'nin bir kayıp hesaplama kodu örneği ve titreşimi hesaplamak için bir formülü vardır. Ana sonuç, bir taşıma akışının temel özelliklerini ölçmek için RTP paketlerinden ve NAL birimlerinden yalnızca birkaç alanın yeterli olmasıdır. Ve bilgilerin geri kalanı ölçümlere dahil değildir ve atılabilir ve atılmalıdır!

RTP akışları nasıl belirlenir?

İstatistikleri tutmak için, RTP başlığından elde edilen bilgiler belirli bir kamera (video akışı) tanımlayıcısına "eklenmelidir". Kamera, aşağıdaki parametrelerle benzersiz bir şekilde tanımlanabilir:

• Kaynak ve Hedef IP Adresleri
• Kaynak ve Hedef Bağlantı Noktaları
• SSRC. Bir IP'den birkaç akışın yayınlanması özellikle önemlidir, yani. çok bağlantı noktalı kodlayıcı durumunda.

İlginç bir şekilde, ilk başta, SSRC'nin rastgele olması gerektiği gerçeğine dayanarak, kamera tanımlamasını yalnızca kaynak IP ve SSRC ile yaptık, ancak pratikte, birçok kameranın SSRC'yi sabit bir değere ayarladığı ortaya çıktı (örneğin, 256). Görünüşe göre, bu kaynak tasarrufu nedeniyle. Sonuç olarak, kamera kimliğine bağlantı noktaları eklemek zorunda kaldık. Bu, benzersizlik sorununu tamamen çözdü.

RTP paketleri diğer trafikten nasıl ayrılır?

Soru şu: Paketi kabul eden Berkut-MX, bunun RTP olduğunu nasıl anlayacak? RTP başlığının IP gibi açık bir tanımlaması yoktur, sağlama toplamı yoktur, bağlantı kurulduğunda dinamik olarak seçilen port numaraları ile UDP üzerinden iletilebilir. Ve bizim durumumuzda, bağlantıların çoğu uzun süredir kurulmuştur ve yeniden kurulum için çok uzun süre bekleyebilirsiniz.

Bu sorunu çözmek için, rfc3550'de (Ek A.1) RTP sürüm bitlerinin kontrol edilmesi önerilir - bu iki bittir ve Yük Tipi (PT) alanı - dinamik bir tür olması durumunda yedi bittir. küçük aralık. Çalıştığımız kamera seti için PT'nin 96 ila 100 aralığına uyduğunu pratikte öğrendik.

Bir faktör daha var - limanın paritesi, ancak uygulamanın gösterdiği gibi, her zaman gözlenmedi, bu yüzden terk edilmesi gerekiyordu.

Böylece Berkut-MX'in davranışı aşağıdaki gibidir:

1. bir paket alıyoruz, alanlara ayırıyoruz;
2. eğer sürüm 2 ise ve payload tipi verilen limitler içindeyse, sunucuya başlıkları göndeririz.

Açıkçası, bu yaklaşımla yanlış pozitifler var, çünkü. sadece RTP paketleri bu kadar basit kriterlerin altına düşemez. Ancak RTP paketini kesinlikle kaçırmamamız ve sunucunun “yanlış” paketleri filtrelemesi bizim için önemlidir.

Yanlış durumları filtrelemek için sunucu, sırayla alınan birkaç paket için video trafiğinin kaynağını kaydeden bir mekanizma kullanır (pakette bir sıra numarası vardır!). Birkaç paket ardışık sayılarla geldiyse, bu bir tesadüf değildir ve bu akışla çalışmaya başlarız. Bu algoritmanın çok güvenilir olduğu kanıtlandı.

Hareketli…

Paketlerde gelen tüm bilgilerin kaliteyi ölçmek ve akışları tanımlamak için gerekli olmadığını fark ederek, RTP paketlerinin alanlarını almak ve izole etmek için tüm yüksek yük ve zaman açısından kritik çalışmaları Berkut-MX'e, yani FPGA. Video akışını "bulur", paketi ayrıştırır, yalnızca gerekli alanları bırakır ve UDP tünelindeki normal bir sunucuya gönderir. Sunucu her kamera için ölçüm alır ve sonuçları veritabanına kaydeder.

Sonuç olarak, sunucu 50-60 Gigabit / s ile değil, maksimum% 5 ile çalışır (bu tam olarak ortalama paket boyutuna gönderilen verilerin oranıdır). Yani, tüm sistemin girişinde 55 Gigabit / s ve sunucuya yalnızca 3 Gigabit / s'den fazla değil!

Sonuç olarak, aşağıdaki mimariye sahibiz:

Ve ilk TOR'u ayarladıktan iki hafta sonra bu konfigürasyonda ilk sonucu aldık!

Sunucunun nihai sonucu nedir?

Peki sunucu bizim mimarimizde ne yapıyor? Görevleri:

• bir UDP soketinde dinleyin ve ondan paketlenmiş başlıkları olan alanları okuyun;
• gelen paketleri ayrıştırın ve oradan kamera tanımlayıcılarıyla birlikte RTP başlık alanlarını çıkarın;
• alınan alanları daha önce alınanlarla ilişkilendirin ve paketlerin kaybolup kaybolmadığını, paketlerin tekrar tekrar gönderilip gönderilmediğini, varış sırasının değişip değişmediğini, paket geçiş gecikmesindeki (jitter) varyasyonun ne olduğunu anlayın;
• ölçülen verileri zamana göre veritabanına kaydedin;
• tabanı analiz edin ve raporlar oluşturun, kritik olaylar hakkında tuzaklar gönderin (yüksek paket kaybı, bazı kameralardan paket kaybı vb.).

Sunucu girişindeki toplam trafiğin yaklaşık 3 Gigabit / s olmasına rağmen, herhangi bir DPDK kullanmasak bile sunucu başa çıkıyor, sadece bir linux soketi üzerinden çalışıyor (tabii ki soket için arabellek boyutunu artırdıktan sonra) . Üstelik performans marjı kaldığı için yeni bağlantılar ve MX'ler bağlamak mümkün olacaktır.

Sunucunun üst kısmı şöyle görünür (bu, yalnızca bir lxc kapsayıcısının üstüdür, raporlar bir diğerinde oluşturulur):

Kalite parametrelerinin hesaplanması ve istatistiklerin muhasebeleştirilmesi için tüm yükün dört sürece eşit olarak dağıtıldığı görülebilir. FPGA'da hash kullanarak böyle bir dağılım elde etmeyi başardık: hash fonksiyonu IP ile hesaplanır ve alınan hash'in düşük bitleri istatistiklerin gideceği UDP portunun sayısını belirler. Buna göre, kendi bağlantı noktasını dinleyen her işlem yaklaşık olarak aynı miktarda trafik alır.

eksiler ve artılar

Çözümün eksikliklerini övünme ve kabul etme zamanı.

Profesyonellerle başlayacağım:

• 10G bağlantıları ile kavşakta kayıp yok. FPGA tüm "darbeyi" aldığından, her paketin analiz edileceğinden emin olabiliriz;
• 55.000 kamerayı (veya daha fazlasını) izlemek için, bir 10G kartına sahip yalnızca bir sunucu gereklidir. Şu anda her biri 2400 MHz'lik 4 çekirdekli 2x Xeon tabanlı sunucular kullanıyoruz. Bir marjla yeter: bilgi toplanmasına paralel olarak raporlar oluşturulur;
• 8 "düzinelerce" (10G bağlantı) izleme yalnızca 2-3 birime sığar: rafta izleme sistemi için her zaman çok fazla alan ve güç yoktur;
• Anahtar aracılığıyla MX'lerden gelen bağlantıları bağlarken, izlemeyi durdurmadan yeni bağlantılar ekleyebilirsiniz, çünkü sunucuya herhangi bir kart takmanıza ve bunun için kapatmanıza gerek yok;
• sunucu verilerle aşırı yüklenmez, yalnızca gerekli olanı alır;
• MX'den gelen başlıklar bir jumbo Ethernet paketinde gelir, bu da işlemcinin kesintilerle boğulmayacağı anlamına gelir (ayrıca, kesinti birleştirmeyi de unutmayız).

Adil olmak gerekirse, dezavantajları dikkate alacağım:

• belirli bir görev için yoğun optimizasyon nedeniyle, yeni alanlar veya protokoller için destek eklenmesi FPGA kodunda değişiklik yapılmasını gerektirir. Bu, işlemcide aynı şeyi yaptığımızdan daha fazla zamana yol açar. Hem geliştirme ve test aşamasında hem de dağıtım sırasında;
• video bilgileri hiç analiz edilmez. Kamera önünde asılı bir buz saçağı çekebilir veya yanlış yöne çevrilebilir. Bu gerçek fark edilmeyecek. Tabii ki, seçilen kameradan video kaydetme özelliğini sağladık, ancak operatör 55.000 kameranın tamamını geçemiyor!
• bir sunucu ve FPGA destekli cihazlar, bir veya iki sunucudan daha pahalıdır;)

Özet

Sonunda hem arayüzlerdeki paketleri ayrıştıran kısmı hem de istatistikleri tutan kısmı kontrol edebileceğimiz bir yazılım ve donanım kompleksimiz oldu. Kameralar RTSP/TCP interleaved moduna geçmeye başladığında, sistemin tüm düğümleri üzerinde tam kontrol bizi kelimenin tam anlamıyla kurtardı. Çünkü bu durumda, RTP başlığı artık pakette sabit bir ofsette bulunmaz: herhangi bir yerde olabilir, hatta iki paketin sınırında bile (ilk yarı bir, ikincisi diğerinde). Buna göre, RTP başlığını ve alanlarını elde etme algoritması temel değişikliklere uğramıştır. 50.000 bağlantının tümü için sunucuda TCP yeniden birleştirmesi yapmak zorunda kaldık - bu nedenle üst kısımdaki oldukça yüksek yük.

Daha önce yüksek yük uygulamaları alanında hiç çalışmamıştık ancak FPGA'daki becerilerimiz sayesinde sorunu çözmeyi başardık ve oldukça iyi çıktı. Hatta bir marj bile vardı - örneğin, 55.000 kameralı bir sisteme 20-30 bin akış daha bağlanabilir.

Linux alt sistemlerinin ayarlanması (kesmelere göre kuyrukların dağıtılması, alma arabelleklerinin artması, çekirdeklerin belirli işlemlere doğrudan atanması vb.) çünkü yazının kapsamı dışında bıraktım. bu konu zaten çok iyi işlenmiştir.

Her şeyden çok uzakta anlattım, bir sürü tırmık toplandı, bu yüzden soru sormaktan çekinmeyin :)

Sonuna kadar okuyan herkese çok teşekkürler!

İnternetin hızlı büyümesi, veri aktarımının hızına ve hacmine yeni talepler getirmektedir. Ve tüm bu talepleri karşılamak için tek başına ağın kapasitesini artırmak yeterli değildir; makul ve etkili trafik yönetimi ve iletim hatlarının sıkışıklığı yöntemlerine ihtiyaç vardır.

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, örneğin sesli ve görüntülü konferans, canlı video, tıbbi uzaktan teşhis, bilgisayar telefonu, dağıtılmış etkileşimli simülasyon, oyunlar, gerçek zamanlı izleme ve diğerlerini içerir.

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

Bu görevin yeni gerçek zamanlı aktarım protokolü ile çözülmesi amaçlanmıştır - RTP(Gerçek Zamanlı Aktarım Protokolü), verilerin belirli sınırlar dahilinde bir veya daha fazla hedefe gecikmeyle teslim edilmesini garanti eder, yani veriler gerçek zamanlı olarak oynatılabilir.

RTP protokolünü oluşturma ilkeleri

RTP, paket teslimi, iletim geçerliliği veya bağlantı güvenilirliği için herhangi bir mekanizmayı 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 adresiyle tanımlanır (bir ağ adresi - IP ve bir çift bağlantı noktası: RTP ve RTCP).

RTP paketleri aşağıdaki alanları içerir: veriyi hangi tarafın oluşturduğunu gösteren gönderen kimliği, verinin alıcı taraf tarafından doğru aralıklarla yeniden oynatılabilmesi için paket üretiminin zaman damgaları, aktarım sırası bilgileri ve verinin doğası hakkında bilgi. video kodlama türü (MPEG, Indeo, vb.) gibi paketin içeriği. 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ğda dolaşırlar ve verileri alındıkça gerçek zamanlı olarak oynatan bir alıcı tarafından alınırlar. Ancak, paketler ağ üzerinden iletilirken 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 tutulur ve ardından sabit bir oranda sağlanır. yazılım Bu çıktıyı üretir. 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 biçimini tanımladığından (ve düzenlediğinden), senkronizasyon kavramı doğrudan bununla ilgilidir ve kısmen RTP çeviri mekanizmasının - karıştırıcının sorumluluğundadır. Bir veya daha fazla kaynaktan RTP paketi akışları aldıktan sonra, karıştırıcı bunları birleştirir ve bir veya daha fazla alıcıya yeni bir RTP paketleri akışı gönderir. Mikser, verileri kolayca birleştirebilir ve örneğin birkaç ses kaynağını birleştirirken biçimini değiştirebilir. farz edelim ki yeni sistem oturuma katılmak istiyor, ancak ağa olan bağlantısı tüm RTP akışlarını desteklemek için yeterli kapasiteye sahip değil, ardından mikser tüm bu akışları alır, bir araya getirir ve sonuncuyu yeni oturum üyesine iletir. 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 kimliğini içerir.

Daha basit bir röle cihazı, 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ı video sinyalini işleyemeyebilir. Çevirmen, videoyu farklı bir format gerektiren daha düşük kaliteli bir formata dönüştürür. yüksek hız veri transferi.

İş kontrol yöntemleri

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

RTCP birkaç işlevi yerine getirir:

1. Tıkanıklık durumunda hizmet kalitesinin ve geri bildirimin sağlanması ve izlenmesi. RTCP paketleri çok noktaya yayın 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ı değerlendirebilir. Gönderenin mesajları, alıcıların veri hızını ve iletim kalitesini değerlendirmesine olanak tanır. Alıcıların mesajları, paket kaybı ve aşırı dalgalanma da dahil olmak üzere yaşadıkları sorunlar hakkında bilgiler içerir. Alıcı geri bildirimi, yayılma hatalarını teşhis etmek için de önemlidir. Ağ yöneticisi, tüm oturum katılımcılarının mesajlarını analiz ederek, sorunun bir katılımcıyla mı ilgili olduğunu 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 sistem için tipik olduğu sonucuna varırsa, kalitedeki düşüş nedeniyle veri sıkıştırma derecesini artırabilir veya videoyu tamamen iletmeyi reddetme - bu, düşük kapasiteli bağlantı üzerinden veri aktarmanıza izin verir.
2. Gönderici kimliği. RTCP paketleri, gönderenin standart bir metin açıklamasını içerir. Veri paketlerinin göndericisi hakkında, rastgele seçilen bir eşitleme kaynağı kimliğinden daha fazla bilgi sağlarlar. Ayrıca, kullanıcının farklı oturumlarla ilgili konuları tanımlamasına yardımcı olurlar.
3. Oturum boyutlandırma ve ölçekleme. Hizmet kalitesini sağlamak ve geri bildirim tıkanıklık kontrolü amacıyla ve ayrıca gönderenin belirlenmesi amacıyla, tüm katılımcılar periyodik olarak RTCP paketleri gönderir. Katılımcı sayısı arttıkça bu paketlerin iletim sıklığı azalır. Az sayıda katılımcı ile maksimum 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 oranını sınırladığı bir algoritmayı açıklar. Amaç, RTCP trafiğini toplam oturum trafiğinin %5'inin altında tutmaktır.

RTP protokolü başlık formatı

RTP, akış odaklı bir protokoldür. RTP paketinin başlığı, gerçek zamanlı iletim ihtiyaçları göz önünde bulundurularak tasarlanmıştır. 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 için ve video ve ses gibi çoklu veri akışlarını senkronize etmek için bir zaman damgası içerir.

Her RTP paketinin temel bir 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:

1. Bu protokol yalnızca iki uç nokta arasında bir bağlantı kurulmasına izin verir ve bu nedenle çok noktaya yayın için uygun değildir.
2. TCP, gerçek zamanlı uygulama artık onları beklemediğinde gelen kayıp bölümlerin yeniden iletilmesini sağlar.
3. TCP, zamanlama bilgilerini segmentlerle ilişkilendirmek için uygun bir mekanizmaya sahip değildir; bu, gerçek zamanlı uygulamalar için ek bir gereksinimdir.

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 kritik bilgi senkronizasyon hakkında.

Her gerçek zamanlı uygulama, gerçek zamanlı iletimi desteklemek için kendi mekanizmalarına sahip olsa da, tek bir protokolün tanımlanmasını oldukça arzu edilir kılan birçok ortak özelliği paylaşırlar.

Yeni gerçek zamanlı aktarım protokolü RTP (Gerçek Zamanlı Aktarım Protokolü), verilerin bir veya daha fazla alıcıya belirtilen sınırlar dahilinde bir gecikmeyle teslim edilmesini garanti eden bu sorunu çözmek için tasarlanmıştır, yani veriler gerçek zamanlı olarak yeniden üretilebilir. .

Şek. 1 sunuldu sabit RTP başlığı paket formatı gibi öğeleri tanımlayan bir dizi alan içeren , seri numarası, kaynaklar, sınırlar ve yük türü. Sabit başlık, veriler hakkında ek bilgiler içeren diğer alanlar tarafından takip edilebilir.

0

2

3

4

8

16

31

Senkronizasyon Kaynağı (SSRC) Tanımlayıcı
Katkıda Bulunan Kaynak (CSRC) Tanımlayıcıları

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

V(2 bit). sürüm alanı. Mevcut sürüm ikincisidir.
R(1 bit). Alanı doldurun. Bu alan, yükün sonunda dolgu oktetlerinin varlığına işaret eder. Doldurma, bir uygulama yük boyutunun örneğin 32 bitin katı olmasını gerektirdiğinde uygulanır. Bu durumda, son sekizli, dolgu sekizlilerinin sayısını gösterir.
X(1 bit). Başlık uzantısı alanı. Bu alan ayarlandığında, ana başlığı, deneysel RTP uzantılarında kullanılan ek bir başlık takip eder.
SS(4 bit). Gönderen sayısı için 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 tipine bağlıdır. İşaret biti tipik olarak veri akışının sınırlarını belirtmek için kullanılır. Video durumunda, çerçevenin sonunu ayarlar. 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ıdan numaralandırmaya başlar, ardından gönderilen her RTP veri paketiyle birer birer artar. 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, ilk yük verisi 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 Kimliği alanı: Bir oturumdaki kaynağı benzersiz şekilde tanımlayan ve ağ adresinden bağımsız, rastgele oluşturulmuş bir sayı. Bu sayı, tek bir kaynaktan gelen verilerin işlenmesinde önemli bir rol oynar.
Katkıda bulunan kaynak (CSRC) Tanımlayıcı(32 bit). Ana akışa "karıştırılmış" kaynak tanımlayıcı alanlarının listesi, örneğin bir karıştırıcı kullanılarak. Karıştırıcı, bu RTP paketinin oluşturulmasına katılan kaynakların SSRC tanımlayıcılarının tam listesini ekler. Bu listeye CSRC denir. Listedeki öğe sayısı: 0'dan 15'e kadar Katılımcı sayısı 15'ten fazlaysa, ilk 15 seçilir.Örnek, RTP paketlerinde tüm katılımcıların konuşmalarının toplandığı, her biri kendileriyle birlikte bir sesli konferanstır. kendi SSRC'si - CSRC listesini oluştururlar. Bu durumda, 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 protokollerini karşılaştırın). RTCP protokolünün çekirdeği RTP olmasına rağmen, işlevlerini uyguladığı birçok ek alan içerir.

Kaynak Rezervasyon Protokolü - LCV

Gecikmelerin çok kritik olmadığı geleneksel verilerin aksine, gecikmeye duyarlı veriler için öncelik sorununu çözmek için, şu anda İnternet Mühendisliği Görev Gücü (IETF) tarafından değerlendirilmekte olan kaynak rezervasyon protokolü - RSVP'ye başvurulur. LCV izin verir uç sistemler gerekli hizmet kalitesini elde etmek için ağ kaynaklarını, özellikle RTP protokolünü kullanan gerçek zamanlı grafikler için kaynakları ayırın. RSVP, öncelikle yönlendiricilerle ilgilidir, ancak uç düğüm uygulamaları, 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 kullanacağını da bilmelidir.

RTP, açıklanan diğer standartlarla birlikte, video ve sesin geleneksel IP ağları üzerinden başarılı bir şekilde iletilmesini mümkün kılar. RTP/RTCP/RSVP, gerçek zamanlı veri ağları için standartlaştırılmış bir çözümdür. Tek dezavantajı sadece IP ağları için olmasıdır. Ancak bu sınırlama geçicidir: ağlar öyle ya da böyle bu yönde gelişecektir. Bu çözüm, gecikmeye duyarlı verilerin İnternet üzerinden iletilmesi sorununu çözmeyi vaat ediyor.

Edebiyat

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

TCP / IP protokol yığınına dayalı olarak hizmet kalitesi için farklı gereksinimlere sahip çeşitli trafik türlerini destekleme gereksinimi artık çok önemlidir. Bu sorun, hizmet kalitesini garanti etmeyen bir ağ üzerinden ses veya video gibi verilerin gerçek zamanlı iletimi için bir IETF standardı olan Gerçek Zamanlı Aktarım Protokolü (RTP) tarafından ele alınmaktadır.

RTP protokolü, verilerin belirtilen değeri aşmayan bir gecikmeyle bir veya daha fazla alıcıya teslim edilmesini garanti eder. Bunu yapmak için, protokol başlığı, ses ve video bilgilerinin başarılı bir şekilde geri yüklenmesi için gerekli zaman damgalarını ve ayrıca bilgi kodlama yöntemine ilişkin verileri içerir.

TCP protokolü, iletilen verilerin doğru sırada teslim edilmesini garanti etmesine rağmen, trafik tek tip değildir, yani datagramların teslimi sırasında öngörülemeyen gecikmeler meydana gelir. RTP protokolü datagramların içeriğinin farkında olduğu ve veri kaybı tespit mekanizmalarına sahip olduğu için gecikmeyi kabul edilebilir bir düzeye indirebilir.

IP protokolü adres şeması

IP protokolünde kullanılan ağlar arası adresleme şeması, RFC 990 ve RFC 997'de açıklanmıştır. Bu ağlardaki adresleme ağlarının adresleme cihazlarından ayrılmasına dayanmaktadır. Bu şema yönlendirmeyi kolaylaştırır. Bu durumda, yönlendirmeyi daha verimli hale getirmek için adreslerin düzenli (ardışık) bir şekilde atanması gerekir.

Ağ üzerinde TCP/IP protokol yığınını kullanırken, uç cihazlar benzersiz adresler alır. Bu tür cihazlar olabilir kişisel bilgisayarlar, medya sunucuları, yönlendiriciler vb. Ancak, yönlendiriciler gibi birden çok fiziksel bağlantı noktasına sahip bazı aygıtların bağlantı noktalarının her birinde benzersiz bir adresi olmalıdır. Adresleme şemasına ve ağdaki bazı cihazların birkaç adresi olabileceği gerçeğine dayanarak, bu adresleme şemasının cihazın kendisini ağda değil, bu cihazın ağa özel bir bağlantısını tanımladığı sonucuna varabiliriz. Bu şema bir dizi rahatsızlığa yol açar. Bunlardan biri, cihazı başka bir ağa taşırken adresini değiştirme ihtiyacıdır. Diğer bir dezavantaj, dağıtılmış bir ağda birden fazla bağlantısı olan bir cihazla çalışmak için, bu bağlantıları tanımlayan tüm adreslerini bilmeniz gerekmesidir.

Dolayısıyla IP ağlarındaki her cihaz için üç seviyeli adreslerden bahsedebiliriz:

q Fiziksel adres cihaz (daha doğrusu - belirli bir arayüz). Ethernet ağlarındaki cihazlar için bu MAC adresidir ağ kartı veya yönlendirici bağlantı noktası. Bu adresler donanım üreticileri tarafından atanır. Fiziksel adresin altı baytı vardır: üstteki üç bayt üreticinin tanımlayıcısıdır, alttaki üç bayt üretici tarafından atanır;

q Dört bayttan oluşan bir IP adresi. Bu adres için kullanılır ağ katmanı OSI referans modeli;

q Karakter tanımlayıcı - isim. Bu tanımlayıcı, yönetici tarafından keyfi olarak atanabilir.

IP protokolü Eylül 1981'de standardize edildiğinde, spesifikasyonu bir ağa bağlı her cihazın benzersiz bir 32-bit adresine sahip olmasını gerektiriyordu. Bu adres iki bölüme ayrılmıştır. Adresin ilk kısmı, cihazın bulunduğu ağı tanımlar. İkinci kısım, cihazın kendisini ağ içinde benzersiz bir şekilde tanımlar. Bu şema, iki seviyeli bir adres hiyerarşisine yol açar (Şekil 6.23).

Artık adresteki ağ numarası alanı çağrılır. ağ öneki,çünkü ağı tanımlar. Ağdaki tüm iş istasyonları aynı ağ önekini paylaşır. Aynı zamanda, sahip olmaları gerekir benzersiz sayılar cihazlar. Farklı ağlarda bulunan iki iş istasyonu farklı ağ öneklerine sahip olmalıdır, ancak yine de aynı cihaz numarasına sahip olabilirler.

Adreslemede esneklik için bilgisayar ağları Protokol tasarımcıları, IP adres alanının A, B ve C olmak üzere üç farklı sınıfa bölünmesi gerektiğini belirlediler. Sınıfı bildiğinizde, ağ öneki ile cihaz numarası arasındaki sınırın 32 bitlik bir adreste nerede olduğunu bilirsiniz. . Şek. Şekil 6.24, bu temel sınıfların adres biçimlerini göstermektedir.

Sınıfları kullanmanın başlıca avantajlarından biri, ağ öneki ile cihaz numarası arasındaki sınırın nerede olduğunu adresin sınıfından belirleyebilmenizdir. Örneğin, adresin en anlamlı iki biti 10 ise, ayrılma noktası 15 ve 16 bitleri arasındadır.

Bu yöntemin dezavantajı, bağlanırken ağ adresini değiştirme ihtiyacıdır. ek cihazlar. örneğin, eğer toplam sayısı C sınıfı ağdaki cihaz sayısı 255'i aşarsa, adreslerini B sınıfı adreslerle değiştirmek gerekecektir.Ağ adreslerini değiştirmek, yöneticinin ağda hata ayıklamak için ek çaba göstermesini gerektirir. Ağ yöneticileri yapamaz yumuşak bir geçiş sınıflar açıkça ayrıldığından yeni bir adres sınıfına. Tüm bir ağ adresi grubunun kullanımını yasaklamanız, bu gruptaki cihazların tüm adreslerini aynı anda değiştirmeniz ve ancak o zaman ağ üzerinde tekrar kullanılmasına izin vermeniz gerekir. Ek olarak, adres sınıflarının tanıtılması, teorik olarak olası bireysel adres sayısını önemli ölçüde azaltır. AT şimdiki versiyonu IP protokolü (sürüm 4), protokol adresi belirtmek için 32 bit kullanımını sağladığından, toplam adres sayısı 2 32 (4 294 967 296) olabilir. Doğal olarak, bazı bitlerin hizmet amacıyla kullanılması, mevcut bireysel adreslerin sayısını azaltır.

A Sınıfı büyük ağlar içindir. Her A sınıfı adresin, en anlamlı bitin 1'e ayarlandığı ve sonraki yedi bitin ağ numarası için kullanıldığı 8 bitlik bir ağ öneki vardır. Kalan 24 bit cihaz numarası için kullanılır. AT şu an tüm A sınıfı adresler zaten tahsis edilmiştir. A sınıfı ağlar ayrıca "/8" olarak da adlandırılır çünkü A sınıfı adreslerin 8 bitlik bir ağ öneki vardır.

Maksimum A sınıfı ağ sayısı 126'dır (2 7 -2 - yalnızca sıfırlar ve birlerden oluşan iki adres çıkarılır). Bu sınıftaki her ağ, 16.777.214 (2 24 -2) adede kadar cihazı destekler. A sınıfı bir adres bloğu maksimum 231 (2 147483648) bireysel adresi tutabildiğinden ve IP sürüm 4 yalnızca maksimum 232 (4294967296) adresi destekleyebildiğinden, A sınıfı toplam IP adres alanının %50'sini kaplar.

B Sınıfı orta ölçekli ağlar için tasarlanmıştır. Her sınıf B adresi, en önemli iki bitin 10 olduğu ve sonraki 14 bitin ağ numarası için kullanıldığı 16 bitlik bir ağ önekine sahiptir. Cihaz numarası için 16 bit ayrılmıştır. B sınıfı ağlar ayrıca "/16" olarak da adlandırılır çünkü B sınıfı adreslerin 16 bitlik bir ağ öneki vardır.

B sınıfı ağların maksimum sayısı 16.382'dir (2 14 -2). Bu sınıftaki her ağ 65.534 adede kadar (2 16 -2) cihazı destekler. B sınıfı bir adres bloğunun tamamı maksimum 230 (1.073.741.824) ayrı adres içerebildiğinden, toplam IP adres alanının %25'ini kaplar.

C sınıfı adresler, az sayıda cihaza sahip ağlarda kullanılır. Her C sınıfı ağ, en önemli üç bitin 110 olduğu ve sonraki 21 bitin ağ numarası için kullanıldığı 24 bitlik bir ağ önekine sahiptir. Kalan 8 bit, cihaz numaraları için ayrılmıştır. C sınıfı ağlar ayrıca "/24" olarak da adlandırılır çünkü C sınıfı adreslerin 24 bitlik bir ağ öneki vardır.

Maksimum C Sınıfı ağ sayısı 2.097.152'dir (221). Bu sınıftaki her ağ 254 (2 8 -2) cihaza kadar destekler. C Sınıfı, toplam IP adres alanının %12,5'ini kaplar.

Masada. 6.9, ağ sınıfları analizimizi özetler.

Tablo 6.9. Ağ sınıfları

Bu üç adres sınıfına ek olarak iki sınıf daha vardır. D sınıfında en önemli dört bit 1110'dur. Bu sınıf çok noktaya yayın için kullanılır. E sınıfında, üstteki dört bit 1111'dir. Deney için ayrılmıştır.

Teknik literatürde, uygulama programlarında vb. adreslerin okunmasını kolaylaştırmak için IP adresleri dört olarak gösterilir. ondalık sayılar noktalarla ayrılmış. Bu sayıların her biri, IP adresinin bir sekizlisine (8 bit) karşılık gelir. Bu biçim, noktalı ondalık gösterim (Ondalık Nokta Gösterimi) veya noktalı ondalık gösterim olarak adlandırılır (Şekil 6.25).

Masada. 6.10, üç adres sınıfı için ondalık değer aralıklarını listeler. Masada. 6.10 XXX girişi, isteğe bağlı bir alan anlamına gelir.

Tablo 6.10. Adres değeri aralıkları

Bazı IP adresleri ağdaki cihazlara atanamaz (Tablo 6.11).

Bu tabloda gösterildiği gibi, ayrılmış IP adreslerinde, sıfıra ayarlanan tüm bitler aşağıdakilerden birine karşılık gelir: bu cihaz, veya bu ağ ve tüm bitleri 1'e ayarlanmış IP adresleri bilgi yayınında kullanılır. Tüm IP ağına bir bütün olarak atıfta bulunmak için, tüm bitleri "0" olarak ayarlanmış bir cihaz numarasına sahip bir adres kullanılır. A Sınıfı ağ adresi 127.0.0.0 geri döngü için ayrılmıştır ve aynı makinedeki işlemler arasındaki iletişimi test etmek için sunulmuştur. Bir uygulama bir geri döngü adresi kullandığında, TCP/IP protokol yığını bu verileri ağa hiçbir şey göndermeden uygulamaya döndürür. Ayrıca bu adres, aynı makine içinde ayrı işlemlerin etkileşimi için kullanılabilir. Bu nedenle IP ağlarında cihazlara 127 ile başlayan IP adresleri atanması yasaktır.

Belirli bir iş istasyonuna yönlendirilmiş veri iletimine ek olarak, mevcut veya belirtilen ağdaki tüm istasyonların bilgi aldığı yayın iletimi aktif olarak kullanılır. IP protokolünde iki tür yayın vardır: yönlendirilmiş ve sınırlı.

Yönlendirilmiş yayın, uzak ağdaki bir cihazın aynı ağdaki tüm cihazlara bir datagram göndermesine izin verir. mevcut ağ. İletilmiş bir yayın adresine sahip bir datagram yönlendiricilerden geçebilir, ancak tüm cihazlara değil, yalnızca belirtilen ağdaki tüm cihazlara iletilecektir. Yönlendirilmiş bir yayında, hedef adres, tüm bitleri 0 veya 1 olan belirli bir ağ numarası ve bir cihaz numarasından oluşur. Örneğin, 185.100.255.255 ve 185.100.0.0 adresleri, B sınıfı için yönlendirilmiş yayın adresleri olarak değerlendirilir. ağ 185.100.xxx.xxx Adresleme açısından, yönlü yayının ana dezavantajı, hedef ağ numarası bilgisinin gerekli olmasıdır.

Sınırlı yayın olarak adlandırılan ikinci yayın biçimi, geçerli ağ (gönderen cihazın bulunduğu ağ) içinde yayın yapar. Sınırlı bir yayın adresine sahip bir datagram asla bir yönlendiriciden geçmez. Sınırlı yayında, ağ numarası ve cihaz numarası bitlerinin tümü sıfır veya birdir. Böylece, hedef adresi 255.255.255.255 veya 0.0.0.0 olan bir datagram ağdaki tüm cihazlara teslim edilecektir. Şek. Şekil 6.26, yönlendiriciler tarafından bağlanan ağları göstermektedir. Masada. Şekil 6.12, iş istasyonu A tarafından gönderilen yayın verikatarlarının alıcılarını listeler.

IP protokolü üç adresleme yöntemini destekler: tekli (tekli yayın), yayın (yayın) ve grup (çoklu yayın).

Tablo 6.12. Yayın Datagram Alıcıları

Tek adreslemede datagramlar belirli bir tek cihaza gönderilir. Bu yaklaşımın uygulanması zor değildir, ancak eğer çalışma Grubu birçok istasyon içeriyorsa, aynı datagram birçok kez iletileceğinden verim yeterli olmayabilir.

Yayın adresleme ile uygulamalar, ağdaki tüm cihazlara teslim edilen tek bir datagram gönderir. Bu yaklaşımın uygulanması daha da basittir, ancak bu durumda yayın trafiği aşağıdakilerle sınırlı değilse: yerel ağ(ve örneğin, yönlendiriciler kullanılarak başka bir ağ iletilir), bu durumda küresel ağın önemli bir bant genişliğine sahip olması gerekir. Bilgi yalnızca küçük bir cihaz grubuna yönelikse, bu yaklaşım mantıksız görünüyor.

Çok noktaya yayında, datagramlar belirli bir cihaz grubuna teslim edilir. Aynı zamanda (dağıtılmış ağlarda çalışırken çok önemlidir), aşırı trafik oluşturulmaz. Çok noktaya yayın ve tek adresli datagramlar adres bakımından farklılık gösterir. Çok noktaya yayınlı bir IP datagramının başlığında, A, B, C sınıflarının IP adresleri yerine, bir D sınıfı adresi, yani bir grup adresi vardır.

Bazı alıcı cihazlara veya başka bir deyişle bir gruba bir grup adresi atanır. Gönderici, bu çok noktaya yayın adresini IP datagramının başlığına yazar. Datagram grubun tüm üyelerine iletilecektir. D sınıfı adresin ilk dört biti 1110'dur. Adresin geri kalanı (28 bit) grup tanımlayıcısı tarafından işgal edilir (Şekil 6.27).

Noktalı ondalık biçimde, grup adresleri 224.0.0.0 ile 239.255.255.255 arasında değişir. Masada. Şekil 6.13, D sınıfı adres tahsis şemasını göstermektedir.

Tablo 6.13. D Sınıfı adres tahsisi

Tablodan da anlaşılacağı gibi. 6.13, ilk 256 adres ayrılmıştır. Özellikle bu aralık, yönlendirme protokolleri ve diğer düşük seviyeli protokoller için ayrılmıştır. Masada. 6.14, bazı ayrılmış D sınıfı IP adreslerini içerir.

Bu aralığın üstünde büyük grupİnternette çalışan uygulamalar için ayrılan adresler. En üstteki adres aralığı (yaklaşık 16 milyon adres), LAN'larda idari amaçlar içindir. D Sınıfı grup adresleri, IANA adlı özel bir kuruluş tarafından merkezi olarak yönetilir ve kaydedilir.

Çok noktaya yayın, OSI modelinin iki seviyesinde uygulanabilir - kanal (Veri Bağlantı Katmanı) ve ağ (Ağ Katmanı). Ethernet ve FDDI gibi bağlantı katmanı iletim protokolleri, tek, yayın ve çok noktaya yayın adreslemeyi destekleyebilir. Bağlantı katmanı çok noktaya yayın, özellikle NIC'deki donanımda destekleniyorsa etkilidir.

IANA çok noktaya yayınını desteklemek için, 01-00-5E'den başlayarak (onaltılık gösterimde) bir çok noktaya yayın Ethernet adresleri bloğu tahsis edilmiştir. Bir çok noktaya yayın IP adresi, bu bloktaki bir adrese çevrilebilir. Çevirinin ilkesi oldukça basittir: IP grup tanımlayıcısının alt 23 biti, Ethernet adresinin alt 23 bitine kopyalanır. IP grup kimliğinin sonraki 5 biti yok sayıldığından, bu şemanın aynı Ethernet adresiyle 32'ye kadar farklı IP grubunu ilişkilendirdiğini unutmayın.

Tablo 6.14. Ayrılmış D sınıfı adresler

Adres	Amaç
224.0.0.1	Alt ağdaki tüm cihazlar
224.0.0.2	Alt ağdaki tüm yönlendiriciler
224.0.0.4	Tüm DVMRP Yönlendiriciler
224.0.0.5	Tüm MOSPF Yönlendiriciler
224.0.0.9	RIP IP Sürüm II
224.0.1.7	sesli haber
224.0.1.11	IEFT ses
224.0.1.12	IEFT videosu

Gönderici ve alıcı aynı fiziksel ağa aitse, bağlantı katmanında çok noktaya yayın çerçevelerini gönderme ve alma işlemi oldukça basittir. Gönderici, alıcı grubunun IP adresini belirtir ve NIC, bu adresi ilgili grup Ethernet adresine çevirir ve çerçeveyi gönderir.

Gönderici ve alıcı, yönlendiriciler tarafından bağlı farklı alt ağlardaysa, datagram teslimi zordur. Bu durumda, yönlendiriciler çok noktaya yayın yönlendirme protokollerinden birini (DVMRP, MOSPF, PIM - aşağıya bakın) desteklemelidir. Bu protokollere göre, yönlendirici bir teslimat ağacı oluşturacak ve çok noktaya yayın trafiğini doğru bir şekilde iletecektir. Ayrıca, her yönlendirici, doğrudan bağlı alt ağlarda grup üyelerinin varlığını belirlemek için Grup Yönetim Protokolü'nü (IGMP) desteklemelidir (Şekil 6.28).

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, bu kılavuzun yardımcı olacağını umuyorum. Ek telefon hizmetleri türlerini yapılandırma sorunlarının (çağrı aktarımı, sesli posta, konferans aramaları vb.) burada dikkate alınmaz.

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

1. Telefonun temel kavramları: cihaz türleri, bağlantı şemaları
2. SIP/SDP/RTP protokolleri paketi: nasıl çalışır
3. Basılan düğmeler hakkındaki bilgiler nasıl iletilir?
4. Ses ve faks iletimi nasıl çalışır?
5. IP telefonda dijital sinyal işleme ve ses kalitesi güvencesi

1. Telefonun temel kavramları

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ı (PBX) tarafında, FXS (Yabancı Değişim Abonesi) bağlantı noktasına sahip bir telefon modülü kurulur. Evde veya ofiste FXO (Döviz Bürosu) portu ve çevirici modülü olan bir telefon veya faks makinesi kurulur.

İle dış görünüş FXS ve FXO bağlantı noktaları farklı değildir, bunlar normal 6 pinli RJ11 konektörleridir. Ancak bir voltmetre kullanarak bunları ayırt etmek çok kolaydır - FXS bağlantı noktasında her zaman bir miktar voltaj olacaktır: Ahize 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.

Bir telefon hattı üzerinden veri aktarmak için, sağlayıcı tarafında 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.

Kablosuz DECT telefonlar (Dijital Avrupa Kablosuz Telekomünikasyon) artık oldukça popüler. Cihaz açısından, sıradan telefonlara benzerler: ayrıca bir FXO portu ve bir çevirici modülüne sahiptirler, ancak bir modülleri de vardır. kablosuz iletişim 1.9 GHz frekansında istasyonlar ve ahizeler.

Aboneler PSTN ağına (Genel Anahtarlamalı Telefon Ağı) bağlanır - telefon ağı genel kullanım, PSTN, PSTN'dir. PSTN ağı kullanılarak organize edilebilir farklı teknolojiler: ISDN, optik, POTS, Ethernet. Normal bir analog/bakır hat kullanıldığında özel bir PSTN durumu - POTS (Plain Old Telephone Service) - basit bir eski telefon sistemi.

İnternetin gelişmesiyle telefon iletişimi yeni bir seviyeye taşındı. Sabit telefonlar, özellikle resmi 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 sınırları ile sınırlıdır (dolaşım pahalıdır). Ancak IP telefonlar için de 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ı bir mimari ve telefon dinlemenin hangi yetkililer tarafından bilindiği. Birincisinden dolayı, kendi telefon mikro ağınızı oluşturmanız mümkün değildir. Ve ikincisi nedeniyle - özellikle kişisel ve ticari konuşmalarda, gözetlenmeniz çok 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. SIP protokolünde H.323'e kıyasla birkaç yazılım telefonu daha vardır ve bu, göreceli basitliği ve esnekliği ile açıklanabilir. Ancak bazen bu esneklik, çarka büyük bir sopa sokabilir. Hem SIP hem de H.323 protokolleri, medya verilerini aktarmak için RTP protokolünü kullanır.

Düşünmek temel prensiplerİki abonenin bağlantısının nasıl gerçekleştiğini anlamak için SIP protokolü.

2. SIP/SDP/RTP protokolleri paketinin açıklaması

SIP (Oturum Başlatma Protokolü) - bir oturum (sadece bir telefon değil) oluşturmak için bir protokol, UDP üzerinden bir metin protokolüdü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 adresleri (IP ve bağlantı noktası) konusunda anlaşmaya yönelik bir protokoldür. Aynı zamanda bir metin protokolüdür. SDP parametreleri, SIP paketlerinin gövdesinde gönderilir.

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 SIP yönteminin yürütülmesinin sonucunu gösteren bir alan.
• başlıklar: Ek BilgilerÖZELLİK: DEĞER çiftlerini içeren dizeler olarak biçimlendirilmiş Başlangıç ​​Satırına.
• Gövde: ikili veya metin verileri. Genellikle SDP parametreleri veya mesajları göndermek için kullanılır.

Ortak bir çağrı kurulum prosedürü için iki SIP paketi örneği aşağıda verilmiştir:

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

Ana alanlar çerçevelenmiştir:

• Method/Request-URI, SIP yöntemini ve URI'yi içerir. Örnekte oturum kurulur - DAVET yöntemi, abone çağrılır [e-posta korumalı]
• Durum Kodu - önceki SIP komutu için yanıt kodu. AT bu örnek 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ın göndereni ve alıcısının adını ve adresini görüntüleyin. 200 OK mesajı için bu alan DAVET mesajından kopyalanır.
• Cseq, komutun sıra numarasını ve verilen mesajın atıfta bulunduğu yöntemin adını içerir. 200 OK mesajı için bu alan DAVET mesajından kopyalanır.
• İçerik Türü - Gövde bloğunda iletilen veri türü, bu durumda SDP verileri.
• 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, bunlar 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 alanlar şunları içerir:

• Ö- Köken, oturum düzenleyici adı ve oturum kimliği.
• İle birlikte- Bağlantı Bilgileri, alan daha önce açıklanmıştır.
• m- Medya Açıklaması, alan daha önce açıklanmıştır.
• a- medya öznitelikleri, iletilen verilerin biçimini belirtin. Örneğin, ses alma veya iletim (sendrecv) yönünü belirtirler, kodekler için örnekleme oranını ve bağlama numarasını (rtpmap) belirtirler.

RTP paketleri, belirli bir biçimde kodlanmış ses/video verilerini içerir. Bu biçim PT (yük tipi) alanında belirtilir. Bu alanın değerinin belirli bir biçime nasıl karşılık geldiğine dair bir tablo https://wikipedia org wiki RTP ses video profilinde verilmiştir.

Ayrıca, RTP paketleri benzersiz bir SSRC tanımlayıcısı (RTP akışının kaynağını tanımlar) ve bir zaman damgası (ses veya videoyu eşit şekilde oynatmak için kullanılan zaman damgası) içerir.

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

Bir SIP telefonu çalışmaya başlar başlamaz yaptığı ilk şey kendini şuraya kaydettirmektir. uzak sunucu(SIP Registar), kendisine bir SIP REGISTER mesajı gönderir.

Bir abone aranırken, gövdesi ses / video aktarım parametrelerini (hangi codec bileşenlerinin desteklendiği, sesin hangi IP ve bağlantı noktasına gönderileceği vb.) içeren bir SDP mesajını içeren bir SIP INVITE mesajı gönderilir.

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

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 müzakere 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ğer.

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

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

Bazen, oturum kurulduktan sonra, bir arama sırasında ek hizmetlere (VAS) erişim 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ırayla açılıp kapanması nedeniyle gerçekleşir.
• Tonlu - DTMF kodlarıyla arama (Çift Tonlu Çoklu Frekans) - telefonun her düğmesinin kendi iki sinüsoidal sinyal (ton) kombinasyonu vardır. Goertzel algoritmasını çalıştırarak, basılan düğmeyi belirlemek oldukça kolaydır.

Bir konuşma 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 (her biri 100 ms'lik 10 darbe: 60 ms - hat sonu, 40 ms - hat kapatma) 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, geleneksel telefonda, VAS'a erişim için yalnızca ton modu kullanılır.

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

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

Ses verileri (Inband) içindeki DTMF iletiminin birkaç dezavantajı vardır - bunlar, tonları oluştururken/gömerken ve bunları algılarken ek kaynaklar, DTMF kodlarını bozabilen bazı kodeklerin sınırlamaları ve zayıf iletim güvenilirliğidir (paketlerin bir kısmı kaybolursa, o zaman 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 RTP'yi doğrudan aboneler arasında aktarma yeteneğine sahipse (örneğin, yıldız işaretiyle canreinvite=yes), sunucu RFC2833 paketlerini fark etmeyecektir. sonucu haline geldikleri kullanılamayan hizmetler DVO. SIP paketleri her zaman SIP proxy sunucuları aracılığıyla iletilir, bu nedenle VAS her zaman çalışacaktır.

4. Ses ve faks iletimi

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

Ses iletimi için farklı bit hızı / kalite / karmaşıklık oranlarına sahip birçok farklı kodlayıcı vardır, açık ve kapalı olanlar vardır. Herhangi bir yazılım telefonunun G.711 alaw/ulaw kodeklerini desteklemesi gerekir, bunların uygulanması çok basittir, ses kalitesi iyidir, ancak 64 kbps bant genişliği gerektirirler. Örneğin, G.729 codec bileşeni yalnızca 8 kbps gerektirir, ancak CPU yoğundur ve ücretsiz değildir.

Faks iletimi için genellikle G.711 codec bileşeni veya T.38 protokolü kullanılır. G.711 codec bileşenini kullanarak faks gönderme, faks normal bir telefon hattı üzerinden gönderilmiş gibi, ancak aynı zamanda T.30 protokolünü kullanarak bir faks göndermeye karşılık gelir. analog sinyal hattan hukuk/ulaw kanununa göre sayısallaştırılır. Buna Inband T.30 fakslama da denir.

T.30 protokolünü kullanan fakslar kendi parametrelerini müzakere eder: iletim hızı, datagram boyutu, hata düzeltme türü. 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. Böylece ham veriler değil, tanınan faks kontrol komutları iletilir.

T.38 komutu, UDP tabanlı bir protokol olan ve yalnızca T.38 için kullanılan UDPTL protokolü kullanılarak iletilir. TCP ve RTP protokolleri, T.38 komutlarını iletmek için de kullanılabilir, ancak çok daha az sıklıkla kullanılırlar.

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:

1. Herhangi bir kodlayıcı kullanılarak normal bir ses bağlantısı kurulur.
2. Gönderen faks makinesine 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.
3. Alıcı tarafta, bir T.30 sinyali CED (Aranan Terminal Tanımlaması) oluşturulur - 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.
4. Gönderen tarafta CED sinyali algılanır ve SIP REINVITE prosedürü gerçekleşir ve T.38 tipi SDP mesajında ​​belirtilir: m=image 39164 udptl t38.

İnternet üzerinden tercihen T.38'de faks gönderme. Faksın ofis içinde veya sabit bir bağlantısı olan 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ü kapatılmalıdır.

David Hanes ve Gonzalo Salgueiro'nun "Fax, Modem, and Text for IP Telephony" kitabında faks ile ilgili çok detaylı bilgiler yazılıdır.

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

Bir konuşma oturumu (SIP / SDP) kurmak için protokolleri ve bir RTP kanalı üzerinden ses iletme yöntemini ele aldık. Önemli bir soru vardı - 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, verim ağlar da kauçuk değildir.

Ses kalitesini iyileştiren 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 belirleme prosedürü. Bu ayrım ağ yükünü önemli ölçüde azaltabilir, çünkü sessizlikle ilgili bilgilerin iletimi çok daha az veri gerektirir (gürültü seviyesini iletmek veya hiç bir şey iletmek yeterlidir).

Bazı codec bileşenleri zaten VAD prosedürlerini (GSM, G.729) içerirken, diğerlerinin (G.711, G.722, G.726) bunları uygulaması gerekir.

VAD, gürültü seviyesi hakkında bilgi iletmek üzere yapılandırılırsa, özel SID paketleri (Sessizlik Ekleme Tanımlayıcısı) 13. CN (Konfor Gürültüsü) RTP 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 iletimini yapılandırmanız önerilir.

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

PLC(paket kaybı gizleme) - paket kaybı durumunda ses akışını geri yükleme prosedürü. %50 paket kaybında bile iyi bir PLC algoritması kabul edilebilir konuşma kalitesine ulaşabilir. Elbette çarpıtmalar olacak, ancak kelimeleri anlayabilirsiniz.

Paket kaybını (Linux'ta) taklit etmenin en kolay yolu, netem modülü ile iproute paketindeki tc yardımcı programını kullanmaktır. Sadece giden trafiğin şekillendirilmesini gerçekleştirir.

%50 paket kaybıyla çalışan ağ öykünmesine bir örnek:

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ığın çok değiştiği ve en kötü durumda, alınan paketlerin yanlış sıralanmasına yol açan titreşim etkisinden kurtulma prosedürü. Ayrıca bu etki konuşma kesintilerine yol açar. Titreşim etkisini ortadan kaldırmak için, alıcı tarafta belirli bir aralıkta orijinal gönderen paket sırasını geri yüklemeye yetecek boyutta bir paket arabelleği 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 abone kendi sesini duymaya başladığında yerel yankıyı ortadan kaldırmak için bir 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 ve SLIC modülü. Çoğu durumda bu, 4 kabloludan 2 kablolu telefon hattına dönüştürme devrelerinde meydana gelir.

Sebebini (akustik veya elektriksel yankı) bulmak zor değildir: Yankısının oluşturulduğu abonenin mikrofonu kapatması gerekir. Eko hala devam ediyorsa, o zaman elektrikseldir.

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

Bu, VoIP'ye yüzeysel bir teorik genel bakışı tamamlar. İ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