Вопросы безопасности
Для аутентификации пользователя SIP применяет систему запрос/ответ. Исходное сообщение INVITE посылается на прокси-сервер, с которым желает установить соединение конечное устройство. Прокси возвращает сообщение 407 Proxy Authorization Request (запрос авторизации на прокси), содержащее случайный набор символов, который называют временным кодом (nonce). Этот временный код вместе с паролем используется для формирования хеша MD5, который передается в следующем сообщении INVITE. Если хеш MD5 соответствует хешу, сформированному прокси, клиент проходит аутентификацию. DoS-атаки (Denial of Service - отказ в обслуживании) - наверное, самый распространенный тип атак при связи по протоколам VoIP. DoS- атакой может считаться поступление на прокси-сервер большого количества недействительных запросов INVITE с целью вызвать перегрузку системы. Эти атаки относительно просто реализовать, и они мгновенно отражаются на пользователях системы. SIP располагает несколькими методами минимизации эффектов от DoS-атак, но предотвратить их полностью невозможно.
SIP реализует схему, которая гарантирует, что для установления связи между вызывающим абонентом и доменом вызываемого абонента используется безопасный транспортный механизм с шифрованием (а именно Transport Layer Security, или TLS). Кроме того, защищенный запрос посылается в конечное устройство согласно локальным политикам безопасности сети. Обратите внимание, что шифрование речевых данных (то есть потока RTP) не входит в функции SIP и должно реализовываться отдельно.
Больше информации относительно вопросов безопасности в SIP, включая похищение учетных данных, подмену сервера и обрыв сеанса, можно найти в разделе 26 документации SIP RFC 3261.
SIP и NAT
Наверное, самым большим техническим препятствием, которое должен преодолеть SIP, является проведение транзакции через сети, использующие технологию NAT. Поскольку SIP инкапсулирует адресную информацию в своих порциях данных и NAT выполняется на более низком сетевом уровне, автоматической корректировки адресной информации не происходит. Таким образом, медиа-потоки не будут располагать правильной адресной информацией, которая необходима для завершения установления соединения при использовании NAT. Кроме того, межсетевые экраны, обычно интегрированные с NAT, не будут рассматривать поступающий медиа-поток как часть SIP-тран- закции и блокируют соединение. Более новые межсетевые экраны и пограничные контроллеры сеансов (Session Border Controllers) поддерживают SIP, но это по-прежнему считается недостатком данного протокола и является источником бесконечных неприятностей для сетевых специалистов, которым приходится соединяться с конечными точками, работающими по SIP-протоколу, используя существующую сетевую инфраструктуру.
H.323
Этот протокол, рекомендованный Международным союзом телекоммуникаций (МСТ), изначально был разработан для обеспечения транспортного механизма для видеоконференц-связи по IP-протоколу. Он стал стандартом для оборудования видеоконференц-связи, работающего по IP-протоколу, и также некоторое время пользовался популярностью как VoIP-протокол. Хотя еще ведутся жаркие дебаты по поводу того, какой из протоколов, SIP или H.323 (или IAX), будет доминировать в мире VoIP-протоколов, Asterisk почти отказалась от H.323 в пользу IAX и SIP. H.323 не завоевал особой популярности среди пользователей и компаний, хотя по-прежнему является, наверное, самым широко используемым VoIP-протоколом среди поставщиков услуг связи.
Три версии H.323, поддерживаемые в Asterisk, обрабатываются модулями chan_h323.so (поставляется с Asterisk), chan_oh323.so (доступен как бесплатное дополнение) и chan_ooh323.so (поставляется в пакете asterisk-addons).
Скорее всего, вы использовали H.323, даже не подозревая об этом: клиент NetMeeting от компании Microsoft является, наверное, наиболее популярным Н.323-клиентом.
История
H.323 был разработан МСТ в мае 1996 как средство передачи голоса, видео, данных и факсов по IP-сетям с возможностью подключения к PSTN. С тех пор H.323 пережил несколько версий и дополнений (которые вносят дополнительную функциональность в протокол), что позволяет использовать его как в простых сетях, предназначенных исключительно для VoIP, так и в сетях с более развитой топологией.
Будущее
Будущее H.323 является предметом споров. Если брать за показатель его использование, будущее H.323 не слишком радужное, потому что в этой связи он упоминается редко (несомненно, не так часто, как SIP). H.323 часто называют техническим соперником SIP, но, как показывают примеры других технологий, заявления такого рода редко являются решающим фактором для достижения успеха. Один из аспектов, негативно влияющих на популярность H.323, - его сложность, хотя многие отмечают, что изначально простой SIP начинает страдать тем же недугом.
H.323, безусловно, по-прежнему обслуживает основную массу мирового VoIP-трафика, но, по мере того как снижается зависимость людей от традиционных поставщиков услуг связи, будущее H.323 становится все менее предсказуемым. Хотя H.323, вероятно, и не будет предпочтительным протоколом для новых реализаций, можно с уверенностью ожидать, что нам еще некоторое время придется решать вопросы совместимости с H.323.
Вопросы безопасности
H.323 - относительно защищенный протокол и не требует особых мер обеспечения безопасности, кроме тех, которые обычно применяются при любом обмене информацией по сети Интернет. Поскольку H.323 использует для передачи медиа-данных RTP-протокол, он не поддерживает шифрованные медиа-потоки. Использование VPN или другого шифрованного канала между конечными точками является самым распространенным способом обеспечения безопасности передачи медиа-данных. Конечно, недостатком здесь является необходимость установления этих безопасных каналов между конечными точками, что может быть не всегда удобным (или даже возможным). По мере того как VoIP все чаще используется для связи с финансовыми учреждениями, такими как банки, скорее всего, нам понадобятся расширения для наиболее популярных протоколов VoIP, обеспечивающие поддержку методов устойчивого шифрования.
H.323 и NAT
Стандарт H.323 использует RTP-протокол IETF для переноса речевых данных между конечными точками. Поэтому в сетях с использованием NAT протоколу H.323 свойственны те же проблемы, что и SIP. Самый простой способ - переадресация соответствующих портов через NAT- устройство на внутреннего клиента.
Для получения вызовов всегда придется переадресовывать TCP-порт 1720 на клиента. Кроме того, понадобится переадресовывать UDP- порты для медиа-данных, передаваемых по протоколу RTP, и управляющих потоков RTCP (необходимый диапазон портов указан в руководстве пользователя к устройству). Более старые клиенты, такие как NetMeeting от Microsoft, также потребуют переадресации TCP-портов для туннелирования H.245 (опять же, диапазон используемых портов можно найти в руководстве пользователя).
Если за устройством NAT имеется большое количество клиентов, понадобится шлюз, работающий в режиме прокси. Шлюз потребует наличия интерфейса для взаимодействия закрытой IP-подсети и открытого Интернета). Тогда клиент H.323 из закрытой IP-подсети зарегистрируется на шлюзе, который будет передавать вызовы от его лица. Заметьте, что любым внешним клиентам, которые пожелают позвонить вам, тоже придется зарегистрироваться на прокси-сервере. В настоящее время Asterisk не может выступать в роли шлюза H.323. Для этого придется использовать отдельное приложение, такое как OpenH323 Gatekeeper с открытым исходным кодом (http://www.gnugk.org).
MGCP
Протокол контроля медиа-шлюзов (Media Gateway Control Protocol, MGCP) мы также получили от IETF. Хотя MGCP распространен больше, чем кому-то может показаться, он быстро сдает позиции в пользу таких протоколов, как SIP и IAX. Однако Asterisk любит протоколы, поэтому, естественно, имеет базовую поддержку и этого протокола. MGCP описан в RFC 3435[89]. Он был разработан, чтобы максимально упростить конечные устройства (такие, как телефоны) и перенести всю логику и обработку вызовов на плечи медиа-шлюзов и агентов вызова. В отличие от SIP, MGCP использует централизованную модель. MGCP- телефоны не могут напрямую вызывать другие MGCP-телефоны; обязательно должен использоваться какой-нибудь контроллер.
