asterisk.ru

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

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

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"
      }
     }
    }

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