Джим Меггелен - Asterisk™ - будущее телефонии Второе издание

Три версии 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-телефоны; обязательно должен использоваться какой-нибудь контроллер.