Некоторые особенности операций классов протокола tcap:

Операции класса 1. Подтверждение успешного и неуспешного завершения операции. В случае ошибки протокола может также иметь место НЕПРИЕМ. При вызове операции класса 1, на вызывающей стороне идентификатор операции (i) остается активным до приема “последнего” отклика и далее, не может быть не принят.

Местно, ID может быть освобожден пользователем ТС. ID также может быть освобожден при таймауте вызова. Это указывается на рис.1

При операции класса 2 докладывается только об ошибках. В случае ошибки протокола может иметь место неприем. При вызове операции класса 2 идентификатор вызова на вызывающей стороне сохраняется активным до приема отклика и не может быть далее не принят или до события отмены таймаута или ситуации завершения. (Рис.2)

При операциях класса 3 докладывается только об успехе. В случае ошибки протокола может иметь место неприем. При вызове операции класса 3 на вызывающей стороне идентификатор вызова сохраняется активным до приема отклика и не может более быть не принятым или до отклика или ситуации завершения. (Рис.3)

В случае операции класса 4 идентификатор вызова сохраняется на вызывающей стороне активным до приема компоненты Reject или до событий отмены таймаута или ситуации завершения.

Note 1: В этих ситуациях ТС пользователь информируется и переход осуществляется, когда инициируется передача reject.

Note 2: Эти ситуации являются аномальными.

Note 3: Когда принимается примитив, указывающий на связанный вызов, проверяется существование конечного автомата i, чтобы гарантировать нахождение в состоянии “operation sent”, но на состояние конечного автомата влияния не оказывается.

Примечание 1 (Note 1) Это аномальные ситуации. Так как в данном случае должна поступать информация только об ошибке.

Примечание 2 (Note 2) В данных ситуациях ТС пользователь информируется. Переход осуществляется, когда инициируется передача «reject».

Примечание 3. (Note 3) Ситуация аналогична предыдущей, рассмотренной в примечании 2.

Управление диалогом посредством тс примитивов

Примитивы запросов TC-UNI, TC-BEGIN, TC-CONTINUE и TC-END используются пользователем ТС для управления передачей компонент.

Определенные примитивы запроса управления диалогом ТС (пользователей) могут также обуславливать построение APDU, в случае, если контекстно-зависимый параметр приложения включен в примитив запроса TC-BEGIN.

Сопоставление примитивов управления диалогом с прикладными блоками данных APDU приводится ниже.

ТС примитивы (запросы)	APDU управления диалогом
TC-UNI	Диалог UNI (AUDT)
TC-BEGIN	Запрос диалога (AARQ)
TC-CONTINUE	Отклик диалога (AARE (принято)), (прим.1)
TC-END	Отклик диалога (AARE (принято)), (прим.2)
TC-U-ABORT	Прерывание диалога (ABRT) Отклик диалога (AARE (не принято)), (прим.3)
Примечания: Это применимо только для первого примитива в обратном направлении TC-CONTINUE; Это применимо только для примитива запроса TC-END, введенного в отклик на примитив индикации TC-BEGIN; Это применимо только перед установлением диалога (т.е., перед первым сообщением CONTINUE в обратном направлении) и только в случае, если параметр “причина прекращения” в примитиве запроса TC-U-ABORT установлен в “контекстно-зависимое название не поддерживается”

PDU управления диалогом передаются в диалоговой части сообщения ТС. Диалоговая часть, если она присутствует, связывается с компонентной частью и переносится к подуровню транзакций как пользовательские данные, соответствующие примитиву услуг TR.

Компоненты в сообщении доставляются к удаленному пользователю ТС в порядке, аналогичному порядку приема от местного ТС пользователя на исходящей стороне компонентного подуровня. Соответствующие указательные примитивы используются компонентным подуровнем для информирования ТС пользователя на приемном окончании о состоянии диалога.

ТС пользователь использует примитив запроса управления диалогом (TC-UNI, TC-BEGIN, TC-CONTINUE или TC-END) для переключения передачи всех ранее переданных компонент с аналогичным идентификатором диалога, исключая примитивы TC-U-ABORT, которые обуславливают удаление из системы компонент, находящихся на ожидании. Примитивы управления диалогом подуровня компонент, в свою очередь, переключают соответствующий запрос услуги к подуровню транзакций. Сопоставление компонент соответствующего подуровня с примитивами управления транзакциями на подуровне транзакций, представлено ниже:

Примитив ТС	Примитив TR
TC-UNI	TR-UNI
TC-BEGIN	TR-BEGIN
TC-CONTINUE	TR-CONTINUE
TC-END	TR-END
TC-U-ABORT	TR-U-ABORT
TC-P-ABORT	TR-P-ABORT