Пароль для входа

Для пользователей, которые будут работать в приложении Elph, необходимо задать пароль. Данный пароль будет использован также для аутентификации в чате. Учётная запись чата автоматически создаётся сразу после авторизации абонента в Elph-Desktop.

Пароль для авторизации в Elph — это не пароль SIP, он задаётся отдельно.


domain/test.domain/alias/set 1000 test.group 1000@test.domain password parol

Для возможности создания конференций с помощью мобильных elph требуется задать пароль для селекторных совещаний, пример:

domain/test.domain/alias/set 1000 test.group 1000@test.domain teleconference\password parol

Существует возможность задать пароль через web-конфигуратор:

Пароль нужно сообщить пользователю. При авторизации в приложении в качестве логина нужно ввести номер телефона и данный пароль.

Тип терминала — smart

Для работы с приложением тип терминала абонента должен быть smart, пример:

domain/test.domain/alias/set 1000 test.group 1000@test.domain terminal_type smart

Необходимые услуги (ДВО)

Для полноценной работы необходимо, чтобы на номере были активны услуги:

Возможности использования других услуг также доступны при активации.

Включение core_forking

Обязательно включение данной опции, подробнее о её работе можно прочитать ниже.

На уровень интерфейса был добавлен параметр core_forking. Как работает этот параметр, если он выставлен в true?

  • В oct_rr_obcsm делается запрос на SIP-адаптер для получения контактов абонента Б;
  • В oct_rr_forking делаются параллельные вызовы на контакты абонента Б, полученные на шаге выше. Контакт абонента Б, который ответил раньше остальных, будет проключен с абонентом А.

На уровне elph-desktop в SIP-сообщения REGISTER и INVITE в заголовок Contact был добавлен тег +sip.ice. Данный тег служит индикатором того, что удаленная сторона является WebRTC-клиентом.

  • Как факт наличия тега +sip.ice в SIP-сообщении INVITE используется в SSW? SIP-адаптер формируют занятие на Core с параметром ice_o со значением true. На Core данный параметр сигнализирует о том, что согласование медии (в oct_rr_lander) абонента А нужно парковать с использованием протокола ice https://datatracker.ietf.org/doc/html/rfc8838;
  • Как факт наличия тега +sip.ice в SIP-сообщении REGISTER используется в SSW? SIP-адаптер в ответе на запрос получения контактов абонента Б, помечает контакты как WebRTC. На Core (в oct_rr_forking), при формировании параллельных занятий на контакты абонента Б, в занятии формируется флаг ice_t со значением true. Данный параметр сигнализирует о том, что согласование медии (в oct_rr_lander) контакта абонента Б нужно делать с использованием протокола ice https://datatracker.ietf.org/doc/html/rfc8838.

Параметр core_forking со значением true перебивает параметр ice/enabled.

В случае, если абонент Б использует только WebRTC клиент, то обращаться к SIP-адаптеру для получения единственного WebRTC-контакта пользователя Б не имеет смысла. В данном случае на интерфейсе абоненте Б достаточно будет выставить параметр ice/enabled. Параметр ice/enabled работает только для абонента Б.

Если простыми словами, то в случае core_forking, выставленного в true, администратору SSW больше не нужно задумываться об использовании пользователем телефонного аппарата (ТА) и/или Desktop-клиента (WebRTC-клиента, работающего по протоколу ice https://datatracker.ietf.org/doc/html/rfc8838).

Установите параметр core_forking в значение true:

domain/<DOMAIN>/iface/user-set <SIP> <GROUP> <USER>@<DOMAIN> core_forking true

Включение core_forking одновременно с ice/enabled приведёт к некорректной работе Elph в режиме ассистента.

Пример:

domain/test.domain/iface/user-set sip1 test.group 1000@test.domain core_forking true

На этом настройка абонента закончена. Функционал приложения описан в разделе Клиентская часть Elph.

При обращении пользователя администратор домена/ECSS производит для него вышеприведенные настройки и передает ему параметры подключения и учетные данные для самостоятельной установки.