Подключение Asterisk'а по H323 на Gatekeeper РМ Телекома.

[nickolay]

Добрый вечер, уважаемое сообщество. Возникла проблема при регистрации Астериска на Gatekeeper. Что было сделано:
1. Собрал драйвер канала chan_h323.so
2. Собрал asterisk 1.4.42.
3. Настроил в файле h323.conf следущие секции:

[general]
port = 1720
bindaddr = y.y.y.5 ; this SHALL contain a single, valid IP address for this machine
disallow=all
allow=ulaw
allow=alaw
dtmfmode=rfc2833
gatekeeper = 100.100.100.100
AllowGKRouted = yes
context=incoming_did

[qwerty] - указал логин, выданный провайдером
type=h323
port=1720
context=incoming_did
e164=4991234567
secret=654321
prefix=., так же, пробовал prefix=4991234567

Провайдер предоставил мне следующие данные (для примера):
Логин для RAS пользователя qwerty
Пароль 654321
Номер для входящей и исходящей связи 4991234567
Адрес GK 100.100.100.100

После настроек, даю команду module unload chan_h323.so, потом module load chan_h323.so.

Выдают ошибку регистрации на GK. Пробовал на лабораторной мере, с таким же конфигом, ситуация аналогичная.
Пишет ошибку авторизации. На мере создал RAS пользователя с простыми логинами и паролями. Пробовал с SJPhone - работает.
С asterisk - ошибка регистрации и все. С chan_ooh323.so тоже не получается. Завтра попробую chan_oh323.so.
У провайдера, скорее всего Мера или CISCO. Может быть у кого-нибудть есть примеры файлов конфигураций для регистрации на GK.

Спасибо.

[ded]

Для type=h323 не можно указывать port=1720, и уж никакого secret= там нигде нет даже в примерах
[qwerty] - этим он логинится,
type=h323
;port=1720
context=incoming_did
e164=654321 - это алиас, которым он тоже регистрируется
;secret=654321
prefix=. - не принципиально для регистрации

Смотрите дебаг, и всё будет ясно, пусть даже не сразу.

[nickolay]

Так в этом то и проблема, что в дебаге меры он ругается на Secure Denail. Т.е., получается, либо проблема как раз с полем пароля, либо в chan_h323 его передать нельзя, как я понимаю. Потому что sjphone, регистрируется с этими данными нормально.

[ded]

1) Вы уже попробовали с параметрами, указанными выше? Нет такого поля пароля в Н323, я его замаркировал выше, это видно?
2) Вы будете переписываться по проблеме дальше или посмотрите дебаг Н323 на стороне Астериска?

[nickolay]

Добрый день. Спасибо за участие. В итоге, вопрос решился. Действительно, chan_h323 не умеет передавать пароль в канал. Пробовал собрать chan_oh323.so, но видимо, из-за разницы версии gcc и других библиотек, он собираться не хочет. С chan_ooh323.so, так же не хочет работать с GK, если последний имеет пароль. М.б. попробовать YATE, в качестве клиента к GK, а на нем зарегистрировать Asterisk? Хотя такая схема, мне кажется не очень надежной.

[Vlad1983]

YATE, в качестве клиента к GK, а на нем зарегистрировать Asterisk? Хотя такая схема, мне кажется не очень надежной.

YATE в качестве SIP-H323 шлюза работает без проблем несколько лет.

[ded]

nickolay, я открою страшный секрет: в Н.323 нет никаких паролей. Об этом знают все телекоммуникаторы, но молчат (закон - омерта!), а я вот проговорился.
Поэтому все каналы chan_h323.so, chan_ooh323.so умеют регистрироваться как шлюзы в гейткиперах (изучите поля запроса Registration Request (RRQ)) по протоколу RAS.

В итоге, вопрос решился. Действительно, chan_h323 не умеет передавать пароль в канал.

Думаю, что чего-то не умеете просто Вы.
http://www.cisco.com/en/US/docs/ios/12_ ... tgkar.html
http://dvo.sut.ru/libr/skiri/w133gold/2.htm

[Vlad1983]

ни chan_h323.so ни chan_ooh323.so не поддерживают h.235 authentification
http://www.cisco.com/en/US/tech/tk1077/ ... 4a01.shtml

YATE может
http://yate.null.ro/pmwiki/index.php?n=Main.H323chan

[ded]

Я бы всё таки уточнил: не поддерживают H.235 security? То есть передают токены в чистом виде, как там в примере

Код: Выделить всё

value RasMessage ::= registrationRequest : 
  {
   requestSeqNum 29
   protocolIdentifier { 0 0 8 2250 0 3 }
   discoveryComplete FALSE
   callSignalAddress 
   {
   }
   rasAddress 
   {
    ipAddress : 
    {
     ip 'AC100D0F'H
     port 57514
    }
   }
   terminalType 
   {
    mc FALSE
    undefinedNode FALSE
   }
   gatekeeperIdentifier {"ogk1"}
   endpointVendor 
   {
    vendor 
    {
     t35CountryCode 181
     t35Extension 0
     manufacturerCode 18
    }
   }
   timeToLive 60
   tokens

а хотелось в хэшированном?

Код: Выделить всё

{
   
    {
     tokenOID { 1 2 840 113548 10 1 2 1 }
     timeStamp 731208684
     challenge 'F57C3C65B59724B9A45C93F98CCF9E45'H
     random 12
     generalID {"ogw"}
    }
   }
   cryptoTokens 
   {
    cryptoEPPwdHash : 
     {
      alias h323-ID : {"ogw"}
      timeStamp 731208684
      token 
      {
       algorithmOID { 1 2 840 113549 2 5 }
       paramS 
       {
       }
       hash "D7F85666AF3B881ADD876DD61C20D5D9"
      }
     }
    }

Сама регистрация RAS на гейткипере разве не есть аутентификация? Шлюз там не 123 авторизуется.
Вся аутентификация Н.235 описана в документе ITU http://www.itu.int/rec/dologin_pub.asp? ... type=items

6.2
Аутентификация
В процессе аутентификации проверяется, являются ли ответчики в действительности теми, за кого
себя выдают. Аутентификация может совершаться совместно с обменом сертификатами на основе
открытого ключа. Аутентификация может также совершаться посредством обмена, использующего
общий секрет между участвующими объектами. Он может быть статическим паролем или какой-либо
другой априорной информацией.
В данной Рекомендации описывается протокол обмена сертификатами, но не указываются критерии,
по которым они совместно проверяются и принимаются. В основном, сертификаты дают некую
гарантию проверяющему, что предъявляющий сертификат является тем, за кого себя выдает. Смысл,
стоящий за обменом сертификатами, заключается в аутентификации пользователя конечной точки, а
не просто физической конечной точки. Используя цифровые сертификаты, протокол аутентификации
подтверждает, что ответчики владеют частными ключами, соответствующими открытым ключам,
содержащимся в сертификате. Эта аутентификация защищает от атак через посредника, но
автоматически не доказывает, кем являются ответчики. Нормальное ее выполнение требует наличия
неких правил, касающихся остального содержимого сертификатов. Например, если говорить о
сертификатах авторизации, сертификат может содержать идентификацию поставщика услуг наряду с
формой идентификации учетной записи пользователя, назначенной поставщиком услуг.
В инфраструктуре аутентификации данной Рекомендации не назначается содержимого сертификатов
(т. е. не устанавливаются правила, касающиеся сертификатов) свыше того, которое требует протокол
аутентификации. Однако приложения, использующие эту инфраструктуру, могут налагать
требования политики высокого уровня, таких как предоставление сертификата пользователю для
подтверждения. Политика высокого уровня может либо автоматически контролироваться внутри
приложения, либо требовать воздействия человека.
Для аутентификации, не использующей цифровые подписи, в данной Рекомендации предусмотрена
сигнализация, чтобы осуществить различные сценарии запроса/ответа. Этот метод аутентификации
требует предварительной координации связанных объектов, чтобы было возможным получение
общего секрета. Примером этого метода может служить клиент обслуживания службы, основанной
на подписях.

[nickolay]

Добрый день. Да, именно не поддерживают H.235 security. Т.е. когда я пытаюсь зарегистрироваться на своем оборудовании (стоит MVTS для тестов, версия 3.х.х), в ее отладчике появляется именно HASH пароля, а не сам пароль. И РМ телеком пишет, что они не поддерживают H.235 Security и еще не поддерживают кодек g711.