Сергей ЛЁВИН, главный конструктор ГК СИГМА
Оперативная связь при организации системы безопасности является одним из важнейших компонентов. От качества связи напрямую зависит слаженность действий службы безопасности как при организации повседневной работы, так и в случае возникновения чрезвычайных ситуаций. В большинстве случаев используют носимые радиостанции, которые в основном успешно решают все задачи оперативной связи. Но вместе с этим традиционная стационарная связь также остается востребованной. Один из возможных вариантов использования – связь между постами охраны.
В одном из проектов, реализованных нашей компанией, необходимо было организовать дуплексные аудио переговоры между линейными постами и центральным постом охраны. Связь должна быть проводной, на линейных постах безнаборные громкоговорящие устройства, на центральном посту – обычный телефонный аппарат с номеронабирателем. Связь может устанавливаться только между центральным постом и линейным, причем по инициативе обоих абонентов. Непосредственно между линейными постами связь не устанавливается. При выборе и анализе возможных решений были рассмотрены варианты аналоговой и цифровой связи.
Как уже говорилось выше, переговорных устройств используются два типа: центральное и линейное абонентское. Дежурный центрального поста должен иметь возможность вызова любого линейного поста путем набора его номера на клавиатуре центрального аппарата. Понятно, что в качестве коммутирующего устройства здесь удобнее всего использовать обычную офисную АТС. Абонентское устройство линейного поста представляет из себя фактически безнаборный телефонный аппарат громкой связи. Единственная кнопка на передней панели служит как для приема входящего вызова, инициации исходящего вызова или выдачи сигнала отбоя для завершения сеанса связи. Рассматривались два варианта построения подобной системы связи: традиционная аналоговая телефонная связь и IP-телефония.
Для подключения оконечного аналогового телефонного устройства к телефонной станции используется аналоговая абонентская линия, имеющая более строгое название – Z-интерфейс. Да да, именно так называются два провода, куда уже более 130 лет подключаются миллиарды обычных телефонных аппаратов. По этим же двум проводам осуществляется питание оконечного абонетского устройства и вся сигнализация - трубка снята, трубка опущена и набор номера. Согласно требованиям абонентская линия должна обеспечивать ток не менее 18 мА. Для создания такого тока используется станционная линейная батарея с номинальным значением напряжения 60В или 48В. Замыкание/размыкание абонентского шлейфа, с помощью контакта телефонного аппарата, используется и для передачи информации в станцию о том что трубка телефонного аппарата снята и о наборе номера. Абонентский комплект должен обеспечивать посылку в абонентскую линию сигнала так называемого индукторного вызова, представляющего собой переменное напряжение 95В с частотой 25Гц. В общем, все просто, кондово и надежно. Тем не менее был рассмотрен второй вариант, гораздо более современный – подключение абонентских устройств через компьютерную сеть.
В основе современной IP-телефонии лежит протокол инициирования сеансов – Session Initiation Protocol (SIP), который является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации. Пользователи могут принимать участие в существующих сеансах связи, приглашать других пользователей и быть приглашенными ими к новому сеансу связи. Приглашения могут быть адресованы определенному пользователю, группе пользователей или всем пользователям. Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543. Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут использоваться протоколы Х.25, Frame Relay, AAL5/ATM, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но, в то же время, предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. При этом, правда, необходимо создать дополнительные механизмы для надежной доставки сигнальной информации. К таким механизмам относятся повторная передача информации при ее потере, подтверждение приема и др.
Здесь же следует отметить то, что сигнальные сообщения могут переноситься не только протоколом транспортного уровня UDP, но и протоколом ТСР. Протокол UDP позволяет быстрее, чем TCP, доставлять сигнальную информацию (даже с учетом повторной передачи неподтвержденных сообщений), а также вести параллельный поиск местоположения пользователей и передавать приглашения к участию в сеансе связи в режиме многоадресной рассылки. В свою очередь, протокол ТСР упрощает работу с межсетевыми экранами (firewall), а также гарантирует надежную доставку данных. При использовании протокола ТСР разные сообщения, относящиеся к одному вызову, либо могут передаваться по одному TCP соединению, либо для каждого запроса и ответа на него может открываться отдельное TCP соединение. По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходимо известить встречную сторону, какого рода информация может приниматься (передаваться), алгоритм ее кодирования и адрес, на который следует передавать информацию. Таким образом, одним из обязательных условий организации связи при помощи протокола SIP является обмен между сторонами данными об их функциональных возможностях. Для этой цели чаще всего используется протокол описания сеансов связи – SDP (Session Description Protocol). Поскольку в течение сеанса связи может производиться его модификация, предусмотрена передача сообщений SIP с новыми описаниями сеанса средствами SDP.
Для передачи речевой информации комитет IETF предлагает использовать протокол RTP, но сам протокол SIP не исключает возможность применения для этих целей других протоколов. В протоколе SIP не реализованы механизмы управления потоками информации и предоставления гарантированного качества обслуживания. Кроме того, протокол SIP не предназначен для передачи пользовательской информации, в его сообщениях может переноситься информация лишь ограниченного объема. При переносе через сеть слишком большого сообщения SIP не исключена его фрагментация на уровне IP, что может повлиять на качество передачи информации. Обычно приложения, обеспечивающие передачу речевой информации, используют сервис транспортного уровня без установления соединений (например, UDP). При этом каждое приложение может обеспечивать формирование полезной нагрузки пакетов специфическим образом, включая необходимые для функционирования поля и данные. Комитетом IETF был разработан протокол транспортировки информации в реальном времени - Realtime Transport Protocol (RTP), который стал базисом практически для всех приложений, связанных с интерактивной передачей речевой и видеоинформации по сети с маршрутизацией пакетов. Характерные для IP-сетей временные задержки и вариация задержки пакетов (джиттер) могут серьезно исказить информацию, чувствительную к задержке, например, речь и видеоинформацию, сделав ее абсолютно непригодной для восприятия. Причем именно вариация задержки пакетов гораздо сильнее влияет на субъективную оценку качества передачи, чем абсолютное значение задержки. Именно протокол RTP позволяет компенсировать негативное влияние джиттера на качество речевой информации. В то же время, он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг, -это осуществляют нижележащие протоколы. Обычно протокол RTP базируется на протоколе UDP и использует его функции, но может работать и поверх других транспортных протоколов. Существует несколько серьезных причин, по которым такой распространенный транспортный протокол, как TCP, плохо подходит для передачи чувствительной к задержкам информации. Во-первых, это алгоритм надежной доставки пакетов. Пока отправитель повторно передаст пропавший пакет, получатель будет ждать, результатом чего может быть недопустимое увеличение задержки. Во-вторых, алгоритм управления при перегрузке в протоколе TCP далеко не оптимален для передачи речи или видеоинформации. При обнаружении потерь пакетов протокол TCP уменьшает размер окна, а затем будет его медленно увеличивать. Однако передача речевой и видеоинформации осуществляется на вполне определенных, фиксированных скоростях, которые нельзя мгновенно уменьшить, не ухудшив качество предоставляемых услуг. Правильной реакцией на перегрузку для информационных потоков этих типов было бы изменение метода кодирования, частоты видеокадров или размера видеоизображения. Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой. Итак, главная особенность RTP - это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой, равной этому среднему значению.
В результате, на практике, гораздо удобнее и проще оказалось использовать более сложное, чем аналоговое, но намного более функциональное IP-соединение для организации связи между постами охраны. Так, например, легко получилось организовать режим конференции, когда к разговору между двумя абонентами подключаются дополнительные абоненты. Был реализован групповой вызов всех или заданной группы постов с центрального аппарата. Ну и конечно, запись переговоров, реализуется что называется, по умолчанию. В общем, опыт применения IP-телефонии в системе безопасности можно считать удачным.
В статье использовались материалы книги «IP-телефония» Б.С. Гольштейн.
Архив публикаций
https://www.sigma-is.ru/articles/Levin- | Дата печати: 21 Nov 2024 19:02:24 |