Asterisk™: будущее телефонии Второе издание

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 с открытым исходным кодом .

MGCP

Протокол контроля медиа-шлюзов (Media Gateway Control Protocol, MGCP) мы также получили от IETF. Хотя MGCP распространен больше, чем кому-то может показаться, он быстро сдает позиции в пользу таких протоколов, как SIP и IAX. Однако Asterisk любит протоколы, поэтому, естественно, имеет базовую поддержку и этого протокола. MGCP описан в RFC 3435[89]. Он был разработан, чтобы максимально упростить конечные устройства (такие, как телефоны) и перенести всю логику и обработку вызовов на плечи медиа-шлюзов и агентов вызова. В отличие от SIP, MGCP использует централизованную модель. MGCP- телефоны не могут напрямую вызывать другие MGCP-телефоны; обязательно должен использоваться какой-нибудь контроллер.

Asterisk поддерживает MGCP посредством модуля chan_mgcp.so, а конечные точки определены в конфигурационном файле mgcp.conf. Поскольку Asterisk предоставляет только базовые сервисы агента вызовов, он не может эмулировать телефон MGCP (чтобы зарегистрироваться на другом MGCP-контроллере как агент пользователя, например). Если у вас под рукой есть несколько MGCP-телефонов, их можно использовать с Asterisk. Если планируется вводить MGCP-телефоны в эксплуатацию в системе Asterisk, помните, что сообщество перешло на более популярные протоколы и поэтому необходимо соответственно планировать затраты на программную поддержку. Если это возможно (например, для телефонов Cisco), следует обновить MGCP-телефоны и перейти на протокол SIP.

Узкоспециализированные протоколы

Наконец давайте рассмотрим два поддерживаемых в Asterisk узкоспециализированных протокола.

Skinny/SCCP

Протокол Skinny Client Control Protocol (SCCP) является узкоспециализированным протоколом для VoIP-оборудования Cisco. Это протокол по умолчанию для конечных точек офисной АТС Cisco Call Manager¹. Asterisk поддерживает Skinny, но при подключении телефонов Cisco к Asterisk, как правило, рекомендуется получить SIP-образы для всех телефонов, поддерживающих SIP, и соединяться через SIP.

UNISTIM