Уровень приложений
Уровень приложений относится к верхнему уровню сетевой архитектуры IMS. На данном уровне расположены серверы приложений AS, предоставляющие доступ как к приложениям IMS, так и приложениям на основе других платформ (таких как OSA и CAMEL).
SCIM (Service Capability Interaction Manager) – обеспечивает управление взаимодействием плоскости приложений и ядра IMS;
SIP AS (SIP Application Server) – сервер приложений, служащий для выполнения услуг, базирующихся на протоколе SIP. Ожидается, что все новые услуги в IMS будут находиться именно в сервере SIP AS;
OSA-SCS (Open Service Access – Service Capability Server) – сервер возможных услуг, который обеспечивает интерфейс к услугам, базирующимся на открытом доступе (OSA).
IM-SSF (IP Multimedia – Service Switching Function) – сервер коммутации услуги, служит для возможности использования в IMS услуг
TAS (Telephony Application Server) – сервер телефонных приложений принимает и обрабатывает сообщения протокола SIP, а также определяет, каким образом должен быть инициирован исходящий вызов.
Список протоколов
В качестве основного протокола был выбран протокол установления соединений (SIP)
Diameter
MEGACO
SIGTRAN
H.248
1.29 Определение значения сообщения по текущему состоянию. Работа с сохранением состояний (не уверен, что это подойдёт)
Сообщения по текущему состоянию - это такие сообщения, которые описывают текущий статус соединения. На примере команды “Netstat” можно проверить текущее состояние соединения.
Состояние Listening говорит о том, что строка состояния отображает информацию о сетевой службе, ожидающей входящие соединения по соответствующему протоколу на адрес и порт, отображаемые в колонке "Локальный адрес ". Состояние ESTABLISHED указывает на активное соединение. В колонке "Состояние" для соединений по протоколу TCP может отображаться текущий этап TCP-сессии определяемый по обработке значений флагов в заголовке TCP - пакета (Syn, Ask, Fin ... ). Возможные состояния:
CLOSE_WAIT - ожидание закрытия соединения.
CLOSED - соединение закрыто.
ESTABLISHED - соединение установлено. LISTENING - ожидается соединение (слушается порт)
TIME_WAIT - превышение времени ответа.
При состоянии Listening - Сервер TCP получает SYN и посылает SYN/ACK. Сервер получил SYN и послал SYN/ACK. Переходит к ожиданию ACK. SYN-RECEIVED Сервер TCP получает ACK. ESTABLISHED (установлено) Получен ACK, открыто соединение.
Сохранение состояний нужно для того, чтобы пользователь мог сохранить свои данные и при следующем использовании воспользоваться сохраненным(регистрация и дальнейший вход по логину и паролю). Если говорить про веб-сервисы, то для сохранения данных пользователя используется база данных (sql), чтобы впоследствии брать оттуда информацию для работы системы.
Также система может использовать отложенные события для того, чтобы составить список событий, которые будут выполняться при событии триггера или перехода в другое состояние.
2.25 Стартовая строка, заголовки и тело сообщения в протоколе sip.
Стартовая строка передает тип сообщения и версию протокола. И для запроса (строка запроса), и для ответа (строка статуса) стартовая строка содержит три элемента, разделенных пробелами.
Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.
Поля заголовков имеют следующий формат: <Заголовок>: <Значение> <Перевод строки>
Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.
Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.
Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны.
В сообщении присутствует опциональное поле Subject, то есть тема сообщения. Некоторые SIP-клиенты могут выводить значение этого поля на экран. Для маршрутизации и идентификации диалога поле не используется и может быть произвольным.
Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки.
Тело сообщения описывает сессию (используя SDP) или содержит непрозрачный текст или бинарные данные, содержащие полезную нагрузку, связанную с сессией (например, с MIME типом или форматом сообщения). Тело сообщения может содержаться как в сообщениях запросов, так и в сообщениях ответов.