Добър ден!

Общо: системата за мониторинг е комплекс, който е свързан в ненатрапчив режим към n-тия брой 10-гигабитови Ethernet връзки, който непрекъснато „наблюдава“ предаването на всички RTP видео потоци, присъстващи в трафика, и прави измервания при определен интервал от време, за да ги запишете по-късно в базата. Според данните от базата данни, редовно се изграждат отчети за всички камери.

И кое е толкова трудното?

В процеса на намиране на решение веднага бяха отстранени няколко проблема:

• Ненатрапчива връзка. Системата за мониторинг се свързва към вече работещи канали, в които повечето от връзките (през RTSP) вече са установени, сървърът и клиентът вече знаят на кои портове се извършва обменът, но ние не знаем това предварително. Има добре известен порт само за протокола RTSP, но UDP потоците могат да преминават през произволни портове (освен това се оказа, че те често нарушават изискването за четни/нечетни портове, вижте rfc3550). Как да определите, че този или онзи пакет от някакъв IP адрес принадлежи към видео поток? Например протоколът BitTorrent се държи по подобен начин - на етапа на установяване на връзка клиентът и сървърът се договарят за портове и тогава целият UDP трафик изглежда като „просто битов поток“.
• Свързаните връзки могат да съдържат повече от просто видео потоци. Може да има и HTTP, и BitTorrent, и SSH, и всякакви други протоколи, които използваме днес. Следователно системата трябва да идентифицира правилно видео потоците, за да ги отдели от останалия трафик. Как да направите това в реално време с 8 десет гигабитови връзки? Разбира се, те обикновено не се запълват на 100%, така че общият трафик няма да бъде 80 гигабита / сек, а около 50-60, но това не е толкова малко.
• Мащабируемост. Там, където вече има много видео потоци, може да има още повече, тъй като видеонаблюдението отдавна се е доказало като ефективен инструмент. Това предполага, че трябва да има марж за производителност и резерв за връзки.

Търся подходящо решение...

Естествено, ние се опитахме да се възползваме максимално от собствения си опит. По времето, когато беше взето решението, вече имахме реализация на обработка на Ethernet пакети на FPGA захранвано устройство Bercut-MX (по-просто - MX). С помощта на Bercut-MX успяхме да получим необходимите полета за анализ от заглавките на Ethernet пакетите. За съжаление, нямахме опит в обработката на такъв обем трафик с помощта на „обикновени“ сървъри, така че те погледнаха на такова решение с известно опасение ...

Изглежда, че остава само да приложим метода към RTP пакети и ще имаме златния ключ в джоба си, но MX може да обработва само трафик, няма възможност да записва и съхранява статистика. В FPGA няма достатъчно памет за съхраняване на намерените връзки (комбинации IP-IP-порт-порт), тъй като в 2x10-гигабитова връзка, влизаща на входа, може да има около 15 хиляди видеопотока и за всеки трябва да “ запомни” броя на получените пакети, броя на изгубените пакети и така нататък... Освен това търсенето с такава скорост и такова количество данни, подлежащи на обработка без загуби, се превръща в нетривиална задача.

За да намерим решение, трябваше да „копаем по-дълбоко“ и да разберем какви алгоритми ще използваме за измерване на качеството и идентифициране на видео потоци.

Какво може да се измери чрез полетата на RTP пакет?

От описанието може да се види, че от гледна точка на качествените измервания в RTP пакета, ние се интересуваме от следните полета:

• пореден номер - 16-битов брояч, който нараства с всеки изпратен пакет;
• timestamp - времева марка, за h.264 размерът на извадката е 1/90000 s (т.е. съответства на честота от 90 kHz);
• Бит за маркер В rfc3550 обикновено се описва, че този бит е предназначен да обозначава „значими“ събития и всъщност камерите най-често маркират началото на видеокадър и специализирани пакети с SPS / PPS информация с този бит.

Съвсем очевидно е, че поредният номер ви позволява да дефинирате следните параметри на потока:

• загуба на пакети (загуба на рамка);
• повторно изпращане на пакета (дубликат);
• промяна на реда на пристигане (пренареждане);
• презареждане на камерата, с голям "пропуск" в последователността.

Timestamp ви позволява да измервате:

• вариация на забавянето (наричана още трептене). В този случай 90 kHz брояч трябва да работи на приемащата страна;
• по принцип забавянето на преминаването на пакета. Но за това трябва да синхронизирате времето на камерата с времевия печат и това е възможно, ако камерата предава доклади на изпращача (RTCP SR), което по принцип не е вярно, т.к. в реалния живот много камери игнорират съобщението RTCP SR (около половината от камерите, с които имахме възможност да работим).

Е, M-bit ви позволява да измервате честотата на кадрите. Вярно е, че SPS/PPS кадрите на протокола h.264 въвеждат грешка, защото не са видео рамки. Но може да бъде изравнено чрез използване на информация от заглавката на NAL-единицата, която винаги следва RTP заглавката.

Подробните алгоритми за измерване на параметрите са извън обхвата на статията, няма да се задълбочавам в нея. Ако се интересувате, rfc3550 има пример за код за изчисляване на загубите и формула за изчисляване на трептене. Основният извод е, че само няколко полета от RTP пакети и NAL единици са достатъчни за измерване на основните характеристики на транспортния поток. А останалата информация не участва в измерванията и може и трябва да се изхвърли!

Как да идентифицирам RTP потоци?

За да се поддържа статистика, информацията, получена от RTP хедъра, трябва да бъде „прикрепена“ към определен идентификатор на камера (видео поток). Камерата може да бъде уникално идентифицирана по следните параметри:

• IP адреси на източника и местоназначението
• Изходен и дестинационен порт
• SSRC. От особено значение е, когато от едно IP се излъчват няколко потока, т.е. в случай на многопортов енкодер.

Интересното е, че първоначално направихме идентификация на камерата само чрез IP на източника и SSRC, разчитайки на факта, че SSRC трябва да е случаен, но на практика се оказа, че много камери задават SSRC на фиксирана стойност (да речем, 256). Очевидно това се дължи на спестяване на ресурси. В резултат на това трябваше да добавим портове към идентификатора на камерата. Това реши напълно проблема с уникалността.

Как да отделя RTP пакети от друг трафик?

Остава въпросът: как Berkut-MX, след като е приел пакета, ще разбере, че това е RTP? RTP хедърът няма такава изрична идентификация като IP, няма контролна сума, може да се предава по UDP с номера на портове, които се избират динамично при установяване на връзката. И в нашия случай повечето от връзките отдавна са установени и можете да чакате много дълго време за преинсталиране.

За да разрешите този проблем, се препоръчва в rfc3550 (Приложение A.1) да проверите битовете на RTP версията - това са два бита, и полето Payload Type (PT) - седем бита, което в случай на динамичен тип отнема малък диапазон. На практика установихме, че за набора от камери, с които работим, PT се побира в диапазона от 96 до 100.

Има още един фактор - паритетът на пристанището, но както показа практиката, той не винаги се спазва, така че трябваше да бъде изоставен.

По този начин поведението на Berkut-MX е следното:

1. получаваме пакет, разглобяваме го на полета;
2. ако версията е 2 и типът полезен товар е в дадените граници, тогава изпращаме заглавките към сървъра.

Очевидно при този подход има фалшиви положителни резултати, т.к. не само RTP пакетите могат да попаднат под такива прости критерии. Но за нас е важно, че определено няма да пропуснем RTP пакета и сървърът ще филтрира „грешните“ пакети.

За филтриране на фалшиви случаи сървърът използва механизъм, който регистрира източника на видео трафик за няколко последователно получени пакета (в пакета има пореден номер!). Ако дойдат няколко пакета с последователни номера, това не е случайно и започваме да работим с този поток. Този алгоритъм се оказа много надежден.

Преместване на…

Осъзнавайки, че цялата информация, която идва в пакети, не е необходима за измерване на качеството и идентифициране на потоци, ние решихме да прехвърлим цялата натоварена и критична във времето работа по получаване и изолиране на полетата на RTP пакети към Berkut-MX, тоест към FPGA. Той „намира“ видео потока, анализира пакета, оставя само задължителните полета и го изпраща до обикновен сървър в UDP тунела. Сървърът прави измервания за всяка камера и записва резултатите в базата данни.

В резултат на това сървърът не работи с 50-60 Gigabit / s, а с максимум 5% (това е точно съотношението на изпратените данни към средния размер на пакета). Тоест на входа на цялата система 55 Gigabit / s и само не повече от 3 Gigabit / s достига до сървъра!

В резултат на това получихме следната архитектура:

И получихме първия резултат в тази конфигурация две седмици след настройката на първоначалния TOR!

Какъв е крайният резултат от сървъра?

И така, какво прави сървърът в нашата архитектура? Неговите задачи:

• слушане на UDP сокет и четене на полета с пакетирани заглавки от него;
• анализира входящите пакети и извлича RTP заглавните полета от там заедно с идентификаторите на камерата;
• съпоставете получените полета с тези, които са били получени преди, и разберете дали пакетите са били изгубени, дали пакетите са били изпращани многократно, дали редът на пристигане се е променил, каква е била промяната в забавянето на транзита на пакета (трептене) и т.н.;
• запис на измерените данни в базата данни по време;
• анализира базата и генерира доклади, изпраща капани за критични събития (висока загуба на пакети, загуба на пакети от някоя камера и т.н.).

Въпреки факта, че общият трафик на входа на сървъра е около 3 Gigabit / s, сървърът се справя дори ако не използваме никакви DPDK, а просто работим през linux сокет (след увеличаване на размера на буфера за сокета, разбира се) . Освен това ще бъде възможно да се свързват нови връзки и MX "s, тъй като маржът на производителността остава.

Ето как изглежда горната част на сървъра (това е горната част само на един lxc контейнер, отчетите се генерират в друг):

От него се вижда, че цялото натоварване за изчисляване на параметрите на качеството и отчитане на статистиката е равномерно разпределено върху четири процеса. Успяхме да постигнем такова разпределение с помощта на хеширане в FPGA: хеш функцията се изчислява по IP, а най-малко значимите битове от получения хеш определят номера на UDP порта, към който ще отиде статистиката. Съответно всеки процес, слушащ своя порт, получава приблизително еднакво количество трафик.

минуси и плюсове

Време е да се похвалите и да признаете недостатъците на решението.

Ще започна с плюсовете:

• без загуба на кръстовището с 10G връзки. Тъй като FPGA поема целия „удар“, можем да сме сигурни, че всеки пакет ще бъде анализиран;
• за наблюдение на 55 000 камери (или повече) е необходим само един сървър с една 10G карта. В момента използваме сървъри, базирани на 2x Xeon с 4 ядра по 2400 MHz всяко. Достатъчно с резерв: успоредно със събирането на информация се генерират отчети;
• наблюдението на 8 "десетки" (10G връзки) се побира само в 2-3 единици: не винаги има много място и мощност в стойката за системата за наблюдение;
• когато свързвате връзки от MX през комутатора, можете да добавяте нови връзки, без да спирате наблюдението, защото не е необходимо да вмъквате никакви платки в сървъра и не е необходимо да го изключвате за това;
• сървърът не е претоварен с данни, той получава само това, което е необходимо;
• заглавките от MX идват в jumbo Ethernet пакет, което означава, че процесорът няма да бъде задушен от прекъсвания (освен това не забравяме за обединяването на прекъсванията).

Честно казано, ще разгледам недостатъците:

• поради тежка оптимизация за конкретна задача, добавянето на поддръжка за нови полета или протоколи изисква промени в кода на FPGA. Това води до повече време, отколкото ако направихме същото на процесора. Както при разработка и тестване, така и по време на внедряване;
• видео информацията изобщо не се анализира. Камерата може да заснеме висяща висулка пред нея или да бъде обърната в грешната посока. Този факт ще остане незабелязан. Разбира се, предвидили сме възможност за запис на видео от избраната камера, но операторът не може да мине през всичките 55 000 камери!
• сървър и устройства, работещи с FPGA, са по-скъпи от само един или два сървъра;)

Резюме

В крайна сметка получихме софтуерно-хардуерен комплекс, в който можем да контролираме както частта, която анализира пакетите на интерфейсите, така и частта, която поддържа статистика. Пълният контрол върху всички възли на системата буквално ни спаси, когато камерите започнаха да превключват на RTSP/TCP interleaved режим. Тъй като в този случай RTP хедърът вече не се намира в пакета с фиксирано отместване: той може да бъде навсякъде, дори на границата на два пакета (първата половина в единия, втората в другия). Съответно алгоритъмът за получаване на RTP хедъра и неговите полета е претърпял фундаментални промени. Трябваше да направим повторно сглобяване на TCP на сървъра за всички 50 000 връзки - оттук и доста високото натоварване в горната част.

Никога преди не сме работили в областта на приложения с високо натоварване, но успяхме да разрешим проблема благодарение на нашите умения в FPGA и се получи доста добре. Имаше дори марж - например, още 20-30 хиляди потока могат да бъдат свързани към система с 55 000 камери.

Настройка на подсистеми на Linux (разпределение на опашки по прекъсвания, увеличаване на буферите за получаване, директно разпределение на ядра към конкретни процеси и т.н.) Оставих извън обхвата на статията, т.к. тази тема вече е много добре покрита.

Описах далеч не всичко, събраха се много рейкове, така че не се колебайте да задавате въпроси :)

Много благодаря на всички, които прочетоха до края!

Бързият растеж на Интернет поставя нови изисквания към скоростта и обема на пренос на данни. И за да се задоволят всички тези изисквания, не е достатъчно само да се увеличи капацитетът на мрежата, необходими са разумни и ефективни методи за управление на трафика и претоварването на преносните линии.

В приложенията в реално време подателят генерира поток от данни с постоянна скорост, а получателят (или получателите) трябва да предостави тези данни на приложението със същата скорост. Такива приложения включват например аудио и видео конференции, видео на живо, медицинска дистанционна диагностика, компютърна телефония, разпределена интерактивна симулация, игри, наблюдение в реално време и други.

Най-широко използваният протокол на транспортния слой е TCP. Въпреки че TCP може да поддържа голямо разнообразие от разпределени приложения, той не е подходящ за приложения в реално време.

Тази задача е предназначена да бъде решена от новия транспортен протокол в реално време - RTP(Real-Time Transport Protocol), който гарантира доставката на данни до една или повече дестинации със закъснение в рамките на определени граници, т.е. данните могат да се възпроизвеждат в реално време.

Принципи на конструиране на RTP протокола

RTP не поддържа никакъв механизъм за доставка на пакети, валидност на предаването или надеждност на връзката. Всички тези функции са присвоени на транспортния протокол. RTP работи върху UDP и може да поддържа трансфер на данни в реално време между множество участници в RTP сесия.

Забележка

За всеки участник в RTP сесията се определя от двойка транспортни адреси на дестинация на пакети (един мрежов адрес - IP и двойка портове: RTP и RTCP).

RTP пакетите съдържат следните полета: идентификационен номер на изпращача, указващ коя страна генерира данните, времеви отпечатъци на генерирането на пакета, така че данните да могат да се възпроизвеждат от получаващата страна на правилните интервали, информация за реда на предаване и информация за естеството на съдържанието на пакета, като например тип кодиране на видео (MPEG, Indeo и др.). Наличието на такава информация дава възможност да се оцени стойността на първоначалното закъснение и размера на буфера за предаване.

Забележка

В типична среда в реално време изпращачът генерира пакети с постоянна скорост. Те се изпращат на редовни интервали, преминават през мрежата и се получават от приемник, който възпроизвежда данните в реално време, докато са получени. Въпреки това, поради промени в латентността, когато пакетите се предават по мрежата, те може да пристигат на нередовни интервали. За да се компенсира този ефект, входящите пакети се буферират, задържат се за известно време и след това се предоставят с постоянна скорост. софтуерТова, което генерира изхода. Следователно, за да функционира протоколът в реално време, е необходимо всеки пакет да съдържа времева марка - така че получателят да може да възпроизвежда входящите данни със същата скорост като изпращача.

Тъй като RTP определя (и регулира) формата на полезния товар на предаваните данни, концепцията за синхронизация е пряко свързана с това, за което механизмът за превод на RTP, миксерът, е частично отговорен. При получаване на потоци от RTP пакети от един или повече източници, миксерът ги комбинира и изпраща нов поток от RTP пакети до един или повече получатели. Миксерът може просто да комбинира данните, както и да променя формата си, например при комбиниране на няколко източника на звук. Нека се преструваме, че нова системаиска да участва в сесията, но неговата връзка към мрежата няма достатъчен капацитет, за да поддържа всички RTP потоци, тогава миксерът получава всички тези потоци, обединява ги в един и предава последния на новия член на сесията. Когато получава множество потоци, миксерът просто добавя PCM стойностите. RTP хедърът, генериран от миксера, включва самоличността на подателя, чиито данни присъстват в пакета.

По-простото релейно устройство създава един изходящ RTP пакет за всеки входящ RTP пакет. Този механизъм може да промени формата на данните в пакета или да използва различен набор от протоколи от ниско ниво за прехвърляне на данни от един домейн в друг. Например потенциален получател може да не е в състояние да обработи високоскоростния видео сигнал, използван от други участници в сесията. Преводачът преобразува видеото във формат с по-ниско качество, който изисква различен висока скоростпредаване на данни.

Методи за контрол на работата

Протоколът RTP се използва само за прехвърляне на потребителски данни - обикновено мултикаст - към всички участници в сесията. Заедно с RTP работи протоколът RTCP (Real-time Transport Control Protocol), чиято основна задача е да осигури контрол върху предаването на RTP. RTCP използва същия основен транспортен протокол като RTP (обикновено UDP), но различен номер на порт.

RTCP изпълнява няколко функции:

1. Осигуряване и наблюдение на качеството на услугите и обратна връзка при претоварване. Тъй като RTCP пакетите са мултикаст, всички участници в сесията могат да оценят колко добре се представят и получават другите участници. Съобщенията на подателя позволяват на получателите да оценят скоростта на предаване на данни и качеството на предаване. Съобщенията на получателите съдържат информация за проблемите, които изпитват, включително загуба на пакети и прекомерна вълна. Обратната връзка от получателя също е важна за диагностициране на грешки при разпространение. Анализирайки съобщенията на всички участници в сесията, мрежовият администратор може да определи дали проблемът засяга един участник или е от общ характер. Ако изпращащото приложение стигне до заключението, че проблемът е типичен за системата като цяло, например поради повреда на един от комуникационните канали, то може да увеличи степента на компресиране на данните поради намаляване на качеството или отказвайте да предавате видео изобщо - това ви позволява да прехвърляте данни през връзката с нисък капацитет.
2. Идентификация на подателя. RTCP пакетите съдържат стандартно текстово описание на подателя. Те предоставят повече информация за изпращача на пакети с данни, отколкото произволно избран идентификатор на източник на синхронизиране. В допълнение, те помагат на потребителя да идентифицира нишки, свързани с различни сесии.
3. Оразмеряване и мащабиране на сесии. За да гарантираме качеството на услугите и обратна връзкас цел контрол на задръстванията, както и с цел идентифициране на подателя, всички участници периодично изпращат RTCP пакети. Честотата на предаване на тези пакети намалява с увеличаване на броя на участниците. При малък брой участници един RTCP пакет се изпраща максимум на всеки 5 секунди. RFC-1889 описва алгоритъм, при който участниците ограничават скоростта на RTCP пакетите въз основа на общия брой участници. Целта е да поддържате RTCP трафика под 5% от общия трафик на сесията.

Формат на заглавката на RTP протокола

RTP е потоково ориентиран протокол. Заглавието на RTP пакета е проектирано с оглед на нуждите от предаване в реално време. Той съдържа информация за реда на пакетите, така че потокът от данни да бъде правилно сглобен в приемащия край, и времева маркировка за правилно вплитане на кадри по време на възпроизвеждане и за синхронизиране на множество потоци от данни, като видео и аудио.

Всеки RTP пакет има основен хедър и евентуално допълнителни полета, специфични за приложението.

Използването на TCP като транспортен протокол за тези приложения не е възможно поради няколко причини:

1. Този протокол позволява да се установи връзка само между две крайни точки и следователно не е подходящ за мултикастинг.
2. TCP осигурява повторно предаване на загубени сегменти, които пристигат, когато приложението в реално време вече не ги чака.
3. TCP няма удобен механизъм за свързване на информация за времето със сегменти, допълнително изискване за приложения в реално време.

Друг широко използван протокол на транспортния слой, LJDP, няма някои от ограниченията на TCP, но не предоставя критична информацияотносно синхронизацията.

Докато всяко приложение в реално време може да има свои собствени механизми за поддържане на предаване в реално време, те споделят много общи характеристики, които правят дефинирането на един протокол много желателно.

Новият транспортен протокол в реално време RTP (Real-time Transport Protocol) е предназначен да реши този проблем, който гарантира доставката на данни до един или повече получатели със закъснение в рамките на зададените граници, т.е. данните могат да бъдат възпроизведени в реално време .

На фиг. 1 представен фиксиран RTP хедър, който съдържа редица полета, идентифициращи елементи като формата на пакета, сериен номер, източници, граници и тип полезен товар. Фиксираният хедър може да бъде последван от други полета, съдържащи допълнителна информация за данните.

0

2

3

4

8

16

31

Идентификатор на източника на синхронизация (SSRC).
Идентификатори на допринасящ източник (CSRC).

Ориз. 1. Фиксиран RTP хедър.

V(2 бита). поле за версия. Текущата версия е втората.
Р(1 бит). Попълнете полето. Това поле сигнализира за наличието на допълващи октети в края на полезния товар. Подпълването се прилага, когато дадено приложение изисква размерът на полезния товар да бъде кратен на, например, 32 бита. В този случай последният октет показва броя на октетите за допълване.
х(1 бит). Поле за разширение на заглавката. Когато това поле е зададено, основният хедър е последван от допълнителен хедър, използван в експериментални RTP разширения.
СС(4 бита). Полето за броя на подателите. Това поле съдържа броя на идентификаторите на подателите, чиито данни са в пакета, като самите идентификатори следват главния хедър.
М(1 бит). Маркерно поле. Значението на маркерния бит зависи от вида на полезния товар. Маркерният бит обикновено се използва за указване на границите на потока от данни. В случай на видео, той задава края на кадъра. В случай на глас, той определя началото на речта след период на мълчание.
RT(7 бита). Поле за тип полезен товар. Това поле идентифицира вида на полезния товар и формата на данните, включително компресия и криптиране. В стационарно състояние изпращачът използва само един тип полезен товар на сесия, но може да го промени в отговор на променящите се условия, ако бъде сигнализиран от протокола за управление на транспорта в реално време.
пореден номер(16 бита). Поле за пореден номер. Всеки източник започва да номерира пакетите от произволен номер, след което увеличава с единица с всеки изпратен RTP пакет данни. Това ви позволява да откриете загуба на пакети и да определите реда на пакетите с едно и също времево клеймо. Няколко последователни пакета може да имат едно и също времево клеймо, ако са логически генерирани в един и същи момент, като например пакети, принадлежащи към един и същ видеокадър.
Времево клеймо(32 бита). Поле за клеймо за време. Това поле съдържа моментът от време, в който е създаден първият октет данни за полезен товар. Мерните единици, в които е посочено времето в това поле, зависят от вида на полезния товар. Стойността се определя от местния часовник на подателя.
Източник на синхронизация (SSRC) Идентификатор(32 бита). Поле за идентификатор на източника на синхронизация: Произволно генерирано число, което уникално идентифицира източника в рамките на сесия и е независимо от мрежовия адрес. Този номер играе важна роля при обработката на входящата част от данните от един източник.
Идентификатор на допринасящ източник (CSRC).(32 бита). Списък с полета за идентификатор на източника, „смесени“ в основния поток, например с помощта на миксер. Миксерът вмъква цял списък от SSRC идентификатори на източници, които са участвали в изграждането на този RTP пакет. Този списък се нарича CSRC. Брой елементи в списъка: от 0 до 15. Ако участниците са повече от 15, се избират първите 15. Пример е аудиоконференция, в чиито RTP пакети се събират изказванията на всички участници, всеки със своите собствен SSRC - те формират списъка на CSRC. В този случай цялата конференция има общ SSRC.

Протоколът RTCP, както всеки контролен протокол, е много по-сложен както по структура, така и по отношение на функциите, които изпълнява (сравнете например протоколите IP и TCP). Въпреки че ядрото на RTCP протокола е RTP, той съдържа много допълнителни полета, с които изпълнява функциите си.

Протокол за резервиране на ресурси - RSVP

За решаване на приоритетния проблем за чувствителните към забавяне данни, за разлика от традиционните данни, за които забавянията не са толкова критични, се използва протоколът за резервиране на ресурси - RSVP, който в момента се разглежда от Internet Engineering Task Force (IETF). RSVP позволява крайни системирезервни мрежови ресурси за получаване на необходимото качество на услугата, по-специално ресурси за графики в реално време, използващи протокола RTP. RSVP се занимава предимно с рутери, въпреки че приложенията на крайния възел също трябва да знаят как да използват RSVP, за да резервират необходимата честотна лента за даден клас на услуга или ниво на приоритет.

RTP, заедно с другите описани стандарти, прави възможно успешното предаване на видео и аудио през конвенционални IP мрежи. RTP/RTCP/RSVP е стандартизирано решение за мрежи за данни в реално време. Единственият му недостатък е, че е само за IP мрежи. Това ограничение обаче е временно: мрежите ще се развиват в тази посока по един или друг начин. Това решение обещава да реши проблема с предаването на чувствителни към забавяне данни по интернет.

Литература

Описание на RTP протокола може да се намери в RFC-1889.

Изискването за поддръжка на няколко вида трафик с различни изисквания за качество на услугата, базирано на стека на протоколите TCP / IP, вече е много актуално. Този проблем се решава от протокола за транспортиране в реално време (RTP), който е стандарт на IETF за предаване в реално време на данни като глас или видео по мрежа, която не гарантира качество на услугата.

RTP протоколът гарантира доставката на данни до един или повече получатели със закъснение, което не надвишава определената стойност. За да направите това, заглавката на протокола съдържа времеви марки, необходими за успешното възстановяване на аудио и видео информация, както и данни за метода на кодиране на информация.

Въпреки че протоколът TCP гарантира доставката на предадените данни в правилната последователност, трафикът не е еднакъв, тоест възникват непредсказуеми забавяния по време на доставката на дейтаграми. Тъй като RTP протоколът е наясно със съдържанието на дейтаграмите и има механизми за откриване на загуба на данни, той може да намали латентността до приемливо ниво.

Адресна схема на IP протокол

Схемата за адресиране на мрежата, използвана в IP протокола, е описана в RFC 990 и RFC 997. Тя се основава на разделянето на адресиращи мрежи от адресиращи устройства в тези мрежи. Тази схема улеснява маршрутизирането. В този случай адресите трябва да се задават по подреден (последователен) начин, за да се направи маршрутизирането по-ефективно.

Когато използвате протоколния стек TCP / IP в мрежата, крайните устройства получават уникални адреси. Такива устройства могат да бъдат персонални компютри, медийни сървъри, рутери и т.н. Въпреки това, някои устройства, които имат множество физически портове, като рутери, трябва да имат уникален адрес на всеки от портовете. Въз основа на схемата за адресиране и факта, че някои устройства в мрежата могат да имат няколко адреса, можем да заключим, че тази схема за адресиране не описва самото устройство в мрежата, а конкретна връзка на това устройство към мрежата. Тази схема води до редица неудобства. Една от тях е необходимостта от промяна на адреса на устройството при преместването му в друга мрежа. Друг недостатък е, че за да работите с устройство, което има няколко връзки в разпределена мрежа, трябва да знаете всичките му адреси, които идентифицират тези връзки.

Така че за всяко устройство в IP мрежи можем да говорим за адреси от три нива:

р Физически адресустройство (по-точно - специфичен интерфейс). За устройства в Ethernet мрежи това е MAC адресът мрежова картаили порт на рутера. Тези адреси се задават от производителите на хардуер. Физическият адрес има шест байта: горните три байта са идентификаторът на производителя, долните три байта са присвоени от производителя;

q IP адрес, състоящ се от четири байта. Този адрес се използва за мрежов слойреферентния модел OSI;

q Символен идентификатор - име. Този идентификатор може да бъде зададен произволно от администратора.

Когато IP протоколът беше стандартизиран през септември 1981 г., неговата спецификация изискваше всяко устройство, свързано към мрежа, да има уникален 32-битов адрес. Този адрес е разделен на две части. Първата част от адреса идентифицира мрежата, в която се намира устройството. Втората част уникално идентифицира самото устройство в мрежата. Тази схема води до двустепенна адресна йерархия (Фигура 6.23).

Сега се извиква полето за номер на мрежата в адреса мрежов префикс,тъй като идентифицира мрежата. Всички работни станции в мрежата споделят един и същ мрежов префикс. В същото време те трябва да имат уникални номераустройства. Две работни станции, разположени в различни мрежи, трябва да имат различни мрежови префикси, но въпреки това могат да имат един и същ номер на устройство.

За гъвкавост при адресиране компютърни мрежиДизайнерите на протокола определиха, че IP адресното пространство трябва да бъде разделено на три различни класа - A, B и C. Познавайки класа, вие знаете къде е границата между мрежовия префикс и номера на устройството в 32-битов адрес . На фиг. Фигура 6.24 показва адресните формати на тези основни класове.

Едно от основните предимства на използването на класове е, че можете да определите от класа на адреса къде е границата между мрежовия префикс и номера на устройството. Например, ако най-значимите два бита от адреса са 10, тогава точката на разделяне е между битове 15 и 16.

Недостатъкът на този метод е необходимостта от промяна на мрежовия адрес при свързване допълнителни устройства. Например ако общ бройброят на устройствата в мрежа от клас C надвишава 255, тогава ще е необходимо нейните адреси да бъдат заменени с адреси от клас B. Промяната на мрежови адреси ще изисква допълнителни усилия от администратора за отстраняване на грешки в мрежата. Мрежовите администратори не могат плавен преходкъм нов адресен клас, тъй като класовете са ясно разделени. Трябва да забраните използването на цяла група мрежови адреси, да промените едновременно всички адреси на устройства в тази група и едва след това да разрешите отново използването им в мрежата. В допълнение, въвеждането на адресни класове значително намалява теоретично възможния брой индивидуални адреси. AT сегашна версия IP протокол (версия 4) общият брой адреси може да бъде 2 32 (4 294 967 296), тъй като протоколът предвижда използването на 32 бита за определяне на адреса. Естествено, използването на някои битове за служебни цели намалява наличния брой индивидуални адреси.

Клас А е за големи мрежи. Всеки адрес от клас А има 8-битов мрежов префикс с най-значимия бит, зададен на 1, а следващите седем бита се използват за номера на мрежата. Останалите 24 бита се използват за номера на устройството. AT този моментвсички адреси от клас А вече са разпределени. Мрежите от клас A също се наричат ​​"/8", тъй като адресите от клас A имат 8-битов мрежов префикс.

Максималният брой мрежи от клас А е 126 (2 7 -2 - два адреса се изваждат, състоящи се само от нули и единици). Всяка мрежа от този клас поддържа до 16 777 214 (2 24 -2) устройства. Тъй като адресен блок от клас A може да съдържа максимум 231 (2 147483648) индивидуални адреса, а IP версия 4 може да поддържа максимум 232 (4294967296) адреса, клас A заема 50% от общото IP адресно пространство.

Клас B е предназначен за мрежи със среден размер. Всеки адрес от клас B има 16-битов мрежов префикс, където двата най-значими бита са 10, а следващите 14 бита се използват за номера на мрежата. За номера на устройството се отделят 16 бита. Мрежите от клас B също се наричат ​​"/16", тъй като адресите от клас B имат 16-битов мрежов префикс.

Максималният брой мрежи от клас B е 16 382 (2 14 -2). Всяка мрежа от този клас поддържа до 65 534 (2 16 -2) устройства. Тъй като целият адресен блок от клас B може да съдържа максимум 230 (1 073 741 824) отделни адреса, той заема 25% от общото IP адресно пространство.

Адресите от клас C се използват в мрежи с малък брой устройства. Всяка мрежа от клас C има 24-битов мрежов префикс, в който трите най-значими бита са 110, а следващите 21 бита се използват за номера на мрежата. Останалите 8 бита са разпределени за номера на устройства. Мрежите от клас C се наричат ​​също "/24", тъй като адресите от клас C имат 24-битов мрежов префикс.

Максималният брой мрежи от клас C е 2 097 152 (221). Всяка мрежа от този клас поддържа до 254 (2 8 -2) устройства. Клас C заема 12,5% от общото IP адресно пространство.

В табл. 6.9 обобщава нашия анализ на мрежовите класове.

Таблица 6.9. Мрежови класове

В допълнение към тези три класа адреси има още два класа. В клас D най-значимите четири бита са 1110. Този клас се използва за мултикастинг. В клас E горните четири бита са 1111. Той е запазен за експериментиране.

За по-лесно четене на адреси в техническа литература, приложни програми и т.н., IP адресите са представени като четири десетични числаразделени с точки. Всяко от тези числа съответства на един октет (8 бита) от IP адреса. Този формат се нарича десетичен запис с точки (Decimal-Point Notation) или десетичен запис с точки (Фигура 6.25).

В табл. 6.10 изброява диапазоните от десетични стойности за трите класа адреси. В табл. 6.10 Запис XXX означава произволно поле.

Таблица 6.10. Диапазон на стойността на адреса

Някои IP адреси не могат да бъдат присвоени на устройства в мрежата (Таблица 6.11).

Както е показано в тази таблица, в запазените IP адреси всички битове, зададени на нула, съответстват на един от двата това устройство, или тази мрежа, и IP адреси, всички битове от които са зададени на 1, се използват за излъчване на информация. За да се посочи цялата IP мрежа като цяло, се използва адрес с номер на устройство, като всички битове са зададени на "0". Мрежовият адрес от клас A 127.0.0.0 е запазен за обратна връзка и е въведен за тестване на комуникацията между процеси на една и съща машина. Когато дадено приложение използва loopback адрес, TCP/IP протоколният стек връща тези данни на приложението, без да изпраща нищо към мрежата. В допълнение, този адрес може да се използва за взаимодействие на отделни процеси в една и съща машина. Следователно в IP мрежите е забранено да се присвояват IP адреси, започващи с 127, на устройства.

В допълнение към насоченото предаване на данни към конкретна работна станция, активно се използва излъчване на предаване, при което всички станции в текущата или определена мрежа получават информация. В IP протокола има два вида излъчвания: насочени и ограничени.

Насоченото излъчване позволява на устройство в отдалечена мрежа да изпрати дейтаграма до всички устройства в същата мрежа. текуща мрежа. Дейтаграма с препратен адрес за излъчване може да премине през рутери, но ще бъде доставена само до всички устройства в определената мрежа, а не до всички устройства. При насочено излъчване адресът на дестинация се състои от конкретен мрежов номер и номер на устройство, всички битове от които са 0 или 1. Например адреси 185.100.255.255 и 185.100.0.0 ще бъдат третирани като адреси за насочено излъчване за клас B мрежа 185.100.xxx.xxx От гледна точка на адресиране, основният недостатък на насоченото излъчване е, че се изисква познаване на номера на целевата мрежа.

Втората форма на излъчване, наречена ограничено излъчване, излъчва в рамките на текущата мрежа (мрежата, в която се намира изпращащото устройство). Дейтаграма с ограничен адрес за излъчване никога няма да премине през рутер. При ограничено излъчване всички битове на номера на мрежата и номера на устройството са нули или единици. Така дейтаграма с адрес на дестинация 255.255.255.255 или 0.0.0.0 ще бъде доставена до всички устройства в мрежата. На фиг. Фигура 6.26 показва мрежи, свързани с рутери. В табл. Фигура 6.12 изброява получателите на разпръснати дейтаграми, изпратени от работна станция A.

IP протоколът поддържа три метода на адресиране: единично (unicast), излъчване (broadcast) и групово (multicast).

Таблица 6.12. Приемници за излъчване на дейтаграми

При единично адресиране дейтаграмите се изпращат до конкретно единично устройство. Прилагането на този подход не е трудно, но ако работна групасъдържа много станции, пропускателната способност може да не е достатъчна, тъй като една и съща дейтаграма ще бъде предавана много пъти.

При широко разпространено адресиране приложенията изпращат една дейтаграма, която се доставя до всички устройства в мрежата. Този подход е още по-прост за изпълнение, но ако в този случай трафикът на излъчване не се ограничава до локална мрежа(и, например, друга мрежа се препраща с помощта на рутери), тогава глобалната мрежа трябва да има значителна честотна лента. Ако информацията е предназначена само за малка група устройства, тогава този подход изглежда ирационален.

При мултикаст дейтаграмите се доставят до определена група устройства. В същото време (което е много важно при работа в разпределени мрежи) не се генерира излишен трафик. Мултикаст и един адрес дейтаграми се различават по адрес. В заглавката на IP дейтаграма с мултикаст, вместо IP адреси от класове A, B, C, има адрес от клас D, т.е. групов адрес.

Групов адрес се присвоява на някои устройства получатели или, с други думи, на група. Подателят записва този мултикаст адрес в заглавката на IP дейтаграмата. Дейтаграмата ще бъде доставена до всички членове на групата. Първите четири бита на адреса от клас D са 1110. Останалата част от адреса (28 бита) е заета от идентификатора на групата (Фигура 6.27).

В десетичен формат с точки груповите адреси варират от 224.0.0.0 до 239.255.255.255. В табл. Фигура 6.13 показва схемата за разпределяне на адреси от клас D.

Таблица 6.13. Разпределение на адреси от клас D

Както се вижда от табл. 6.13, първите 256 адреса са запазени. По-специално, този диапазон е запазен за протоколи за маршрутизиране и други протоколи от ниско ниво. В табл. 6.14 съдържа някои запазени IP адреси от клас D.

Над този диапазон е голяма групаадреси, разпределени за приложения, работещи в Интернет. Най-горният диапазон от адреси (приблизително 16 милиона адреса) е за административни цели в локални мрежи. Груповите адреси от клас D се управляват централно и регистрират от специална организация, наречена IANA.

Мултикастът може да бъде реализиран на две нива на OSI модела – канално (Data-Link Layer) и мрежово (Network Layer). Протоколите за предаване на ниво връзка, като Ethernet и FDDI, могат да поддържат единично, излъчващо и групово адресиране. Груповото предаване на ниво връзка е особено ефективно, ако се поддържа от хардуера на NIC.

За да се поддържа мултикастиране на IANA, е разпределен блок от мултикаст Ethernet адреси, започвайки от 01-00-5E (в шестнадесетичен запис). Груповият IP адрес може да бъде преведен в адрес в този блок. Принципът на транслация е доста прост: долните 23 бита от идентификатора на IP групата се копират в долните 23 бита на Ethernet адреса. Обърнете внимание, че тази схема свързва до 32 различни IP групи с един и същ Ethernet адрес, тъй като следващите 5 бита от идентификатора на IP групата се игнорират.

Таблица 6.14. Запазени адреси клас D

Адрес	Предназначение
224.0.0.1	Всички устройства в подмрежата
224.0.0.2	Всички рутери в подмрежата
224.0.0.4	Всички DVMRP рутери
224.0.0.5	Всички MOSPF рутери
224.0.0.9	RIP IP версия II
224.0.1.7	аудио новини
224.0.1.11	IEFT аудио
224.0.1.12	IEFT видео

Ако изпращачът и получателят принадлежат към една и съща физическа мрежа, процесът на изпращане и получаване на групови кадри на слоя за връзка е доста прост. Подателят посочва IP адреса на групата получатели, а NIC преобразува този адрес в съответния групов Ethernet адрес и изпраща рамката.

Ако подателят и получателят са в различни подмрежи, свързани с рутери, доставката на дейтаграма е трудна. В този случай рутерите трябва да поддържат един от протоколите за мултикаст маршрутизиране (DVMRP, MOSPF, PIM - вижте по-долу). Съгласно тези протоколи рутерът ще изгради дърво за доставка и правилно ще препрати мултикаст трафика. Освен това всеки рутер трябва да поддържа протокол за управление на група (IGMP), за да определи присъствието на членове на групата в директно свързани подмрежи (Фигура 6.28).

Ако един ден трябва бързо да разберете какво е VoIP (глас през IP) и какво означават всички тези диви съкращения, надявам се това ръководство да ви помогне. Веднага ще отбележа, че проблемите с конфигурирането на допълнителни видове телефонни услуги (като прехвърляне на разговори, гласова поща, конферентни разговори и др.) не се вземат предвид тук.

И така, с какво ще се занимаваме под разреза:

1. Основни понятия на телефонията: видове устройства, схеми на свързване
2. Пакет от SIP/SDP/RTP протоколи: как работи
3. Как се предава информация за натиснати бутони
4. Как работи предаването на глас и факс?
5. Цифрова обработка на сигнала и осигуряване на качеството на звука в IP телефонията

1. Основни понятия на телефонията

Като цяло схемата за свързване на местен абонат към телефонен доставчик чрез обикновена телефонна линия е следната:

От страната на доставчика (PBX) е инсталиран телефонен модул с FXS (Foreign eXchange Subscriber) порт. Вкъщи или в офиса се инсталира телефон или факс с FXO (Foreign eXchange Office) порт и модул за набиране.

от външен видПортовете FXS и FXO не се различават, те са обикновени 6-пинови RJ11 конектори. Но с помощта на волтметър е много лесно да ги различите - винаги ще има известно напрежение на FXS порта: 48/60 V, когато слушалката е спусната, или 6-15 V по време на разговор. На FXO, ако не е свързан към линията, напрежението винаги е 0.

За прехвърляне на данни по телефонна линия е необходима допълнителна логика от страна на доставчика, която може да се реализира на модула SLIC (subscriber line interface circuit), а от страна на абоната - с помощта на модула DAA (Direct Access Arrangement).

Безжичните DECT телефони (цифрови европейски безжични телекомуникации) са доста популярни сега. По отношение на устройството те са подобни на обикновените телефони: те също имат FXO порт и модул за набиране, но имат и модул безжична комуникациястанции и слушалки на честота 1,9 GHz.

Абонатите се свързват към PSTN мрежата (обществена комутируема телефонна мрежа) - телефонна мрежаобща употреба, това е PSTN, PSTN. PSTN мрежата може да бъде организирана с помощта на различни технологии: ISDN, оптика, POTS, Ethernet. Специален случай на PSTN, когато се използва обикновена аналогова/медна линия - POTS (Plain Old Telephone Service) - проста стара телефонна система.

С развитието на Интернет телефонни комуникациипреместени на ново ниво. Стационарните телефони се използват все по-рядко, предимно за служебни нужди. DECT телефоните са малко по-удобни, но ограничени до периметъра на къщата. GSM-телефоните са още по-удобни, но са ограничени от границите на страната (роумингът е скъп). Но за IP телефоните те също са софтуерни телефони (SoftPhone), няма ограничения, освен за достъп до интернет.

Skype е най-известният пример за софтфон. Може да прави много неща, но има два важни недостатъка: затворена архитектура и подслушването се знае от кои органи. Поради първото не е възможно да създадете собствена телефонна микромрежа. И заради второто – не е много приятно, когато те шпионират, особено в лични и търговски разговори.

За щастие има отворени протоколи за създаване на собствени комуникационни мрежи с екстри - това са SIP и H.323. Има малко повече софтуерни телефони на SIP протокола, отколкото на H.323, което може да се обясни с неговата относителна простота и гъвкавост. Но понякога тази гъвкавост може да постави голям удар в колелото. И двата протокола SIP и H.323 използват RTP протокола за прехвърляне на медийни данни.

Обмисли основни принципи SIP протокол, за да разберете как се осъществява връзката на двама абонати.

2. Описание на пакета от SIP/SDP/RTP протоколи

SIP (Session Initiation Protocol) - протокол за установяване на сесия (не само телефонна) е текстов протокол през UDP. Възможно е също да използвате SIP през TCP, но това са редки случаи.

SDP (Session Description Protocol) е протокол за договаряне на вида на предаваните данни (за звук и видео това са кодеци и техните формати, за факсове - скорост на предаване и коригиране на грешки) и техните целеви адреси (IP и порт). Това също е текстов протокол. SDP параметрите се изпращат в тялото на SIP пакетите.

RTP (транспортен протокол в реално време) е протокол за пренос на аудио/видео данни. Това е двоичен протокол през UDP.

Обща структура на SIP пакетите:

• Начален ред: поле, указващо SIP метода (команда), когато бъде поискан, или резултата от изпълнението на SIP метода при отговор.
• заглавки: Допълнителна информациякъм началния ред, форматирани като низове, съдържащи двойки АТРИБУТ: СТОЙНОСТ.
• Тяло: двоични или текстови данни. Обикновено се използва за изпращане на SDP параметри или съобщения.

Ето пример за два SIP пакета за една обща процедура за настройка на повикване:

Вляво е съдържанието на пакета SIP INVITE, вдясно е отговорът към него - SIP 200 OK.

Основните полета са рамкирани:

• Method/Request-URI съдържа SIP метода и URI. В примера е установена сесията - методът INVITE, абонатът е извикан [имейл защитен]
• Status-Code - код на отговор за предишната SIP команда. AT този примеркомандата е изпълнена успешно - код 200, т.е. Абонат 555 вдигна слушалката.
• Чрез - адрес, на който абонат 777 чака отговор. За съобщението 200 OK това поле се копира от съобщението INVITE.
• От/До - показвано име и адрес на подателя и получателя на съобщението. За съобщението 200 OK това поле се копира от съобщението INVITE.
• Cseq съдържа поредния номер на командата и името на метода, за който се отнася даденото съобщение. За съобщението 200 OK това поле се копира от съобщението INVITE.
• Content-Type - типът данни, които се предават в блока Body, в този случай SDP данни.
• Информация за връзка - IP адрес, на който вторият абонат трябва да изпрати RTP пакети (или UDPTL пакети в случай на предаване на факс чрез T.38).
• Media Description - портът, към който вторият абонат трябва да предаде посочените данни. В случая това са аудио (аудио RTP/AVP) и списък с поддържаните типове данни - PCMU, PCMA, GSM кодеци и DTMF сигнали.

Едно SDP съобщение се състои от редове, съдържащи двойки FIELD=VALUE. Основните полета включват:

• о- Произход, име на организатора на сесията и ID на сесията.
• с- Информация за връзка, полето е описано по-рано.
• м- Описание на медията, полето е описано по-рано.
• а- медийни атрибути, указват формата на предаваните данни. Например те показват посоката на звука - приемане или предаване (sendrecv), за кодеци показват честотата на дискретизация и номера на свързване (rtpmap).

RTP пакетите съдържат аудио/видео данни, кодирани в определен формат. Този форматпосочени в полето PT (тип полезен товар). Таблица за това как стойността на това поле съответства на конкретен формат е дадена в https://wikipedia org wiki RTP аудио видео профил.

Освен това RTP пакетите съдържат уникален SSRC идентификатор (дефинира източника на RTP потока) и времева маркировка (времева маркировка, използвана за равномерно възпроизвеждане на аудио или видео).

Пример за взаимодействие между два SIP абоната чрез SIP сървър (Asterisk):

Веднага след като SIP телефон стартира, първото нещо, което прави, е да се регистрира отдалечен сървър(SIP Registar), изпраща съобщение SIP REGISTER към него.

При повикване на абонат се изпраща съобщение SIP INVITE, чието тяло съдържа SDP съобщение, съдържащо параметрите за аудио / видео предаване (кои кодеци се поддържат, към кой IP и порт да се изпрати аудио и т.н.).

Когато отдалеченият абонат вдигне телефона, получаваме съобщение SIP 200 OK също с SDP параметри, само отдалеченият абонат. Използвайки изпратените и получените SDP параметри, можете да настроите RTP аудио/видео сесия или T.38 факс сесия.

Ако получените SDP параметри не ни подхождат или междинният SIP сървър реши да не пропуска RTP трафик през себе си, тогава се изпълнява процедурата за повторно договаряне на SDP, така наречената REINVITE. Между другото, именно поради тази процедура безплатните SIP прокси сървъри имат един недостатък - ако и двамата абонати са в една и съща локална мрежа и прокси сървърът е зад NAT, тогава след пренасочване на RTP трафик никой от абонатите няма да чуе друг.

След края на разговора абонатът, който е затворил, изпраща съобщение SIP BYE.

3. Прехвърляне на информация за натиснати бутони

Понякога, след като сесията е установена, по време на разговор е необходим достъп до допълнителни услуги (VAS) - задържане на разговор, прехвърляне, гласова поща и др. - които реагират на определени комбинации от натиснати бутони.

И така, в обикновена телефонна линия има два начина за набиране на номер:

• Pulse - исторически първият, се използва главно в телефони с ротационен дайлер. Набирането става чрез последователно затваряне и отваряне на телефонната линия според набраната цифра.
• Тонално - набиране с DTMF кодове (Dual-Tone Multi-Frequency) - всеки бутон на телефона има собствена комбинация от два синусоидални сигнала (тона). Чрез изпълнение на алгоритъма на Goertzel е доста лесно да се определи натиснатият бутон.

По време на разговор импулсният метод е неудобен за предаване на натиснатия бутон. Така отнема приблизително 1 секунда за предаване на "0" (10 импулса по 100 ms всеки: 60 ms - прекъсване на линия, 40 ms - затваряне на линия) плюс 200 ms за пауза между цифрите. Освен това по време на импулсно набиране често ще се чуват характерни щракания. Следователно при конвенционалната телефония се използва само тонов режим за достъп до VAS.

При VoIP телефонията информацията за натиснатите бутони може да се предава по три начина:

1. DTMF Inband - генерирането на аудио тон и предаването му вътре в аудио данните (текущ RTP канал) е нормално тонално набиране.
2. RFC2833 - генерира се специален RTP пакет за телефонно събитие, който съдържа информация за натиснат клавиш, сила на звука и продължителност. Номерът на RTP формата, в който ще се предават RFC2833 DTMF пакети, е посочен в тялото на SDP съобщението. Например: a=rtpmap:98 telefon-event/8000.
3. SIP INFO - формира се SIP INFO пакет с информация за натиснат клавиш, сила на звука и продължителност.

DTMF предаването вътре в аудио данни (Inband) има няколко недостатъка - това са допълнителни ресурси при генериране/вграждане на тонове и при откриването им, ограничения на някои кодеци, които могат да изкривят DTMF кодовете, и ниска надеждност на предаване (ако част от пакетите се загубят, тогава откриването може да възникне при натискане на същия клавиш два пъти).

Основната разлика между DTMF RFC2833 и SIP INFO: ако SIP прокси сървърът има способността да прехвърля RTP директно между абонати, заобикаляйки самия сървър (например canreinvite=yes в звездичка), тогава сървърът няма да забележи RFC2833 пакети, тъй като резултат от което стават недостъпни услуги DVO. SIP пакетите винаги се предават през SIP прокси сървъри, така че VAS винаги ще работи.

4. Предаване на глас и факс

Както вече споменахме, RTP протоколът се използва за прехвърляне на медийни данни. RTP пакетите винаги определят формата на предаваните данни (кодек).

Има много различни кодеци за предаване на глас, с различни съотношения битрейт / качество / сложност, има отворени и затворени. Всеки софтфон трябва да има поддръжка за кодеци G.711 alaw/ulaw, внедряването им е много просто, качеството на звука е добро, но те изискват честотна лента от 64 kbps. Например кодекът G.729 изисква само 8 kbps, но е много интензивен на процесора и не е безплатен.

За предаване на факс обикновено се използва кодек G.711 или протокол T.38. Изпращането на факс с помощта на кодека G.711 съответства на изпращането на факс с помощта на протокола T.30, сякаш факсът е изпратен по обикновена телефонна линия, но в същото време аналогов сигналот линията се цифровизира съгласно закона alaw/ulaw. Това също се нарича Inband T.30 факс.

Факсовете, използващи протокола T.30, договарят своите параметри: скорост на предаване, размер на дейтаграмата, тип корекция на грешки. Протоколът T.38 е базиран на протокола T.30, но за разлика от Inband предаването, генерираните и получени T.30 команди се анализират. Така се предават не необработени данни, а разпознати команди за управление на факса.

Командата T.38 се предава с помощта на протокола UDPTL, който е базиран на UDP протокол и се използва само за T.38. TCP и RTP протоколите също могат да се използват за предаване на T.38 команди, но те се използват много по-рядко.

Основните предимства на T.38 са намалено натоварване на мрежата и по-голяма надеждност в сравнение с предаването на факс в лентата.

Процедурата за изпращане на факс в режим T.38 е както следва:

1. Нормална гласова връзка се установява с помощта на произволен кодек.
2. Когато хартията е заредена в изпращащото факс устройство, то периодично изпраща сигнал T.30 CNG (Calling Tone), за да покаже, че е готово да изпрати факс.
3. От приемащата страна се генерира T.30 сигнал CED (Called Terminal Identification) - това е готовността за получаване на факс. Този сигнал се изпраща или след натискане на бутона "Получаване на факс", или факсът го прави автоматично.
4. Сигналът CED се открива от изпращащата страна и се появява процедурата SIP REINVITE и типът T.38 е посочен в SDP съобщението: m=image 39164 udptl t38.

Изпращане на факсове по интернет за предпочитане в T.38. Ако факсът трябва да бъде предаден в рамките на офиса или между обекти, които имат стабилна връзка, тогава може да се използва предаване на факс Inband T.30. В този случай, преди да изпратите факс, процедурата за премахване на ехото трябва да бъде изключена, за да не се внасят допълнителни изкривявания.

Много подробна информация за факса е написана в книгата "Факс, модем и текст за IP телефония" от Дейвид Ханес и Гонсало Салгейро.

5. Цифрова обработка на сигнала (DSP). Осигуряване на качество на звука при IP телефония, тестови примери

Разгледахме протоколите за установяване на разговорна сесия (SIP / SDP) и метода за предаване на аудио през RTP канал. Имаше един важен въпрос - качеството на звука. От една страна, качеството на звука се определя от избрания кодек. Но от друга страна, все още са необходими допълнителни DSP процедури (DSP - цифрова обработка на сигнала). Тези процедури отчитат особеностите на VoIP телефонията: не винаги се използват висококачествени слушалки, има изпускане на пакети в интернет, понякога пакетите пристигат неравномерно, пропускателна способностмрежите също не са гумени.

Основни процедури, които подобряват качеството на звука:

VAD(Детектор на гласова активност) - процедура за определяне на кадри, които съдържат глас (активен гласов кадър) или мълчание (неактивен гласов кадър). Това разделяне може значително да намали натоварването на мрежата, тъй като предаването на информация за мълчанието изисква много по-малко данни (достатъчно е да се предаде нивото на шума или нищо).

Някои кодеци вече съдържат VAD процедури (GSM, G.729), докато други (G.711, G.722, G.726) трябва да ги внедрят.

Ако VAD е конфигуриран да предава информация за нивото на шума, тогава специални SID пакети (Silence Insertion Descriptor) се предават в 13-ия CN (Comfort Noise) RTP формат.

Струва си да се отбележи, че SID пакетите могат да бъдат премахнати от SIP прокси сървъри, така че за проверка е препоръчително да конфигурирате предаването на RTP трафик през SIP сървърите.

CNG(генериране на комфортен шум) - процедура за генериране на комфортен шум въз основа на информация от SID пакети. По този начин VAD и CNG работят заедно, но CNG процедурата е много по-малко търсена, тъй като не винаги е възможно да се забележи работата на CNG, особено при нисък обем.

PLC(укриване на загуба на пакет) - процедурата за възстановяване на аудио потока в случай на загуба на пакет. Дори при 50% загуба на пакети, добър PLC алгоритъм може да постигне приемливо качество на речта. Изкривявания, разбира се, ще има, но можете да различите думите.

Най-лесният начин за емулиране на загуба на пакети (на Linux) е да използвате помощната програма tc от пакета iproute с модула netem. Оформя само изходящия трафик.

Пример за работеща мрежова емулация с 50% загуба на пакети:

Tc qdisc промяна dev eth1 root netem загуба 50%

Деактивиране на емулацията:

Tc qdisc del dev eth1 root

буфер за трептене- процедура за премахване на ефекта на трептене, когато интервалът между получените пакети се променя много, което в най-лошия случай води до неправилен ред на получените пакети. Освен това този ефект води до прекъсване на речта. За да се елиминира ефектът на трептене, е необходимо да се внедри пакетен буфер на приемащата страна с размер, достатъчен за възстановяване на първоначалния ред на изпращане на пакети през даден интервал.

Можете също да емулирате ефекта на трептене, като използвате помощната програма tc (интервалът между очаквания момент на пристигането на пакета и действителния момент може да бъде до 500 ms):

tc qdisc add dev eth1 root netem забавяне 500ms пренареждане 99%

LEC(Line Echo Canceller) - процедура за елиминиране на локално ехо, когато отдалеченият абонат започне да чува собствения си глас. Същността му е да извади получения сигнал от предавания сигнал с определен коефициент.

Ехото може да възникне по няколко причини:

• акустично ехо поради лошо качество на аудио пътя (звук от високоговорителя влиза в микрофона);
• електрическо ехо поради несъответствие на импеданса между телефони SLIC модул. В повечето случаи това се случва във вериги, които преобразуват 4-жична телефонна линия в 2-жична.

Откриването на причината (акустично или електрическо ехо) не е трудно: абонатът, от чиято страна е създадено ехото, трябва да изключи микрофона. Ако ехото все още се появява, значи е електрическо.

За повече информация относно VoIP и DSP процедурите вижте VoIP обработка на глас и факс сигнал. Предварителен преглед е наличен в Google Книги.

Това завършва един повърхностен теоретичен преглед на VoIP. Ако се интересувате, тогава пример за практическо внедряване на мини-PBX на реална хардуерна платформа може да бъде разгледан в следващата статия.

[!?] Въпроси и коментари са добре дошли. На тях ще отговори авторът на статията Дмитрий Валенто, софтуерен инженер в центъра за проектиране на електроника Promwad.

Тагове:

• за начинаещи
• за начинаещи

Добави тагове