Протокол XIMSS. Часть 2

Сигналы

Клиент должен использовать операцию «bind» для того, чтобы начать получать сигналы, направляемые аутентифицированному пользователю.

Клиент может обслуживать одну или несколько одновременных коммуникационных сессий ("звонков"). Каждый звонок идентифицируется по его атрибуту callLeg. Атрибут callLeg присутствует во всех запросах клиента и сообщениях сервера, относящихся к звонку. Все звонки независимы друг от друга.

Для каждого звонка клиент должен уметь создать один или несколько «медиа-объектов», которые фактически реализуют медиа сессии заданного типа (аудио, видео и т.д.). Описатели медиа данных ("объекты SDP") - это элементы данных (в виде текста или XML), которыми клиент обменивается со своими "медиа-объектами".
Как минимум, с каждым медиа-объектом должны быть возможны следующие операции:

• получить SDP "предложения" от медиа-объекта, а потом передать ему SDP "ответа", который описывает медиа-объект абонента; или

• передать SDP "предложения", описывающим медиа-объект абонента, а потом получить SDP "ответа".

Если перепосылка SDP с "предложением" уже активному медиа-объекту невозможна, то должен быть создан новый объект, и "предложение" должно быть отправлено ему. Если от нового медиа-объекта был успешно получен SDP с "ответом", то старый медиа-объект должен быть уничтожен.

Если получение SDP с "предложением" от уже активного медиа-объекта невозможно, то должен быть создан новый объект, и "предложение" должно быть получено от него. Когда SDP "ответа" получен и передан новому медиа-объекту, старый медиа-объект должен быть уничтожен.

медиа-объект поддерживает "расщепление" (forking), если от него возможно получить единственное SDP "предложение", а потом передать ему несколько SDP "ответов", установив таким образом несколько коммуникационных каналов.

Большинство описанных в этом разделе сообщений и запросов может содержать SDP в виде объекта XML.
Описатель SDP может быть передан в виде представления XML или как элемент XML sdpText с данными SDP в оригинальном текстовом формате.
Операция signalBind определяет формат, который будет использоваться Сервером (смотрите ниже).

signalBind

Эта операция позволяет текущей сессии XIMSS получать сигналы, направляемые аутентифицированному пользователю.

Атрибуты:clientID

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

mode

если этот атрибут задан и его значение - fixed, Сервер отказывает в выполнении запроса, если у Пользователя уже есть сессии с таким именем;
если атрибут задан и его значение - kill, Сервер закрывает сессию с таким именем (если она есть).
если атрибут не задан или имеет любое другое значение, Сервер создаёт для сессии уникальное имя, если имя в запросе уже занято другой сессией Пользователя;

presence

если этот необязательный атрибут задан и его значением является yes, то клиент начинает получать уведомления Ростера и Статуса Присутствия.

readIM

если этот необязательный атрибут существует и его значением является 1, то сообщения сервера readIM используют "расширенный" формат.

Тело (необязательно):

XML представление дескриптора SDP клиента.
Дескриптор используется для указания возможностей клиента (способность принимать аудио/видео звонки) и для определения конфигураций "дальнего NAT".
Обратите внимание: чтобы определять "дальние NAT" конфигурации, дескриптор SDP должен содержать атрибут ip с IP адресом медиа, используемым клиентом по умолчанию (смотрите ниже).
Элемент XML sdpText может быть использован вместо элемента SDP. Элемент XML sdpText должен быть текстовым элементом, содержащим данные SDP в оригинальном текстовом формате SDP.
При использовании sdpText данные SDP в сообщениях Сервера callIncoming, callProvisioned, callConnected и callUpdatedбудут представляться тоже в виде sdpText.

signalUnbind

После завершения этой операции текущая сессия XIMSS не получает сигналы, направляемые аутентифицированному пользователю.

callKill

Используйте эту операцию, чтобы завершить звонок и освободить все связанные ресурсы.
Если звонок находился в состоянии "calling", то исходящий звонок прекращается.
Если звонок находился в состоянии "alerting", то входящий звонок отвергается.
Если звонок находился в состоянии "connected", то абоненту отправляется запрос на отсоединение.

Атрибуты:callLeg

идентификатор звонка.

После успешного завершения этой операции можно производить новые звонки с таким же идентификатором.

Исходящие звонки начинаются Клиентом с помощью запроса callStart. Клиент должен создать уникальный идентификатор для использования его в качестве значения атрибута callLeg в запросе callStart. Во всех остальных сообщениях и запросах, имеющих отношение к этому звонку, будет использоваться то же значение атрибута callLeg.
Когда начинается исходящий звонок, Сервер может прислать:

• ноль, одно или несколько сообщений callProvisioned

• ноль, одно или несколько сообщений callUpdateRequest

• ноль или одно сообщение callUpdateSolicited

Каждое из этих сообщений содержит атрибутtag, идентифицирующий "ранний диалог" (одно из "звонящих" устройств абонента).
Когда начинается исходящий звонок, Клиент может прислать:

• ноль, один или несколько запросов callUpdate для "ранних диалогов", установленных с помощью сообщений callProvisioned, callUpdateRequest, callUpdateSolicited. Для каждого запроса callUpdate Сервер присылает сообщение callUpdated.

Исходящий звонок переходит в состояние "установлен", когда Сервер присылает сообщениеcallConnected.
Исходящий звонок аварийно прекращается, если Сервер присылает сообщениеcallDisconnected.
Клиент может прекратить исходящий звонок, используя операциюcallKill.

Входящие звонки начинаются с посылкой Клиенту Сервером сообщения callIncoming. Сервер создаёт уникальный идентификатор для использования его в качестве значения атрибута callLeg для сообщения callIncoming. Во всех остальных сообщениях и запросах, имеющих отношение к этому звонку, будет использоваться то же значение атрибута callLeg. Созданное Сервером для входящих звонков значение атрибута callLeg использует префикс inp, поэтому Клиент не должен использовать такой префикс для значений атрибута callLeg в исходящих звонках.
Когда принимается входящий звонок, Сервер может прислать:

• ноль, одно или несколько сообщений callUpdateRequest

Когда принимается входящий звонок, Клиент может послать:

• ноль, один или несколько запросов callProvision. Для каждого запроса callProvision Сервер присылает сообщение callUpdated.

• ноль, один или несколько запросов callUpdate. Для каждого запроса callUpdate Сервер присылает сообщение callUpdated.

Входящий звонок аварийно прекращается (отменяется), если Сервер присылает сообщениеcallDisconnected.
Клиент может прекратить обработку входящего звонка, отвергнув его с помощью запросаcallRejectили перенаправив его с помощью запросаcallRedirect.
Клиент может принять входящий звонок с помощью запросаcallAccept, тем самым переведя его в состояние "установлен".

Когда исходящий вызов соединяется или когда входящий вызов принимается, звонок переходит в состояние "установлен". В установленном звонке медиа данные могут передаваться в обоих направлениях (если только одна из сторон не поставит звонок "на удержание").
Когда звонок установлен, Сервер может прислать:

• ноль, одно или несколько сообщений callUpdateRequest

• ноль, одно или несколько сообщений callUpdateSolicited

Когда звонок установлен, Клиент может прислать:

• ноль, один или несколько запросов callUpdate. Для каждого запроса callUpdate Сервер присылает сообщение callUpdated.

Установленный звонок прекращается, если Сервер присылает сообщениеcallDisconnected.
Клиент может окончить установленный звонок, послав запросcallKill.

callStart

Используйте эту операцию, чтобы начать исходящий звонок.

Атрибуты:callLeg

идентификатор нового звонка. В текущей сессии XIMSS не должно быть других звонков с таким идентификатором.

peer

адрес электронной почты или SIP URI вызываемого абонента.

peerName

необязательная строка: «настоящее имя» абонента.

Тело (необязательно):

Описатель SDP.

Если запрос callStart завершается успешно, то создаётся новый объект звонка и начинается исходящий вызов.
Обратите внимание: клиент должен быть готов обрабатывать относящиеся к новому звонку сообщения Сервера ещё до получения положительного ответа на запрос callStart.
Обратите внимание: если вызов не заканчивается успешно (получено сообщение callDisconnected), то клиенту всё равно необходимо использовать операцию callKill, чтобы освободить ресурсы, связанные с этим звонком и сделать возможным повторное использование идентификатора звонка.

Управление Медиаданными

Вызов с SDP: Клиент создаёт медиа-объект ("немаркированный" объект).
Клиент должен настроить созданный медиа-объект для работы в режиме "только принимать".
Клиент получает от немаркированного медиа-объекта "предложение" SDP и передаёт этот объект SDP с запросом callStart Серверу.
Обратите внимание: чтобы корректно обрабатывать вызовы "за NAT", дескриптор SDP должен содержать атрибут ip с IP адресом медиа, используемым клиентом по умолчанию.

Вызов без SDP: клиент не создаёт медиа-объект. Клиент шлёт запрос callStart без элемента SDP в теле.

По выбору, Клиент должен быть готов к созданию дополнительных медиа-объектов и поддержке "отображения", в котором каждому созданному медиа-объекту соответствует строка тега - значение атрибута tag из полученных от Сервера сообщений callProvisioned и/или callUpdateRequest.

callProvision

Используйте эту операцию, чтобы направить промежуточный отклик на входящий звонок (объект звонка создаётся, когда Сервер присылает сообщение callIncoming). Предварительный ответ на звонок информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке (у него "звонит телефон").

Атрибуты:callLeg

идентификатор входящего звонка.

Тело (необязательно):

Описатель SDP.

При выполнении запроса Клиент получает сообщение callUpdated от Сервера.

Управление Медиаданными

Если Клиенту надо отправить «ранние медиаданные» (КПВ) вызывающей стороне, Клиент использует запрос callProvision с данными SDP. "Ранние медиаданные" могут быть проиграны устройством вызывающей стороны вместо обычных "гудков дозвона".
Для передачи "ранних медиаданных" Клиент должен создать немаркированный медиа-объект.
Клиент должен настроить созданный медиа-объект для работы в режиме "только передавать".

Если сообщение callIncoming содержало SDP:

Этот объект SDP является предложением.
Клиент должен передать это "предложение" SDP немаркированному медиа-объекту.
Затем Клиент должен получить от этого медиа-объекта "ответ" SDP и послать его на Сервер в теле запроса callProvision. После этого Клиент может включить проигрывание "ранних медиаданных" медиа-объектом.

Если сообщение callIncoming не содержало SDP:

Затем Клиент должен получить от немаркированного медиа-объекта "предложение" SDP и послать его на Сервер в теле запроса callProvision.
В полученном Клиентом от Сервера сообщении callUpdated будет содержаться либо "ответ" SDP, либо код ошибки.
Если получен "ответ" SDP, Клиент должен передать его немаркированному медиа-объекту и затем может включить проигрывание "ранних медиаданных".

callRedirect

Используйте эту операцию для того, чтобы перенаправить входящий вызов.

Атрибуты:callLeg

идентификатор входящего звонка.

fork

если этот необязательный атрибут существует и его значением является yes, то звонок направляется на указанные адреса, но всё ещё является активным для этой сессии и может быть принят или отвергнут.

Тело:

один или более элементов XML To. Каждый элемент должен иметь текстовое тело, в котором указывается URI, на который необходимо перенаправить звонок.

Обратите внимание: клиенту всё равно необходимо использовать операцию callKill, чтобы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.

Пример:
Перенаправление входящего вызова inp003 на user1@example.com и user2@example.com.

C:<callRedirect id="A018" callLeg="inp003" > 
    <To>user1@example.com</To><To>user2@example.com</To> 
  </callRedirect> 
S:<response id="A018"/>

Управление Медиаданными

Клиент должен освободить все медиа-объекты, связанные с этим звонком.

callReject

Используйте эту операцию, чтобы отвергнуть входящий вызов. Вы так же можете использовать операцию callKill, но операция callRejectпозволяет вам указать код ошибки.

Атрибуты:callLeg

идентификатор входящего звонка.

signalCode

числовой код (определяемый стандартами SIP), который передаётся в компонент Signal как код ошибки.
Используйте код 486 ("Здесь занято"), чтобы просигнализировать, что это устройство «Занято» (но другие устройства, зарегистрированные на этого пользователя, будут продолжать звонить).
Используйте код 6xx (600 - "Занято везде" или 603 - "Отклонено"), чтобы просигнализировать, что пользователь не хочет принимать этот сигнал ни на каком устройстве (все другие устройства также прекратят звонить).
Если этот параметр не указан, то используется код 603.

Обратите внимание: клиенту всё равно необходимо использовать операцию callKill, чтобы освободить ресурсы, связанные с этим вызовом и сделать возможным повторное использование идентификатора вызова.

Пример:
Отвергаем входящий вызов inp004 с кодом 603 «Declined»:

C:<callReject id="A020" callLeg="inp004" signalCode="603" /> 
S:<response id="A020"/>

Управление Медиаданными

Клиент должен освободить все медиа-объекты, связанные с этим звонком.

callAccept

Используйте эту операцию, чтобы принять входящий звонок.

Атрибуты:callLeg

идентификатор входящего звонка.

Тело (необязательно):

Описатель SDP.

При выполнении запроса Клиент получает сообщение callUpdated от Сервера.

Управление Медиаданными

Клиент должен создать немаркированный медиа-объект, если он не был ещё создан.

Если Клиент уже отправил запрос callProvision с данными SDP:

Запрос callAccept не должен содержать SDP в теле, и сообщение callUpdated не будет содержать SDP.

Если Клиент ещё не отправил запрос callProvision с данными SDP, а сообщение callIncoming содержало SDP:

Этот объект SDP является предложением.
Клиент должен передать это «предложение» SDP немаркированному медиа-объекту.
Затем Клиент должен получить от этого медиа-объекта «ответ» SDP и послать его на Сервер в теле запроса callAccept.
Когда звонок устанавливается, Клиент получает от Сервера сообщение callUpdated без SDP.

Если Клиент ещё не отправил запрос callProvision с данными SDP, и сообщение callIncoming тоже не содержало SDP:

Клиент должен получить от немаркированного медиа-объекта «предложение» SDP и послать его на Сервер в теле запроса callAccept.
Клиент получит от Сервера сообщение callUpdated, которое будет содержать "ответ" SDP.
Клиент должен передать этот "ответ" SDP немаркированному медиа-объекту.

Клиент должен прекратить проигрывание "ранних медиаданных" "немаркированным" медиа-объектом и настроить его для работы в режиме "отправлять и принимать".

callUpdate

Используйте эту операцию, чтобы изменить звонок (изменить SDP дескриптор). Клиенту может понадобиться использовать этот запрос для постановки звонка "на удержания" или возобновления звонка, для изменения количества и типов медиа потоков (например, для добавления видео потока к аудио звонку), для переключения на другой медиа-объект и т.д.

Атрибуты:callLeg

идентификатор звонка.

tag

необязательно: "to-tag" (идентификатор диалога/ветвления) для "раннего диалога"; должен использоваться при изменении параметров исходящего звонка.

Тело (необязательно):

Описатель SDP.

При выполнении запроса Клиент получает сообщение callUpdated от Сервера.
В случае неудачи, сообщение callUpdated содержит атрибуты signalCode и errorText. В случае успеха сообщение callUpdated не содержит этих атрибутов.

Управление Медиаданными

Если Клиенту не требуется изменять дескриптор SDP, запрос callUpdate можно послать без SDP в теле. Сервер пришлёт сообщение callUpdated тоже без SDP.

Для изменения SDP Клиент должен получить от немаркированного медиа-объекта новое "предложение" SDP. Или же, Клиент должен создать новый медиа-объект и получить от него "предложение" SDP. Это "предложение" должно быть отправлено в теле запроса callUpdate.
Если сообщение callUpdated не содержит атрибут errorText, оно содержит "ответ" SDP, и Клиент должен передать его медиа-объекту. Если это - новый медиа-объект, то старый "немаркированный" медиа-объект должен быть удалён, а новый должен стать текущим "немаркированным" медиа-объектом.
В случае неудачи, сообщение callUpdated содержит атрибут errorText. В этом случае немаркированный медиа-объект должен быть возвращён в предыдущее состояние. Если для получения "предложения" SDP был создан новый медиа-объект, то он должен быть удалён.

callTransfer

Используйте эту операцию, чтобы передать присоединённого абонента другому абоненту.

Атрибуты:callLeg

идентификатор звонка.

peer

адрес электронной почты или SIP URI, на которые необходимо передать звонок. Используйте этот атрибут, чтобы начать "несопровождаемый перевод".

otherLeg

идентификатор звонка. Он должен указывать на некоторый другой "звонок" в этой сессии. Оба звонка должны быть в установленном состоянии. Используйте этот атрибут для завершения операции "сопровождаемого перевода". Удалённый абонент звонка "callLeg" соединяется с удалённым абонентом звонка "otherLeg".

Если атрибут otherLeg указан, то атрибут peer игнорируется.

Если операция перевода звонка завершилась успешно, то звонок "callLeg" отсоединяется (клиенту отправляется сообщение callDisconnected). В дополнении к этому, в операции "сопровождаемого перевода" клиент также получает сообщение callDisconnected и для звонка "otherLeg".

Если операция перевода звонка завершилась неудачей, то клиент получает сообщение callOpFailed.

callUpdateAccept

Используйте эту операцию для того, чтобы принять запрос об изменении параметров SDP звонка.

Атрибуты:callLeg

идентификатор звонка.

Тело (необязательно):

Описатель SDP.

Клиент должен отправить такой запрос при получении сообщений callUpdateRequest, callProvisioned и callConnected. Дополнительную информацию смотрите в описании этих сообщений.

callUpdateReject

Используйте эту операцию для того, чтобы отвергнуть запрос об изменении параметров SDP звонка.

Атрибуты:callLeg

идентификатор звонка.

signalCode

числовой код (определяемый стандартами SIP), который передаётся в компонент Signal как код ошибки.
Если этот атрибут отсутствует, то используется код 488 ("Not Acceptable Here").

Тело:

отсутствует

Клиент должен послать такой запрос вместо запроса callUpdateAccept в случаях, когда модификация параметров SDP звонка оказалась невозможной.
Дополнительную информацию смотрите в описании callUpdateAccept.

callSendDTMF

Используйте эту операцию для отправки DTMF сигнала через канал сигнализации.

Атрибуты:callLeg

идентификатор звонка.

Тело:

строка с DTMF кодом, который необходимо отправить (10 для '*', 11 для '#').

Если операция заканчивается успешно, то сервер возвращает сообщение callOpCompleted.

Если операция не заканчивается успешно, то сервер возвращает сообщение callOpFailed.

callSendInfo

Используйте эту операцию для того, чтобы передать абоненту сигнал INFO.

Атрибуты:callLeg

идентификатор звонка.

Тело:

элемент MIME XML:

Атрибуты:type

Content-Type содержимого INFO.

subtype

Подтип содержимого INFO (необязательно).

Тело:

строка с данными содержимого INFO.

Если операция заканчивается успешно, то сервер возвращает сообщение callOpCompleted.

Если операция заканчивается неуспешно, то сервер возвращает сообщение callOpFailed.

makeCall

Используйте эту операцию, чтобы совершить звонок с использованием любого зарегистрированного устройства или клиента. Сервер инициирует вызов аутентифицированному Пользователю ("самовызов"), что приводит к тому, что все зарегистрированные устройства Пользователя начинают звонить. Когда любое устройство отвечает на звонок, то это устройство получает указание совершить звонок на указанный адрес (или телефонный номер).

Атрибуты:peer

адрес электронной почты или SIP URI вызываемого абонента.

callerParams

необязательный атрибут, содержащий параметры SIP URI для «самовызова».

Операция выполняется, как только запускается задача CG/PL, реализующая эту функцию. Асинхронные сообщения makeCallReportприсылаются при изменении статуса задачи. Сразу по выполнении попытки дозвона присылается пустое сообщение makeCallReport.

Сервер может отправлять следующие сообщения с данными:

callDisconnected

Эти асинхронные сообщения с данными отправляются, когда исходящий вызов заканчивается неуспешно, или когда входящий звонок был прерван, или когда установленный звонок отсоединяется:

Атрибуты:callLeg

идентификатор звонка.

signalCode

в этом необязательном атрибуте указывается числовой код ошибки.

errorText

в этом необязательном атрибуте указывается причина разъединения звонка.

Обратите внимание: клиенту всё равно необходимо использовать операцию callKill, чтобы освободить ресурсы, связанные с этим вызовом, и сделать возможным повторное использование идентификатора вызова.

Управление Медиаданными

Клиент должен освободить все медиа-объекты, связанные с этим звонком.

callProvisioned

Эти асинхронные сообщения данных отправляются, когда исходящий вызов находится в процессе обработки (после того, как Сервером был получен запрос callStart):

Атрибуты:callLeg

идентификатор звонка.

callId

строка с Call-ID звонка.

tag

«to-tag» (идентификатор диалога/ответвления) для "раннего диалога".

Тело (необязательно):

Описатель SDP.

В ответ Клиент должен отправить Серверу запрос callUpdateAccept или callUpdateReject.

Управление Медиаданными

Если сообщение callProvisioned не содержало SDP:

если со значением атрибута tag связан медиа-объект или проигрыватель "тона дозвона" (КПВ), Клиент должен игнорировать это сообщение.
Иначе, Клиент должен создать проигрыватель "тона дозвона" (который уведомляет звонящего, что вызываемый абонент информируется о входящем звонке) и связать его со значением атрибута tag.

Если сообщение callProvisioned содержит SDP, и создан медиа-объект, связанный со значением атрибута tag:

Этот объект SDP является предложением.
Клиент должен передать это "предложение" SDP соответствующему (маркированному) медиа-объекту. Затем Клиент должен получить от этого медиа-объекта "ответ" SDP и послать его на Сервер в теле запроса callUpdateAccept.

Если сообщение callProvisioned содержит SDP, а медиа-объекта, связанного со значением атрибута tag, - нет, и запрос callStart был сделан с "предложением" SDP:

Этот объект SDP является ответом.
Клиент должен запомнить этот "ответ" SDP и связать его со значением атрибута tag, заменяя старый SDP, связанный с этим значением атрибута tag.
Если "немаркированный" медиа-объект поддерживает "расщепление" (ветвление вызова), Клиент должен передать этот "ответ" SDP этому медиа-объекту; Клиент должен также убрать объект проигрывателя "тонов дозвона", связанный с этим значением атрибута tag.
Если "немаркированный" медиа-объект не поддерживает "расщепление", Клиент должен создать объект проигрывателя "тонов дозвона" (если его ещё нет) и связать его с этим значением атрибута tag.

Если сообщение callProvisioned содержит SDP, а медиа-объекта, связанного со значением атрибута tag, - нет, и запрос callStart был сделан без "предложения" SDP:

Этот объект SDP является предложением.
Клиент должен создать новый медиа-объект и связать его с этим значением атрибута tag. Если со значением атрибута tag связан медиа-объект или проигрыватель "тона дозвона" (КПВ), Клиент должен удалить его.
Клиент должен передать это "предложение" SDP новому медиа-объекту, получить от него "ответ" SDP и послать его на Сервер в теле запроса callUpdateAccept.

Если Клиент не может обработать сообщение callProvisioned, он должен послать запрос callUpdateReject.

callConnected

Эти асинхронные сообщения данных отправляются, когда исходящий вызов (запущенный запросом callStart) выполняется успешно и звонок устанавливается:

Атрибуты:callLeg

идентификатор звонка.

callId

строка с Call-ID звонка.

peer

адрес абонента, принявшего звонок.

tag

"to-tag" (идентификатор диалога/ответвления) для "установленного диалога".

Тело (необязательно):

Описатель SDP.

В ответ Клиент должен отправить Серверу запрос callUpdateAccept или callUpdateReject.

Управление Медиаданными

Если создан медиа-объект, связанный со значением атрибута tag, а сообщение callConnected не содержит SDP:

Клиент должен удалить все другие медиа-объекты и проигрыватели "тонов дозвона". Выбранный медиа-объект становится "немаркированным".

Если создан медиа-объект, связанный со значением атрибута tag, а сообщение callConnected содержит SDP:

Этот объект SDP является предложением.
Клиент должен передать это "предложение" SDP выбранному медиа-объекту. Затем Клиент должен получить от этого медиа-объекта "ответ" SDP и послать его на Сервер в теле запроса callUpdateAccept.
Клиент должен удалить все другие медиа-объекты и проигрыватели "тонов дозвона". Выбранный медиа-объект становится "немаркированным".

Если связанного со значением атрибута tag медиа-объекта нет, запрос callStart содержал "предложение" SDP, и сообщение callConnectedсодержит SDP:

Этот объект SDP является ответом.
Клиент должен передать этот "ответ" SDP немаркированному медиа-объекту. Если медиа-объект поддерживает "расщепление" (ветвление вызова) и ему был передан некоторый "ответ" SDP, Клиент должен отключить в этом медиа-объекте все другие коммуникации.
Клиент должен удалить все другие маркированные медиа-объекты и проигрыватели "тонов дозвона".

Если связанного со значением атрибута tag медиа-объекта нет, запрос callStart содержал "предложение" SDP, а сообщение callConnectedне содержит SDP:

Этот объект SDP является ответом.
Если медиа-объект поддерживает "расщепление" (ветвление вызова), то ему был передан некоторый "ответ" SDP, связанный с этим значением атрибута tag. Клиент должен отключить в этом медиа-объекте все другие коммуникации.
Если медиа-объект не поддерживает "расщепление" (ветвление вызова), то ему был передан некоторый "ответ" SDP, полученный с сообщением callProvisioned и связанный с этим значением атрибута tag, - его надо запомнить. Клиент должен передать этот запомненный "ответ" SDP немаркированному медиа-объекту.
Клиент должен удалить все другие маркированные медиа-объекты и проигрыватели "тонов дозвона".

Если связанного со значением атрибута tag медиа-объекта нет, запрос callStart не содержал "предложение" SDP:

Сообщение callConnected должно содержать объект SDP, и этот объект SDP является предложением.
Клиент должен создать новый медиа-объект и передать это "предложение" SDP этому медиа-объекту. Затем Клиент должен получить от этого медиа-объекта "ответ" SDP и послать его на Сервер в теле запроса callUpdateAccept.
Клиент должен удалить все другие медиа-объекты и проигрыватели "тонов дозвона". Созданный медиа-объект становится "немаркированным".

"Немаркированный" медиа-объект (единственный оставшийся) должен быть настроен для работы в режиме "отправлять и получать".

callIncoming

Эти сообщения отправляются при получении новых входящих звонков (для получения входящих звонков вам необходимо использовать операцию signalBind):

Атрибуты:callLeg

идентификатор звонка. Сервер самостоятельно формирует эти идентификаторы.

peer

адрес электронной почты удалённого абонента.

peerName

необязательно; настоящее имя удалённого абонента.

callId

строка с Call-ID звонка.

transferredBy

необязательно: адрес участника, который перевёл этот звонок.

Тело (необязательно):

Описатель SDP.

Управление Медиаданными

Клиент может создать "немаркированный" медиа-объект немедленно или создать его перед посылкой запросов callProvision или callAccept.

Если сообщение callIncoming содержало SDP:

Этот объект SDP является предложением.
Клиент должен передать это "предложение" SDP немаркированному медиа-объекту.

callUpdateRequest

Эти асинхронные сообщения присылаются, когда удалённый абонент пытается изменить параметры звонка (например, SDP).

Атрибуты:callLeg

идентификатор звонка.

tag

"to-tag" (идентификатор диалога/ответвления) для "раннего диалога".

Тело (необязательно):

Описатель SDP.

В ответ Клиент должен отправить Серверу запрос callUpdateAccept или callUpdateReject.

Управление Медиаданными

Если сообщение callUpdateRequest не содержало SDP, то Клиент может его игнорировать.Если сообщение callUpdateRequest содержало SDP:

Этот объект SDP является предложением.
Если звонок исходящий, то Клиент должен удалить все проигрыватели "тонов дозвона", связанные с этой меткой.
Клиент должен найти медиа-объект, связанный с этим значением атрибута tag (или создать новый медиа-объект, если связанный найти не удалось).
Если атрибут tag не был задан, то должен использоваться "немаркированный" медиа-объект.
"Предложение" SDP из сообщения callUpdateRequest должно быть передано выбранному медиа-объекту.
Клиент должен получить от этого медиа-объекта "ответ" SDP и послать его на Сервер в теле запроса callUpdateAccept.
Если Клиент не может принять новое "предложение" SDP, он должен проинформировать об этом Сервер, послав ему запрос callUpdateReject.

callUpdated

Эти асинхронные сообщения отправляются, когда существующий звонок изменяется (помещается на удержание, переключается на другого удалённого участника и т.д.).

Атрибуты:callLeg

идентификатор звонка.

peer

необязательно; адрес электронной почты удалённого участника. Он присылается, когда звонок был переведён.

peerName

необязательно; настоящее имя удалённого абонента.

signalCode

в этом необязательном атрибуте указывается числовой код ошибки.

errorText

необязательно; текст сообщения об ошибке.

Тело (необязательно):

Описатель SDP.

Сообщение присылается в ответ на запросы callUpdate, callProvision, callAccept. Дополнительную информацию смотрите в описании этих сообщений.
В случае неудачи, в сообщении содержатся атрибуты signalCode и errorText.
В случае успеха, атрибуты signalCode и errorText отсутствуют, а Описатель SDP может быть включён в тело сообщения.

callUpdateSolicited

Эти асинхронные сообщения присылаются, когда удалённый абонент пытается изменить параметры звонка (например, SDP), но сам ищет предложения.

Атрибуты:callLeg

идентификатор звонка.

tag

"to-tag" (идентификатор диалога/ответвления) для "раннего диалога".

Тело (необязательно):

Описатель SDP.

Сервер присылает такие сообщения только для установленных звонков или для исходящих звонков в процессе установления.

Управление Медиаданными

Клиент должен выполнить запрос callUpdate с новым "предложением" SDP.

Если Клиент не может выполнить запрос callUpdate (например, не может создать новый медиа-объект), он должен послать запрос callUpdateReject.

Для исходящего звонка в процессе установления Клиент должен создать "маркированный" медиа-объект, получить от него "предложение" SDP и послать его с запросом callUpdate.

callOpCompleted

Эти сообщения отправляются, если операции, совершаемые во время звонка (такие как callUpdate, callSendDTMF, callSendInfo) были выполнены.

Атрибуты:callLeg

идентификатор звонка.

callOpFailed

Эти сообщения отправляются, если операции, совершаемые во время звонка (такие как callUpdate, callSendDTMF, callSendInfo) не были выполнены.

Атрибуты:callLeg

идентификатор звонка.

signalCode

числовой код ошибки.

errorText

текст сообщения об ошибке.

callDTMF

Эти сообщения отправляются при получении сигнала DTMF через канал сигнализации.

Атрибуты:callLeg

идентификатор звонка.

Тело:

Строка с полученным числовым DTMF кодом.

callTransferred

Эти асинхронные сообщения присылаются, когда удалённый абонент перевёл звонок на другого абонента.

Атрибуты:callLeg

идентификатор звонка.

peer

адрес нового абонента.

peerName

необязательно; настоящее имя нового абонента.

callId

строка с Call-ID звонка; при переводе звонка это параметр обычно меняется.

mode

код сценария перевода звонка (информация для отладки).

tag

идентификатор конечного устройства (информация для отладки).

Тело:

Пустое.

callInfo

Эти асинхронные сообщения присылаются при получении запросов INFO:

Атрибуты:callLeg

идентификатор звонка.

Тело:

аналогично операции callSendInfo.

makeCallReport

Эти асинхронные сообщения данных присылаются при использовании операции makeCall.

Тело:

Строка, содержащая текущей статус операции. Сообщение содержит пустое тело при завершении операции.

Пример Входящий-01. Сессия входящего звонка с начальным SDP. Клиент не шлёт вызывающей стороне никаких "тонов дозвона".

Клиент получает сообщение callIncoming с созданным Сервером атрибутом callLeg. 
S:<callIncoming id="A001" callLeg="inp01" peer="user@domain" >SDP:X(offer)</callIncoming> 

Клиент начинает подзывать пользователя (Клиент начинает "звонить"). 
Клиент информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке: 
C:<callProvision id=«A001» callLeg=«inp01»/> 
S:<response id=«A001»/> 

Пользователь решает принять звонок этим Клиентом. 
Клиент создаёт немаркированный медиа-объект A, и передаёт ему полученный SDP:X(offer) ("предложение" SDP) . 
Клиент получает "ответ" SDP от медиа-объекта A, и шлёт его на Сервер, принимая звонок: 
C:<callAccept id="A002" callLeg="inp01">SDP:A(answer)</callAccept> 
S:<response id="A002"/> 
Сервер присылает сообщение callUpdated: 
S:<callUpdated callLeg="inp01"/> 
Обратите внимание: сообщение callUpdated прийти до сообщения response для запроса callAccept. 

Клиент прекращает "звонить". 
Звонок установлен, медиа-объект A настроен для работы в режиме "отправлять и получать", начался обмен медиаданными. 

S:<callDisconnected callLeg="inp01" /> 
Звонок завершается, Клиент удаляет "немаркированный" медиа-объект A. 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id="A003" callLeg="inp01"/> 
S:<response id="A003"/>

Пример Входящий-02. Сессия входящего звонка без начального SDP. Клиент не шлёт вызывающей стороне никаких "тонов дозвона".

Клиент получает сообщение callIncoming с созданным Сервером атрибутом callLeg. 
S:<callIncoming id="A001" callLeg="inp01" peer="user@domain" /> 

Клиент начинает подзывать пользователя (Клиент начинает "звонить"). 
Клиент информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке: 
C:<callProvision id=«A001» callLeg=«inp01»/> 
S:<response id=«A001»/> 

Пользователь решает принять звонок этим Клиентом. 
Клиент создаёт немаркированный медиа-объект A, и получает от него «предложение» SDP: SDP:A(offer). 
Клиент отправляет это SDP на Сервер, принимая звонок: 
C:<callAccept id=«A002» callLeg=«inp01»>SDP:A(offer)</callAccept> 
S:<response id=«A002»/> 
Сервер присылает сообщение callUpdated с «ответом» SDP: 
S:<callUpdated callLeg=«inp01»/>SDP:X(answer)</callUpdated> 
Обратите внимание: сообщение callUpdated прийти до сообщения response для запроса callAccept. 

Клиент прекращает «звонить». 
Клиент передаёт полученный «ответ» SDP медиа-объекту A. 
Звонок установлен, медиа-объект A настроен для работы в режиме «отправлять и получать», начался обмен медиаданными. 

S:<callDisconnected callLeg=«inp01» /> 
Звонок завершается, Клиент удаляет «немаркированный» медиа-объект A. 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id=«A003» callLeg=«inp01»/> 
S:<response id=«A003»/>

Пример Входящий-03. Сессия входящего звонка с начальным SDP. Клиент не шлёт вызывающей стороне никаких "тонов дозвона". Попытка дозвона остановлена вызывающей стороной (или звонок был принят другим клиентом).

Клиент получает сообщение callIncoming с созданным Сервером атрибутом callLeg. 
S:<callIncoming id=«A001» callLeg=«inp01» peer=«user@domain» >SDP:X(offer)</callIncoming> 

Клиент начинает подзывать пользователя (Клиент начинает "звонить"). 
Клиент информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке: 
C:<callProvision id=«A001» callLeg=«inp01»/> 
S:<response id=«A001»/> 

Входящий звонок отменяется: 
S:<callDisconnected callLeg=«inp01» /> 
Звонок прекращается (Для этого клиента он - "пропущен"), Клиент прекращает «звонить». 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id=«A002» callLeg=«inp01»/> 
S:<response id=«A002»/>

Пример Входящий-04. Сессия входящего звонка с начальным SDP. Клиент не шлёт вызывающей стороне никаких "тонов дозвона". Звонок отвергнут пользователем.

Клиент получает сообщение callIncoming с созданным Сервером атрибутом callLeg. 
S:<callIncoming id=«A001» callLeg=«inp01» peer=«user@domain» >SDP:X(offer)</callIncoming> 

Клиент начинает подзывать пользователя (Клиент начинает "звонить"). 
Клиент информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке: 
C:<callProvision id=«A001» callLeg=«inp01»/> 
S:<response id=«A001»/> 

Входящий звонок отвергается: 
S:<callReject id=«A002» callLeg=«inp01» signalCode=«603» /> 
S:<response id=«A002»/> 
Звонок завершается, Клиент прекращает «звонить». 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id=«A003» callLeg=«inp01»/> 
S:<response id=«A003»/>

Пример Входящий-05. Сессия входящего звонка с начальным SDP. Клиент не шлёт вызывающей стороне никаких "тонов дозвона". Приложение перенаправляет звонок на приложение voicemail.

Клиент получает сообщение callIncoming с созданным Сервером атрибутом callLeg. 
S:<callIncoming id=«A001» callLeg=«inp01» peer=«user@domain» >SDP:X(offer)</callIncoming> 

Клиент начинает подзывать пользователя (Клиент начинает "звонить"). 
Клиент информирует вызывающую сторону, что вызываемый абонент проинформирован о входящем звонке: 
C:<callProvision id=«A001» callLeg=«inp01»/> 
S:<response id=«A001»/> 

Входящий звонок перенаправляется: 
S:<callRedirect id=«A002» callLeg=«inp01»><To>#voicemail</To></callRedirect> 
S:<response id=«A002»/> 
Звонок завершается, Клиент прекращает «звонить». 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id=«A003» callLeg=«inp01»/> 
S:<response id=«A003»/>

Пример Исходящий-01. Сессия исходящего звонка с начальным SDP.

Клиент создаёт медиа-объект A и использует его как «немаркированный» медиа-объект для нового звонка. 
Клиент получает «предложение» SDP от этого объекта: SDP:A(offer) 
C:<callStart id=«A001» callLeg=«c1» peer=«user@domain»>SDP:A(offer)</callStart> 
S:<response id=«A001»/> 

S:<callProvisioned callLeg=«c1» tag=«device1»/> 
Клиент создаёт проигрыватель «тонов дозвона», чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id=«A002» callLeg=«c1»/> 
S:<response id=«A002»/> 

S:<callProvisioned callLeg=«c1» tag=«device1»/> 
У Клиента уже есть проигрыватель «тонов дозвона» для этого устройства (тега), поэтому дополнительные операции с медиа не нужны. 
C:<callUpdateAccept id=«A003» callLeg=«c1»/> 
S:<response id=«A003»/> 

S:<callConnected callLeg=«c1» tag=«device1»>SDP:X(answer)</callConnected> 
Клиент удаляет проигрыватель «тонов дозвона» и передаёт полученный дескриптор SDP:X(answer) (это - "ответ" SDP) "немаркированному" медиа-объекту A. Звонок установился, медиа-объект A настроен работать в режиме "передавать и принимать", начался обмен медиа данными. 
C:<callUpdateAccept id="A004" callLeg="c1"/> 
S:<response id="A004"/> 

S:<callDisconnected callLeg="c1" /> 
Звонок завершается, Клиент удаляет "немаркированный" медиа-объект A. 

Клиент также освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id="A005" callLeg="c1"/> 
S:<response id="A005"/>

Пример Исходящий-02. Сессия исходящего звонка с начальным SDP, несколько устройств на принимающей стороне. медиа-объект не поддерживает "расщепление". Клиент не поддерживает расширенные сообщения Сервера для исходящих звонков.

Клиент создаёт медиа-объект A и использует его как "немаркированный" медиа-объект для нового звонка. 
Клиент получает "предложение" SDP от этого объекта: SDP:A(offer) 
C:<callStart id="A001" callLeg="c1" peer="user@domain">SDP:A(offer)</callStart> 
S:<response id="A001"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
Клиент создаёт проигрыватель "тонов дозвона", чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id="A002" callLeg="c1"/> 
S:<response id="A002"/> 

S:<callProvisioned callLeg="c1" tag="device2"/> 
Клиент создаёт ещё один проигрыватель "тонов дозвона", чтобы пользователь знал о факте дозвона. Оба проигрывателя издают тоны дозвона (КПВ).
C:<callUpdateAccept id="A003" callLeg="c1"/> 
S:<response id="A003"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer1)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer1) и связывает его с тегом "device1". Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A004" callLeg="c1"/> 
S:<response id="A004"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer2)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer2) и связывает его с тегом "device1". Он заменяет полученный ранее с этим тегом SDP:X(answer1). Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A005" callLeg="c1"/> 
S:<response id="A005"/> 

S:<callUpdateRequest callLeg="c1" tag="device3">SDP:Y(offer)</callUpdateRequest> 
C:<callUpdateReject id="A006" callLeg="c1" errorText="not implemented" /> 
S:<response id="A006"/> 

S:<callUpdateSolicited callLeg="c1" tag="device4" /> 
C:<callUpdateReject id="A006" callLeg="c1" errorText="not implemented" /> 
S:<response id="A006"/> 

S:<callConnected callLeg="c1" tag="device1">SDP:X(answer3)</callConnected> 
Клиент удаляет все проигрыватели "тонов дозвона" и передаёт полученный медиа дескриптор SDP:X(answer3) (это - "ответ" SDP) "немаркированному" медиа-объекту A. 

Сообщение <callConnected/> вообще могло прийти без SDP: 
S:<callConnected callLeg="c1" tag="device1"/> 
Клиент удаляет все проигрыватели "тонов дозвона" и передаёт сохранённый медиа дескриптор SDP:X(answer2), поскольку он был последним полученным для тега "device1". Клиент передаёт медиа дескриптор SDP:X(answer2) (это - "ответ" SDP) "немаркированному" медиа-объекту A. 

Звонок установился, медиа-объект A настроен работать в режиме "передавать и принимать", начался обмен медиа данными. 
C:<callUpdateAccept id="A006" callLeg="c1"/> 
S:<response id="A006"/> 

Пользователь решает завершить звонок, Клиент завершает звонок и освобождает связанные с ним ресурсы Сервера: 
S:<callKill id="A007" callLeg="c1" /> 
S:<response id="A007"/> 
Звонок заканчивается, Клиент удаляет "немаркированный" медиа-объект A.

Пример Исходящий-03. Сессия исходящего звонка с начальным SDP, несколько устройств на принимающей стороне. медиа-объект не поддерживает "расщепление", дополнительные сообщения от вызываемых устройств.

Клиент создаёт медиа-объект A и использует его как "немаркированный" медиа-объект для нового звонка. 
Клиент получает "предложение" SDP от этого объекта: SDP:A(offer) 
C:<callStart id="A001" callLeg="c1" peer="user@domain">SDP:A(offer)</callStart> 
S:<response id="A001"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
Клиент создаёт проигрыватель "тонов дозвона", чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id="A002" callLeg="c1"/> 
S:<response id="A002"/> 

S:<callProvisioned callLeg="c1" tag="device2"/> 
Клиент создаёт ещё один проигрыватель "тонов дозвона", чтобы пользователь знал о факте дозвона. Оба проигрывателя издают тоны дозвона (КПВ).
C:<callUpdateAccept id="A003" callLeg="c1"/> 
S:<response id="A003"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer1)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer1) и связывает его с тегом "device1". Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A004" callLeg="c1"/> 
S:<response id="A004"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer2)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer2) и связывает его с тегом "device1". Он заменяет полученный ранее с этим тегом SDP:X(answer1). Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A005" callLeg="c1"/> 
S:<response id="A005"/> 

S:<callUpdateRequest callLeg="c1" tag="device2">SDP:Y(offer)</callUpdateRequest> 
Клиент удаляет проигрыватель "тонов дозвона", связанный с тегом "device2". 
Клиент создаёт новый "маркированный" медиа-объект B и связывает его с тегом "device2". медиа-объект B настроен для работы в режиме "только принимать". 
Клиент передаёт полученный SDP:Y(offer) в качестве "предложения" SDP медиа-объекту B. 
Клиент получает "ответ" SDP от этого медиа-объекта: SDP:B(answer), и передаёт его серверу: 
C:<callUpdateAccept id="A006" callLeg="c1">SDP:B(answer)</callUpdateAccept> 
S:<response id="A006"/> 

S:<callConnected callLeg="c1" tag="device1">SDP:X(answer3)</callConnected> 
Клиент удаляет проигрыватели "тонов дозвона", удаляет "маркированный" медиа-объект B и передаёт полученный дескриптор SDP:X(answer3) (это - "ответ" SDP) своему "немаркированному" медиа-объекту A. 

Сообщение <callConnected/> вообще могло прийти без SDP: 
S:<callConnected callLeg="c1" tag="device1"/> 
Клиент удаляет проигрыватели "тонов дозвона", удаляет "маркированный" медиа-объект B и использует дескриптор SDP:X(answer2), поскольку он был последним сохранённым для тега "device1". Клиент передаёт сохранённый дескриптор SDP:X(answer2) (это - "ответ" SDP) своему "немаркированному" медиа-объекту A. 

Сообщение <callConnected/> вообще могло прийти без SDP и с другим тегом: 
S:<callConnected callLeg="c1" tag="device2"/> 
Клиент удаляет проигрыватели "тонов дозвона", удаляет "немаркированный" медиа-объект A и удаляет маркировку с медиа-объекта B (связанного с тегом "device2"). 


Звонок установлен, медиа-объект (A или B) настроен для работы в режиме "отправлять и получать", начался обмен медиаданными. 
C:<callUpdateAccept id="A007" callLeg="c1"/> 
S:<response id="A007"/> 

Пользователь решает завершить звонок, Клиент завершает звонок и освобождает связанные с ним ресурсы Сервера: 
S:<callKill id="A008" callLeg="c1" /> 
S:<response id="A008"/> 
Звонок заканчивается, Клиент удаляет "немаркированный" медиа-объект A.

Пример Исходящий-04. Сессия исходящего звонка с начальным SDP, несколько устройств на принимающей стороне. медиа-объект не поддерживает "расщепление", дополнительные сообщения от вызываемых устройств.

Клиент создаёт медиа-объект A и использует его как "немаркированный" медиа-объект для нового звонка. 
Клиент получает "предложение" SDP от этого объекта: SDP:A(offer) 
C:<callStart id="A001" callLeg="c1" peer="user@domain">SDP:A(offer)</callStart> 
S:<response id="A001"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
Клиент создаёт проигрыватель "тонов дозвона", чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id="A002" callLeg="c1"/> 
S:<response id="A002"/> 

S:<callProvisioned callLeg="c1" tag="device2"/> 
Клиент создаёт ещё один проигрыватель "тонов дозвона", чтобы пользователь знал о факте дозвона. Оба проигрывателя издают тоны дозвона (КПВ).
C:<callUpdateAccept id="A003" callLeg="c1"/> 
S:<response id="A003"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer1)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer1) и связывает его с тегом "device1". Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A004" callLeg="c1"/> 
S:<response id="A004"/> 

S:<callProvisioned callLeg="c1" tag="device1">SDP:X(answer2)</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer2) и связывает его с тегом "device1". Он заменяет полученный ранее с этим тегом SDP:X(answer1). Изменений в медиа нет, оба проигрывателя издают тоны дозвона (КПВ). 
C:<callUpdateAccept id="A005" callLeg="c1"/> 
S:<response id="A005"/> 

S:<callUpdateRequest callLeg="c1" tag="device2">SDP:Y(offer)</callUpdateRequest> 
Клиент удаляет проигрыватель "тонов дозвона", связанный с тегом "device2". 
Клиент создаёт новый медиа-объект B и связывает его с тегом "device2". медиа-объект B настроен для работы в режиме "только принимать". 
Клиент передаёт полученный SDP:Y(offer1) в качестве "предложения" SDP медиа-объекту B. 
Клиент получает "ответ" SDP от этого медиа-объекта: SDP:B(answer), и передаёт его серверу: 
C:<callUpdateAccept id="A006" callLeg="c1">SDP:B(answer)</callUpdateAccept> 
S:<response id="A006"/> 

S:<callUpdateRequest callLeg="c1" tag="device2">SDP:Y(offer2)</callUpdateRequest> 
Клиент использует полученный SDP для передачи его существующему медиа-объекту B, связанному с тегом "device2". 
Если это невозможно, Клиент создаёт новый медиа-объект C, передаёт ему полученный дескриптор SDP:Y(offer2) в качестве "предложения" SDP, и получает от него "ответ" SDP:C(answer). В случае успеха, Клиент удаляет медиа-объект B и "маркирует" вновь созданный медиа-объект C, связывая его с тегом "device2". 
Новый медиа-объект C настроен для работы в режиме "только принимать". 
Клиент передаёт полученный "ответ" SDP на Сервер: 
C:<callUpdateAccept id="A007" callLeg="c1">SDP:C(answer)</callUpdateAccept> 
S:<response id="A007"/> 

S:<callUpdateSolicited callLeg="c1" tag="device3"/> 
Клиент создаёт новый медиа-объект D и связывает его с тегом "device3". 
Новый медиа-объект D настроен для работы в режиме "только принимать". 
Клиент получает от этого медиа-объекта "предложение" SDP:D(offer) и посылает его на Сервер в теле запроса callUpdate. 
C:<callUpdate id="A008" callLeg="c1">SDP:D(offer)</callUpdate> 
S:<response id="A008"/> 

Сервер отвечает сообщением callUpdated: 
S:<callUpdated callLeg="c1" tag="device3">SDP:Z(answer)</callUpdated> 
Клиент должен передать полученный дескриптор SDP медиа-объекту D как "ответ" SDP. 

S:<callConnected callLeg="c1" tag="device1">SDP:X(answer3)</callConnected> 
Клиент удаляет все проигрыватели "тонов дозвона", удаляет "маркированные" медиа-объекты (C и D) и передаёт полученный дескриптор SDP:X-3 (это - "ответ" SDP) "немаркированному" медиа-объекту A. 

Сообщение <callConnected/> вообще могло прийти без SDP: 
S:<callConnected callLeg="c1" tag="device1"/> 
Клиент удаляет проигрыватели "тонов дозвона", удаляет все "маркированные" медиа-объекты (C и D) и использует дескриптор SDP:X(answer2), поскольку он был последним сохранённым для тега "device1". Клиент передаёт сохранённый дескриптор SDP:X(answer2) (это - "ответ" SDP) своему "немаркированному" медиа-объекту A. 

Сообщение <callConnected/> вообще могло прийти без SDP и с другим тегом: 
S:<callConnected callLeg="c1" tag="device2"/> 
Клиент удаляет все проигрыватели "тонов дозвона", удаляет "немаркированный" медиа-объект A и "маркированный" медиа-объект D удаляет маркировку с медиа-объекта C (связанного с тегом "device2"). 

Сообщение <callConnected/> вообще могло прийти без SDP и с другим тегом: 
S:<callConnected callLeg=«c1» tag=«device3»/> 
Клиент удаляет все проигрыватели «тонов дозвона», удаляет «немаркированный» медиа-объект A и «маркированный» медиа-объект С и удаляет маркировку с медиа-объекта D (связанного с тегом "device3"). 

Звонок установлен, «немаркированный» медиа-объект (A, C или D) настроен для работы в режиме "отправлять и получать", начался обмен медиаданными. 
C:<callUpdateAccept id="A007" callLeg="c1"/> 
S:<response id="A007"/> 

Пользователь решает завершить звонок, Клиент завершает звонок и освобождает связанные с ним ресурсы Сервера: 
S:<callKill id="A008" callLeg="c1" /> 
S:<response id="A008"/> 
Звонок заканчивается, Клиент удаляет "немаркированный" медиа-объект A.

Пример Исходящий-11. Сессия исходящего звонка без начального SDP.

Клиент не создаёт медиа-объект перед звонком. 
C:<callStart id="A001" callLeg="c1" peer="user@domain"/> 
S:<response id="A001"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
Клиент создаёт проигрыватель "тонов дозвона", чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id="A002" callLeg="c1"/> 
S:<response id="A002"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
У Клиента уже есть проигрыватель "тонов дозвона" для этого устройства (тега), поэтому дополнительные операции с медиа не нужны. 
C:<callUpdateAccept id="A003" callLeg="c1"/> 
S:<response id="A003"/> 

S:<callConnected callLeg="c1" tag="device1">SDP:X-1</callConnected> 
Клиент удаляет проигрыватель "тонов дозвона", создаёт "немаркированный" медиа-объект A и передаёт полученный дескриптор SDP:X-1 (это - "ответ" SDP) "немаркированному" медиа-объекту A. 
Клиент получает "ответ" SDP (SDP:A-1) от медиа-объекта A и посылает его на сервер: 
C:<callUpdateAccept id="A004" callLeg="c1">SDP:A-1</callUpdateAccept> 
S:<response id="A004"/> 
Звонок установлен, медиа-объект A настроен для работы в режиме "отправлять и получать", начался обмен медиаданными. 

S:<callDisconnected callLeg="inp01" /> 
Звонок завершается, Клиент удаляет "немаркированный" медиа-объект A. 

Клиент освобождает ресурсы Сервера, занятые в звонке: 
C:<callKill id="A005" callLeg="c1"/> 
S:<response id="A005"/>

Пример Исходящий-12. Сессия исходящего звонка без начального SDP, несколько устройств на принимающей стороне.

Клиент не создаёт медиа-объект перед звонком. 
C:<callStart id="A001" callLeg="c1" peer="user@domain"/> 
S:<response id="A001"/> 

S:<callProvisioned callLeg="c1" tag="device1"/> 
Клиент создаёт проигрыватель "тонов дозвона", чтобы дать понять пользователю, что происходит вызов абонента. 
C:<callUpdateAccept id="A002" callLeg="c1"/> 
S:<response id="A002"/> 

S:<callProvisioned callLeg="c1" tag="device2"/> 
Клиент создаёт ещё один проигрыватель "тонов дозвона", чтобы пользователь знал о факте дозвона. Оба проигрывателя издают тоны дозвона (КПВ).
C:<callUpdateAccept id="A003" callLeg="c1"/> 
S:<response id="A003"/> 

S:<callProvisioned callLeg="c1" tag="device2">SDP:X-1</callProvisioned> 
Клиент сохраняет полученный SDP:X(answer1) и связывает его с тегом "device2". 
Клиент создаёт медиа-объект А, маркирует и связывает его с тегом "device2". 
Клиент создаёт немаркированный медиа-объект A, и передаёт ему полученный SDP:X-1 ("предложение" SDP) . 
Клиент получает "ответ" SDP от медиа-объекта A, и шлёт его на Сервер. 
C:<callUpdateAccept id="A004" callLeg="c1">SDP:A-1</callUpdateAccept> 
S:<response id="A004"/> 

S:<callConnected callLeg="c1" tag="device1">SDP:Y-1</callConnected> 
Клиент удаляет "проигрыватель дозвона" и медиа-объект A (маркированный тегом "device2"). 
Клиент создаёт немаркированный медиа-объект B, и передаёт ему полученный SDP:Y-1 ("предложение" SDP) . 
Клиент получает "ответ" SDP от медиа-объекта B (SDP:B-1), и шлёт его на Сервер. 
Звонок установлен, медиа-объект B настроен для работы в режиме "отправлять и получать", начался обмен медиаданными. 
C:<callUpdateAccept id="A005" callLeg="c1">SDP:B-1</callUpdateAccept> 
S:<response id="A005"/> 

Сообщение <callConnected/> вообще могло прийти без SDP и с другим тегом: 
S:<callConnected callLeg="c1" tag="device2"/> 
Клиент удаляет проигрыватели "тонов дозвона", удаляет маркировку с медиа-объекта A (прежде - маркированного и связанного с тегом "device2").
Звонок установлен, медиа-объект A настроен для работы в режиме «отправлять и получать», начался обмен медиаданными. 
C:<callUpdateAccept id=«A005» callLeg=«c1»/> 
S:<response id=«A005»/> 

Пользователь решает завершить звонок, Клиент завершает звонок и освобождает связанные с ним ресурсы Сервера: 
S:<callKill id=«A006» callLeg=«c1» /> 
S:<response id=«A006»/> 
Звонок заканчивается, Клиент удаляет «немаркированный» медиа-объект A.

Мгновенные сообщения

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

sendIM

Эта операция отправляет Мгновенное Сообщение указанному пользователю. Сервер отправляет XIMSS ответ не ожидая фактической доставки Мгновенного сообщения.
Отдельной операции для открытия сессии Мгновенных Сообщений нет. Если Сервер не имеет открытой сессии Мгновенных Сообщений с указанным абонентом, то создаётся новая сессия.

Атрибуты:peer

адрес электронной почты пользователя, которому необходимо отправить сообщение.

clientID

необязательно; имя или идентификатор устройства абонента, на которое надо доставить Мгновенное Сообщение.

type

необязательно; тип сообщения согласно протоколу XMPP: chat, groupchat и т.д.

iqid

необязательно; строка идентификатора сообщения.

Тело:

• текст Мгновенного Сообщения (в кодировке UTF-8) или

• элемент XML body, содержащий текст Мгновенного Сообщения в теле, возможно, вместе с другими элементами XML сообщения. Или

• элемент XML composing (этот элемент надо посылать, когда пользователь приготовил сообщение, но пока его не отправил). Или

• элемент XML paused (этот элемент надо посылать, когда пользователь перестал набирать сообщение перед отправкой). Или

• элемент XML gone (этот элемент надо посылать, когда пользователь закончил разговор).

• элемент XML subject: его текстовое тело является строкой темы сообщения.

closeIM

Запрос на закрытие всех сессий Мгновенных Сообщений с указанным пользователем.
Клиентское приложения должно отправлять этот запрос при закрытии окна обмена Мгновенными Сообщениями.

Атрибуты:peer

адрес электронной почты пользователя.

Сервер присылает следующие сообщения с данными:

readIM

Эти асинхронные сообщения данных присылаются, когда Сервер получает Мгновенное Сообщение для клиента пользователя.

Атрибуты:peer

адрес электронной почты отправителя.

peerName

необязательно; настоящее имя отправителя.

clientID

необязательно; имя или идентификатор устройства абонента, с которого было отправлено Мгновенное Сообщение.

subject

необязательно; строка с темой сообщения (при использовании базового формата).

iqid

необязательно; строка идентификатора сообщения.

gmtTime

необязательно; отметка времени получения сообщения.

Тело:

• элемент XML composing; этот элемент присылается, когда абонент готовит (набирает) сообщение, но пока его не отправляет. Или

• элемент XML paused; этот элемент присылается, когда абонент приостановил набор сообщения. Или

• элемент XML gone; этот элемент присылается, когда пользователь закончил разговор. Или

• содержимое сообщения в базовом или расширенном формате, согласно последнему запросу signalBind:

  простой формат:

  текст Мгновенного Сообщения (в кодировке UTF-8)

  расширенный формат:

  элемент XML body, содержащий текст Мгновенного Сообщения в теле, возможно, вместе с другими элементами XML сообщения.

  элемент XML subject: его текстовое тело является строкой темы сообщения.

Операции явного открытия сессии не существует. Если у клиента отсутствуют открытое окно по обмену Мгновенными Сообщениями для указанного пользователя, то он должен открыть новое окно.

errorIM

Эти асинхронные сообщения данных присылаются, когда Сервер не смог доставить Мгновенное Сообщение.

Атрибуты:peer

адрес электронной почты получателя.

errorText

текст сообщения об ошибке.

signalCode

числовой код ошибки.

sendid

атрибут id той операции sendIM, в которой произошла ошибка при отправке Мгновенного Сообщения.

Ростер и статус присутствия

Модель Ростера и Статуса Присутствия построена согласно модели протокола XMPP.

Ростером является набор элементов данных, каждый из которых описывает "контакт" - некоторого другого локального или удалённого пользователя. Пользователь может быть наблюдать за информацией о статусе присутствия "контакта", а "контакту" могут быть предоставлены права на наблюдение за информацией о статусе присутствия пользователя.

rosterList

Эта операция запрашивает все активные элементы данных Ростера.

Атрибуты:accountName

если этот необязательный атрибут задан, то операция читает элементы Ростера указанного Пользователя.

Сервер отправляет сообщения данных rosterItem для всех активных "контактов" Ростера.

rosterSet

Эта операция изменяет "контакт" в Ростере.

Атрибуты:accountName

если этот необязательный атрибут задан, то операция изменяет Ростер указанного Пользователя.

peer

адрес электронной почты контакта.

subscription

необязательный атрибут:

• update или без атрибутов: изменяет информацию о контакте.

• remove: удаляет контакт из Ростера.

• subscribed: подтверждает запрос контакта на наблюдение за информацией о статусе присутствия пользователя.

• unsubscribed: отвергает запрос контакта на наблюдение за информацией о статусе присутствия пользователя или отзывает ранее предоставленное право на наблюдение.

• subscribe: отправляет запрос на наблюдение за информацией о статусе присутствия контакта.

• subBoth: подтверждает запрос контакта на наблюдение за информацией о статусе присутствия пользователя и отправляет запрос на наблюдение за информацией о статусе присутствия контакта.

• unsubscribe: останавливает наблюдение за информацией о статусе присутствия контакта.

name

необязательный атрибут, в котором содержится настоящее имя Контакта.

Тело:

набор элементов XML group; тело каждого элемента указывает имя Группы, которой принадлежит этого контакт.

Операции update, subscribed и subscribe создают новую запись в Ростере, если ранее элемент данных с таким адресом не существовал.

rosterGroupSet

Эта операция управляет "группами контактов" в Ростере.

Атрибуты:accountName

если этот необязательный атрибут задан, то операция изменяет Ростер указанного Пользователя.

group

имя группы.

mode

• add: создаёт новую группу контактов с указанным именем.

• delete: удаляет существующую группу контактов с указанным именем из Ростера.

• rename: переименовывает существующую группу контактов.

newName

новое имя группы контактов (используется только если атрибут mode имеет значение rename).

presenceSet

Эта операция устанавливает статус присутствия пользователя. Сервер собирает информацию о статусе присутствия от всех подключённых клиентов (XIMSS, XMPP, SIP) и распространяет её всем подписчикам.

Атрибуты:type

этот необязательный элемент может иметь значение unavailable. Он указывает, что пользователь "как будто вне сети".
Если этот атрибут отсутствует, то пользователь находится в сети.

Тело:

необязательный XML элемент show; его текстовое тело указывает статус присутствия пользователя согласно протоколу XMPP:

• dnd - Не беспокоить, Занят(а), На телефоне.

• away - Скоро вернусь, На совещании, На перерыве.

• xa - Нет на месте ("расширенное" Нет на месте).

В качестве альтернативы вы можете использовать элемент XML presence вместо элемента XML show. Тело текстового XML элемента presence содержит более подробный статус присутствия пользователя:

• offline - "как будто вне сети".

• online - В сети.

• on-phone - пользователь в настоящее время разговаривает по телефону.

• in-meeting - пользователь находится на совещании.

• busy - общая форма для "не могу сейчас говорить".

• be-back - пользователь скоро вернётся

• out-lunch - пользователь вышел на перерыв.

• away - Нет на месте.

Тело элемента XML может содержать элемент XML status: его текстовое тело задаёт произвольное сообщение о статусе. Для удаления заданного прежде произвольного сообщения о статусе надо передать пустой объект XML status.

В начале сессии пользователь находится "как будто вне сети". Клиент должен использовать эту операцию, чтобы показать, что пользователь находится в сети.

Когда пользователь отсоединяется, статус его сессии автоматически меняется на unavailable (вне сети).

Эта операция может использоваться для отправки информации о статусе занятости конкретному устройству (например, для подключения к групповому чату по протоколу XMPP). Чтобы отправить информацию о статусе занятости (а не только установить её), надо использовать дополнительные атрибуты:

Атрибуты:peer

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

clientID

необязательно; имя или идентификатор устройства абонента, на которое надо доставить информацию о статусе занятости.

Сервер присылает следующие сообщения с данными:

rosterItem

Эти сообщения с данными отправляются синхронно при обработке Сервером запроса rosterList. Для каждого элемента данных Ростера (для каждого "Контакта") отправляется одно сообщение.
Эти сообщения данных также могут быть отправлены асинхронно (смотрите ниже).

Атрибуты:peer

адрес электронной почты контакта.

subscription

• to: пользователь может наблюдать за контактом.

• from: контакт может наблюдать за пользователем.

• both: пользователь и контакт могут наблюдать друг за другом.

• none: пользователь и контакт не могут наблюдать друг за другом.

ask

этот необязательный атрибут имеет значение subscribe, если пользователь запросил подписку на информацию о статусе присутствия контакта, но этот запрос ещё не был подтверждён.

name

необязательный атрибут, в котором содержится настоящее имя Контакта.

Тело:

набор элементов XML group; тело каждого элемента указывает имя Группы, которой принадлежит этого контакт.

Если для разрешения уведомлений Ростера и Статуса Присутствия была использована операция signalBind:

• Каждый раз, когда элемент данных Ростера добавляется или изменяется, Сервер отправляет сообщения rosterItem с новыми или изменёнными данными.

• Каждый раз, когда элемент данных Ростера удаляется, Сервер отправляет сообщения rosterItem с атрибутом subscription, имеющим значение remove.

• Сервер отправляет сообщения с данными presence.

presence

Эти асинхронные сообщения с данными отправляются, когда статус присутствия некоторого "контакта" (элемента Ростера) изменяется и уведомления об изменении Статуса включены.

Атрибуты:peer

адрес электронной почты контакта.

type

необязательный атрибут:

• unavailable: контакт находится вне сети.

• subscribe: контакт требует подписку на информацию о статусе присутствия пользователя.

• отсутствует: контакт в сети.

Тело:

элемент XML presence; его текстовое тело указывает детализированный статус присутствия контакта (смотрите выше);
необязательный элемент XML show; его текстовое тело указывает статус присутствия контакта в стиле XMPP (смотрите выше).

Эти асинхронные сообщения с данными присылаются также, когда удалённый абонент присылает свою информацию о занятости именно в эту сессию протокола XIMSS (например, групповой чат информирует эту сессию о пользователях - присоединяющихся и покидающих чат). В этом случае сообщение с данными содержит дополнительные атрибуты.

Атрибуты:clientID

имя или идентификатор устройства абонента, с которого было отправлено сообщение о статусе присутствия.

Запросы в стиле протокола XMPP

Клиент может отправлять и получать запросы, аналогичные запросам "iq" в протоколе XMPP.

iqSend

Эта операция отправляет запрос "iq" указанному пользователю. Сервер отправляет XIMSS ответ, не ожидая фактической доставки Мгновенного сообщения.

Атрибуты:peer

адрес электронной почты пользователя, которому необходимо отправить запрос "iq".

clientID

необязательно: имя или идентификатор устройства абонента, на которое надо доставить информацию о статусе занятости.

type

тип запроса "iq" XMPP (get, set, result или error).

iqid

значение этого атрибута задаёт значение атрибута id запроса "iq" XMPP.

Тело:

тело запроса "iq" XMPP.

Сервер присылает следующие сообщения с данными:

iqRead

Эти асинхронные сообщения данных присылаются, когда Сервер получает запрос "iq" XMPP для клиента пользователя.

Атрибуты:peer

адрес электронной почты отправителя.

clientID

необязательно; имя или идентификатор устройства абонента, с которого было отправлено Мгновенное Сообщение.

type

тип запроса "iq" XMPP (get, set, result или error).

iqid

атрибут id принятого запроса "iq" XMPP.

Тело:

тело запроса "iq" XMPP.

Настройки

Клиент может получать и изменять Настройки аутентифицированного пользователя и данные О Себе ("Публично Доступные").

prefsRead

Эта операция получает Настройки аутентифицированного пользователя или его данные "О Себе" ("Публично Доступные").

Атрибуты:type

это - необязательный параметр.
Если указано значение default, то возвращаются Настройки, задаваемые для Пользователя Домена по умолчанию.
Если указано значение custom, то возвращаются явно заданные Настройки Пользователя.
Если указано значение publicInfo, то запрашиваются настройки Пользователя "О Себе" ("Публично Доступные").
Если атрибут не указан, то будут получены все фактически действующие Настройки Пользователя.

Тело:

Ноль или более элементов XML name. Тело этих элементов задаёт имена получаемых элементов; если не указано ни одного элемента name, то получаются все элементы Настроек или элементы "О Себе" ("Публично Доступные").

Сервер возвращает одно сообщение prefs.

prefsStore

Эта операция изменяет Настройки аутентифицированного пользователя или его данные "О Себе" ("Публично Доступные").

Атрибуты:type

это - необязательный параметр.
Если его значением является publicInfo, то изменяются Настройки Пользователя "О Себе" ("Публично Доступные").
Если атрибут не указан, то будут обновлены все указанные Настройки Пользователя.

Тело:

Элементы XML с именами, совпадающими с именами элементов Настроек. Тело элемента содержит новое значение элемента Настроек. Если значением является строка default, то значения пользовательских Настроек или настроек "О Себе" ("Публично Доступные") удаляются и фактически действующими Настройками Пользователя становятся Настройки по умолчанию.
Если значение является массивом, то он должен быть представлен с использованием представления XML для array.
Если значением является словарь, то он должен быть представлен с использованием представления XML для dictionary.

Если тело содержит элемент UserFromAddr, то Сервер использует этот элемент и необязательный элемент UserFromName для составления элемента UserFrom, имеющим значение адрес электронной почты (в формате "UserFromName_value" <UserFromAddr_value>).

prefsReload

Реализация некоторых операций Сервером (таких, как удаление сообщений) зависит от значений Настроек, читаемых при открытии сессии. Когда какая-либо сессия изменяет Настройки, то клиент может использовать эту операцию для того, чтобы Сервер обновил их "кэшированные" значения.

Атрибуты:

отсутствуют

Сервер присылает следующие сообщения с данными:

prefs

Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос prefsRead.

Атрибуты:type

необязательный атрибут, такой же как и атрибут запроса.

Тело:

Элементы XML с именами, совпадающими с именами элементов Настроек и элементов "О Себе". В теле элемента содержится значение элемента.
Если значение является массивом, то он представляется с использованием представления XML для array.
Если значением является словарь, то представляется с использованием представления XML для dictionary.

Если данные prefs содержат строку UserFrom, то Сервер пытается разобрать этот адрес электронной почты. Если адрес может быть разобран, то к телу сообщения данных добавляется элемент UserFromAddr (содержащим "чистый" адрес userName@domainName) и необязательный элемент UserFromName (с комментарием адреса).

prefsModified

Эти асинхронные сообщения данных отправляются при изменении Настроек Пользователя (в этой сессии, в другой сессии или некоторым другим компонентом Сервера CommuniGate Pro).
Рекомендуется, чтобы в ответ на это сообщение клиент прочитал Настройки Пользователя заново.

Операции с хранилищем файлов

Клиент может работать с Хранилищем Файлов Пользователя.
Если аутентифицированный пользователь имеет право администратора домена CanAccessWebSites (Полный доступ ко всем Файлам), то этот клиент, используя префикс перед именем файла ~accountName/fileName, может также работать с файлами, принадлежащими другому Пользователю.

fileList

Операция возвращает список файлов (с информацией о них) в директории Файлового Хранилища.

Атрибуты:directory

необязательный атрибут с именем поддиректории в Хранилище Файлов. Если он и атрибут fileName отсутствуют, то возвращается содержимое корневой директории Пользователя в Хранилище Файлов.

fileName

необязательный атрибут, используемый только при отсутствии атрибута directory. Если он указан, то операция возвращает информацию только о файле или директории с именем из этого атрибута.

gmtTime

необязательный атрибут. Если он указан, то временные отметки в результате используют время GMT.

Сервер возвращает одно сообщение fileInfo для каждого файла или директории, находящихся в указанной директории в Хранилище Файлов.

fileDirInfo

Эта операция возвращает информацию о всех файлах Пользователя или обо всех файлах, находящихся в указанной директории.

Атрибуты:directory

необязательный атрибут с именем поддиректории в Хранилище Файлов. Если он отсутствует, то возвращается информация обо всех файлах в Хранилище Файлов Пользователя.

Сервер возвращает одно сообщение fileDirInfo.

fileDirList

С помощью этой операции можно получить список всех папок в Хранилище Файлов. Сервер возвращает одно сообщение fileDirName для каждой директории Хранилища Файлов.

fileWrite

Эта операция сохраняет данные в файл.

Атрибуты:fileName

имя записываемого файла.

position

Если этот атрибут отсутствует, то эта операция полностью перезаписывает указанный файл. Если файл не существовал, то он создаётся.
Если значением этого атрибута является append, то эта операция добавляет данные в конец файла (атомарно).
Если значением этого атрибута является new, то эта операция сначала проверяет что указанный файл не существует, а затем создаёт файл и сохраняет в нём данные.
Если значением этого атрибута является число, то файл должен существовать, а операция перезаписывает файл, начиная с позиции (байта), указываемого этим числом.

type

Если этот необязательный атрибут задан со значением binary, то телом запроса должен быть элемент XML base64; перед записью в файл тело раскодируется из base64.
Если этот необязательный атрибут задан со значением object, то телом запроса должно быть представление XML данных, содержащихся в Object; в файл записывается текстовое представление этого Объекта. Если это значение используется, то атрибут position не должен указываться.
Если этот необязательный атрибут задан со значением xml, то тело запроса должно быть одним элементом XML. Его текстовое представление записывается в файл. Если это значение используется, то атрибут position не должен указываться.
Если этот необязательный атрибут задан со значением vcard, то тело запроса должно быть одним элементом XML, представляющим объект vCard. Его текстовое представление (в формате vCard) записывается в файл. Если это значение используется, то атрибут position не должен указываться.

Тело:

Или текст с данными файла, или элемент XML base64, или объект в представлении XML, или элемент XML для записи в файл.

fileStore

Эта операция сохраняет загруженный на сервер файл или MIME часть сообщения как файл в Хранилище Файлов.

Атрибуты:fileName

имя создаваемого файла.

uploadID

строка, идентифицирующая файл в "наборе загруженных файлов".

folder, UID, partID

эти атрибуты имеют тот же смысл, что и атрибуты операции fileRead. Они идентифицируют MIME часть сообщения, которую необходимо получить, раскодировать и сохранить как файл.

calendar

используйте этот атрибут вместо атрибута folder для копирования MIME части из открытого Календаря, а не из папки с сообщениями электронной почты.

position

этот необязательный атрибут имеет тот же смысл, что и в операции fileWrite.

Должен быть задан или атрибут uploadID, или атрибут folder, или атрибут calendar. Эти атрибуты не могут быть заданы одновременно в одной операции fileStore.

fileRead

Эта операция читает данные из файла.

Атрибуты:fileName

имя файла, который необходимо прочитать.

position

Этот числовой атрибут задаёт позицию в файле, с которой начинается чтение. Если этот атрибут отсутствует, то файл читается с начала (с позиции 0).

limit

Этот числовой атрибут задаёт максимальный размер читаемой порции данных. Если он указан, то он не должен превышать 3 Мб. Если он не указан, то используется ограничение в 3 Мб.

type

Если этот необязательный атрибут задан со значением binary, то данные файла возвращается в кодировке base64 как тело элемента XML base64.
Если этот необязательный атрибут задан со значением object, то данные файла разбираются как текстовое представление Object и возвращается Объект в представлении XML. Если используется это значение, то атрибуты position и limit не должны указываться и размер файла не должен превышать 3 Мб.
Если этот необязательный атрибут задан со значением xml, то данные файла разбираются как документ XML и возвращается содержимое XML. Если используется это значение, то атрибуты position и limit не должны указываться и размер файла не должен превышать 3 Мб.
Если этот необязательный атрибут задан со значением vCard, то данные файла разбираются как документ vCard и возвращается представление XML для vCard. Если используется это значение, то атрибуты position и limit не должны указываться и размер файла не должен превышать 3 Мб.

Сервер возвращает сообщение с данными fileData.

fileRename

Эта операция переименовывает файл в Хранилище Файлов.

Атрибуты:fileName

имя файла, который необходимо переименовать.

newName

новое имя файла.

fileRemove

Эта операция удаляет файл из Хранилища Файлов.

Атрибуты:fileName

имя файла, который необходимо удалить.

fileCopy

Эта операция копирует файл или содержимое сообщения в файл в Хранилище Файлов.

Атрибуты:newName

имя создаваемого файла (для копии файла). Если файл с этим именем уже существует, то он удаляется.

fileName

необязательно: этот параметр задаёт имя файла, которое необходимо скопировать.

Тело:

необязательный элемент copyMIME. Он задаёт часть сообщения, которую снеобходимо декодировать и скопировать в указанный файл.

Операция должна использовать либо атрибут fileName, либо один элемент тела copyMIME.

fileDirCreate

Эта операция создаёт файловую директорию в Хранилище Файлов.

Атрибуты:fileName

имя файловой директории, которая будет создана.

fileDirRename

Эта операция переименовывает директорию в Хранилище Файлов.

Атрибуты:fileName

имя переименовываемой директории.

newName

новое имя директории.

fileDirRemove

Эта операция удаляет директорию из Хранилища Файлов.

Атрибуты:fileName

имя удаляемой директории. Удалены могут быть только пустые директории.

fileAttrRead

Эта операция считывает расширенные атрибуты файла или директории.

Атрибуты:fileName

имя файла или директории.

Тело:

набор элементов XML field. Каждый элемент должен иметь текстовое тело, содержащее имя получаемого атрибута.

Если ни один элемент field не указан, то возвращаются все атрибуты.
Сервер возвращает сообщение с данными fileAttrData.

fileAttrWrite

Эта операция изменяет расширенные атрибуты файла или директории.

Атрибуты:fileName

имя файла или директории.

Тело:

набор элементов XML с атрибутами.
Если тело элемента XML содержит атрибут mode со значением delete, тогда все файловые атрибуты с именем в теле этого элемента XML будут удалены, а тело элемента XML не будет добавлено в качестве файлового атрибута.
Если тело элемента XML содержит атрибут mode со значением add, тогда тело этого элемента XML будет добавлено в атрибуты файла.
Если тело элемента XML содержит атрибут mode с любым другим значением или вообще без атрибута mode, тогда все файловые атрибуты с именем в теле этого элемента XML будут удалены, а тело элемента XML будет добавлено в качестве нового файлового атрибута.
Прежде чем элемент XML добавляется в набор атрибутов файла, из него удаляется атрибут mode.

fileLock

Эта операция управляет блокировками файла или директории.

Атрибуты:fileName

имя файла или директории.

mode

запрошенная операция: lock (блокировка и продолжение блокировки), unlock (разблокирование), testlock (чтение списка блокировок, может использоваться как пустая операция).

scope

атрибут используется для постановки блока и задаёт его область: exclusive (исключительная) или shared (разделяемая).

type

атрибут используется для постановки блока и задаёт его тип (read, write и т.д.).

token

атрибут используется для операций продолжения и снятия блокировки и указывает на дескриптор блокировки, ранее полученный клиентом. Блокировка, принадлежащая владельцу (owner) с указанным дескриптором (token), обновляется или удаляется.

timeTill

атрибут используется для операций создания и обновления блокировки и задаёт время окончания блокировки (в выбранном часовом поясе). Если он не указан, то используется время прекращения по умолчанию.

create

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

Тело:

для операций блокировки - элемент XML owner, содержащий информацию о владельце блокировки.

Если операция заканчивается успешно, то сервер отправляет сообщение с данными fileLockData.

fileSubList

Эта операция заставляет Сервер отправить сообщение данных fileSubscription для каждого элемента из набора подписки на файлыПользователя. Заметьте, что перечисленные в этом наборе файлы могут и не существовать.

fileSubUpdate

Эта операция изменяет набор подписки на файлы Пользователя.

Тело:

набор элементов fileSubscription.

Атрибуты:fileName

имя файла в кодировке UTF-8.

mode

если значением этого атрибута является add, то имя fileName добавляется в набор подписки на файлы (за исключением случая, когда в наборе уже имеется файл с таким именем).
в противном случае, имя fileName удаляется из набора подписки на файлы.

Сервер присылает следующие сообщения с данными:

fileInfo

Это синхронное сообщение с данными присылается, когда Сервер обрабатывает запрос fileList.

Атрибуты:fileName

имя файла или поддиректории.

directory

необязательный атрибут, аналогично атрибуту directory в запросе fileList.

type

необязательный атрибут, существует и содержит значение directory, если это сообщение описывает поддиректорию.

size

необязательный атрибут с размером файла в байтах (отсутствует, если это сообщение описывает поддиректорию).

timeModified

необязательный атрибут, в котором находится дата и время изменения файла (местное время, если в запросе не указан атрибут gmtTime).

timeAttrModified

необязательный атрибут, в котором находится дата и время изменения атрибутов файла (местное время, если в запросе не указан атрибут gmtTime).

Если атрибут fileName был указан в запросе fileList, или указанное в атрибуте directory имя принадлежит обычному файлу, а не директории, то атрибут directory не добавляется в сообщение fileInfo, а атрибут fileName содержит полный путь до файла или директории.

fileDirInfo

Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос fileDirInfo.
Обратите внимание: все атрибуты необязательны, они не существуют, если Сервер не поддерживает их (например, для операций в виртуальной директории хранилища

Атрибуты:directory

необязательный атрибут, аналогично атрибуту directory в запросе fileDirInfo.

files

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

size

общий размер всех файлов (в байтах).

filesLimit

ограничение на общее количество фалов (квота) в Установках Пользователя.

sizeLimit

ограничение на общий размер фалов (дисковая квота) в Установках Пользователя.

fileDirName

Это синхронное сообщение с данными присылается, когда Сервер обрабатывает запрос fileDirList.

Атрибуты:directory

имя директории в Хранилище Файлов.

fileData

Это синхронное сообщение с данными отправляется, когда Сервер обрабатывает запрос fileRead.

Атрибуты:fileName

имя файла.

position

позиция начала прочитанных данных в файле.

slice

размер прочитанных данных (в байтах). Чтобы получить следующую порцию данных из файла, новое значение атрибута positionскладывается из значений атрибутов position и slice.

size

общий размер файла.

timeModified

необязательный атрибут, в котором находится дата и время изменения файла (местное время).

type

копия атрибута type из запроса.

Тело:

Или текст с данными файла, или base64 (телом являются данные в кодировке base64), или представление XML содержимого файла с Объектом.

Примеры:

C:<fileRead id=«A001» fileName=«test.txt» /> 
S:<fileData id=«A001» fileName=«test.txt»position=«0» slice=«22» size=«22» timeModified=«20061018T115836»>This is not your file!</fileData> 
S:<response id=«A001»/> 

C:<fileRead id=«A002» fileName=«test.txt» limit=«15» /> 
S:<fileData id=«A002» fileName=«test.txt»position=«0» slice=«15» size=«22» timeModified=«20061018T115836»>This is not you</fileData> 
S:<response id=«A002»/> 

C:<fileRead id=«A003» fileName=«test.txt» limit=«15» position=«15» /> 
S:<fileData id=«A003» fileName=«test.txt»position=«15» slice=«7» size=«22» timeModified=«20061018T115836»>r file!</fileData> 
S:<response id=«A003»/> 

C:<fileRead id=«A004» fileName=«test.txt» limit=«15» position=«15» type=«binary» /> 
S:<fileData id=«A004» fileName=«test.txt»position=«15» slice=«7» size=«22» timeModified=«20061018T115836»><base64>ciBmaWxlIQ==</base64></fileData> 
S:<response id=«A004»/> 

C:<fileRead id=«A005» fileName=«test.txt» position=«25» /> 
S:<response id=«A005» errorText=«reading beyond the EOF mark» errorNum=«500» />

fileAttrData

Это синхронное сообщение с данными присылается, когда Сервер обрабатывает запрос fileAttrRead.

Атрибуты:fileName

имя файла или директории.

Тело:

набор элементов XML с атрибутами.

fileLockData

Эти сообщения с данными отправляются при обработке запроса fileLock.

Атрибуты:fileName

имя файла в кодировке UTF-8.

token

строка дескриптора новой или обновлённой блокировки.

expires

время прекращения новой или обновлённой блокировки.

create

этот атрибут добавляется, когда в результате запроса fileLock создаётся новый пустой файл.

Тело:

набор элементов XML fileLockData для всех существующих блокировок.
Каждый элемент содержит описанные выше атрибуты expires, scope, type.
Тело сообщения содержит элемент XML owner с информацией о владельце блокировки.

fileSubscription

Эти сообщения с данными отправляются при обработке запроса fileSubList.

Атрибуты:fileName

имя файла в кодировке UTF-8.

Управление автоматическими правилами

Клиент может работать с Автоматическими Правилами Пользователя. Каждое правило представляется в виде элемента XML rule. Наборы Правил адресуются с использованием параметра type. Поддерживаются следующие значения параметров:

• mailIn - входящие почтовые Правила (Правила Очереди).

• signalIn - входящие Правила Сигналов.

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

Каждое Правило содержит ноль или более элементов condition, ноль или более элементов action и ноль или один элемент comment:

condition

Дополнительную информацию смотрите в разделе Правила.

Атрибуты:opCode

данные условия Правила.

operator

операция условия Правила.

Тело:

параметр условия Правила.

action

Дополнительную информацию смотрите в разделе Правила.

Атрибуты:opCode

операция действия Правила.

Тело:

параметр действия Правила.

comment

Тело:

текст комментария к Правилу.

Пример:
Почтовое Правило, сохраняющее все сообщения с заголовкомX-Junk: 5в ПапкуJunk. Исключение сделано для сообщений, приходящих от аутентифицированных пользователей.

<rule type=«mailIn» name=«Junk Filter» priority=«2» > 
  <condition opCode=«Header Field» operator=«is»>X-Junk: 5*</condition> 
  <condition opCode=«Source» operator=«is not»>authenticated</condition> 
  <action opCode=«Store in»>Junk</action> 
  <action opCode=«Discard»></action> 
  <comment>This is my test Rule&#x21;</comment> 
</rule>

ruleList

Эта операция предписывает Серверу отправить сообщение rule для каждого Правила указанного типа, существующего у Пользователя. Эти сообщения не имеют тела.

Атрибуты:type

набор Правил.

ruleRead

Эта операция предписывает серверу отправить одно сообщение rule для указанного Правила. В теле этого сообщения содержатся элементы XML с условиями и действиями Правил и необязательный комментарий.

Атрибуты:type

набор Правил.

name

имя Правила.

ruleSet

Эта операция сохраняет новое Правило. Если уже есть Правило с таким же именем, то оно удаляется.
Пользователь должен иметь право указывать условия и действия, используемые как в новых, так и в старых Правилах.

Атрибуты:type

набор Правил.

name

имя Правила.

priority

приоритет Правила.

stage

стадия применения Правила (для Правил Сигналов).

Тело:

аналогично элементам XML, используемым в сообщении rule: ноль или более элементов condition, ноль или более элементов action и ноль или один элемент comment.

ruleUpdate

Эта операция изменяет приоритет Правила и/или его стадию применения (для Правил Сигналов).
Пользователь должен иметь право указывать условия и действия, используемые в изменяемом Правиле.

Атрибуты:type

набор Правил.

name

имя Правила.

priority

приоритет Правила.

stage

стадия применения Правила (для Правил Сигналов).

ruleRename

Эта операция переименовывает существующее Правило.
Пользователь должен иметь право указывать условия и действия, используемые в переименовываемом Правиле.

Атрибуты:type

набор Правил.

name

имя существующего Правила.

newName

новое имя Правила.

ruleRemove

Эта операция удаляет существующее Правило.
Пользователь должен иметь право указывать условия и действия, используемые в удаляемом Правиле.

Атрибуты:type

набор Правил.

name

имя существующего Правила.

Сервер присылает следующие сообщения с данными:

rule

Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос ruleList или ruleRead. Смотрите выше формат сообщения rule.

Управление записями RPOP и RSIP

RPOP записи представляются следующими элементами XML rpopRecord:

Атрибуты:name

имя записи.

Тело:

представление XML словаря Записи RPOP.

Клиент может управлять записями RPOP Пользователя.

rpopList

Эта операция предписывает Серверу отправить одно сообщение rpopRecord для каждой записи RPOP Пользователя.

Атрибуты:отсутствуют

rpopUpdate

Эта операция обновляет набор записей RPOP Пользователя.
Пользователь должен иметь право изменять записи RPOP.

Атрибуты:отсутствуют
Тело:

один или несколько элементов rpopRecord. Эти элементы должны иметь дополнительный атрибут:

mode

если значением этого атрибута является delete, то используется только атрибут name. Указанная запись RPOP удаляется из набора записей RPOP Пользователя.
Иначе, запись RPOP из тела элемента rpopRecord добавляется в набор записей RPOP пользователя; Если запись с таким же именем уже была в наборе, то она удаляется.

Записи RSIP представляются элементами XML rsipRecord:

Атрибуты:name

имя записи.

Тело:

представление XML словаря Записи RSIP.

Клиент может управлять записями RSIP Пользователя.

rsipList

Эта операция предписывает Серверу отправить одно сообщение rsipRecord для каждой записи RSIP Пользователя.

Атрибуты:отсутствуют

rsipUpdate

Эта операция обновляет набор RSIP записей Пользователя.
Пользователь должен иметь право изменять записи RSIP.

Атрибуты:отсутствуют
Тело:

один или несколько элементов rsipRecord. Эти элементы должны иметь дополнительный атрибут:

mode

если значением этого атрибута является delete, то используется только атрибут name. Запись RSIP с таким же атрибутом nameудаляется из набора записей RSIP Пользователя.
Иначе, запись RSIP из тела элемента rsipRecord добавляется в набор записей RSIP пользователя; если запись с таким же именем уже была в наборе, то она удаляется.

Сервер присылает следующие сообщения с данными:

rpopRecord

Это синхронное сообщение данных присылается, когда Сервер обрабатывает запрос rpopList. Смотрите выше формат сообщения rpopRecord.
Необязательный атрибут timeCompleted показывает время (в выбранном часовом поясе) последней попытки соединения.
Если последняя попытка опроса учётной записи RPOP была неудачной, в записи содержится дополнительный атрибут errorText со строкой сообщения об ошибке.

rimapRecord

Это синхронное сообщение данных присылается, когда Сервер обрабатывает запрос rimapList. Смотрите выше формат сообщения rimapRecord.
Необязательный атрибут timeCompleted показывает время (в выбранном часовом поясе) последней попытки соединения.
Если последняя попытка опроса учётной записи RIMAP была неудачной, в записи содержится дополнительный атрибут errorText со строкой сообщения об ошибке.

rsipRecord

Это синхронное сообщение с данными отправляется, когда Сервер обрабатывает запрос rsipList. Смотрите выше формат сообщения rsipRecord.
Необязательный атрибут timeCompleted показывает время (в выбранном часовом поясе) последней попытки соединения.
Если последняя попытка регистрации с учётной записью RSIP была неудачной, в записи содержится дополнительный атрибут errorText со строкой сообщения об ошибке.

Управление приложениями реального времени

Клиент может взаимодействовать с Приложениями Реального Времени, запущенными на Сервере или в Кластере CommuniGate Pro.

Сессия XIMSS может взаимодействовать с Задачами, отправляя им События. Задачи воспринимают сессию XIMSS просто как другую Задачу, так что они также могут отправлять обратно События.

Каждая сессия XIMSS поддерживает список Дескрипторов Задач для тех Задач, с которыми она взаимодействует. Каждый дескриптор в списке связан со строкой taskID. XIMSS клиент использует эти строки taskID для нахождения Задачи в списке.

taskFindMeeting

Этот запрос реализует операцию FindMeeting. Дополнительную информацию смотрите в разделе CG/PL.

Атрибуты:meetingSet

необязательное имя набора Встреч. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встреч, применяемый по умолчанию.

meetingName

уникальный идентификатор Встречи.

Если эта операция заканчивается успешно, то Сервер возвращает сообщение taskMeeting с обнаруженными данными встречи.

taskCreateMeeting

Этот запрос реализует операцию CreateMeeting. Дополнительную информацию смотрите в разделе CG/PL.

Атрибуты:meetingSet

необязательное имя набора Встреч. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встреч, применяемый по умолчанию.

meetingName

уникальный идентификатор Встречи.

Тело:

Текст, добавляемый в Событие Встречи в качестве параметра.

taskRemoveMeeting, taskClearMeeting, taskActivateMeeting, taskDeactivateMeeting

Эти запросы реализуют операции для объектов Встреч. Дополнительную информацию смотрите в разделе CG/PL.

Атрибуты:meetingSet

необязательное имя набора Встреч. Если значение этого параметра опущено или является пустой строкой, то используется Набор Встреч, применяемый по умолчанию.

meetingName

уникальный идентификатор Встречи.

taskSendEvent

Эта операция отправляет Задаче Событие.

Атрибуты:taskRef

внутренний taskID Задачи, который отправляется Событие.

eventName

имя отправляемого События.

Тело:

необязательный текст или представление XML объекта данных, которые будут отправлены как параметр События.

taskStart

Эта операция запускает Задачу Приложения Реального Времени.
Если операция заканчивается успешно, то сервер отправляет сообщение данных taskCreated.

Атрибуты:programName

имя приложения.

entryName

этот необязательный атрибут задаёт имя точки входа в программу; если он не указан, то программа запускается с точки входа main.

Тело:

набор элементов XML param. Текстовые тела этих элементов помещаются в массив startParameter Задачи.

taskClose

С каждым внутренним taskID связываются некоторые определённые ресурсы сессии. Если клиент работает со многими задачами, то по завершению взаимодействия с какой-либо Задачей рекомендуется использование операции taskClose, что освобождает все внутренние ресурсы taskID.
Если та же Задача отправляет в эту сессию Событие или Описатель Задачи был обнаружен другим способов, то в этой сессии этой Задаче присваивается новый taskID.

Атрибуты:taskRef

освобождаемый внутренний taskID.

Сервер присылает следующие сообщения с данными:

taskMeeting

Это синхронное сообщение данных отправляется, когда Сервер обрабатывает запрос taskFindMeeting.

Атрибуты:meetingSet, meetingName

копия атрибутов запроса taskFindMeeting.

taskRef

необязательный атрибут: внутренний taskID Задачи, который активировал эту Встречу.

expires

необязательный атрибут с датой и временем (GMT) прекращения доступности Встречи.

Тело:

Представление XML параметров Встречи.

taskCreated

Это синхронное сообщение с данными отправляется, когда Сервер обрабатывает запрос taskStart.

Атрибуты:taskRef

внутренний taskID созданной Задачи.

taskEvent

Это асинхронное сообщение с данными присылается, когда некоторая Задача или сам Сервер отправляет Событие в текущую сессию XIMSS.

Атрибуты:taskRef

внутренний taskID Задачи, отправившей Событие. Если этот атрибут отсутствует, то Событие было создано и отправлено самим Сервером.

eventName

имя полученного События.

Тело:

Текст или представление XML параметров События.

Справочник

Клиент может получать доступ к глобальному Справочнику.

listDirectory

Эта операция получает данные из Справочника.

Атрибуты:baseDN

DN записи Справочника, с которой начинается поиск. Если значением атрибута является $, то baseDN устанавливается в то поддерево Справочника, в котором содержатся записи для текущего Домена Пользователя.

filter

этот необязательный атрибут задаёт фильтр поиска в формате RFC2254.

scope

в этом необязательном атрибуте задаётся тип поиска:

• base - baseDN получаемой записи (атрибут filter игнорируется)

• one (по умолчанию) - поиск осуществляется непосредственно в поддереве baseDN (одноуровневый поиск)

• sub - поиск осуществляется во всём поддереве baseDN (многоуровневый поиск)

limit

в этом необязательном атрибуте задаётся максимальное количество записей в результате поиска.

sortField

в этом необязательном атрибуте задаётся список имён атрибутов через запятую, которые используются для сортировки записей. Внимание: атрибуты ближе к концу списка имеют больший вес при сортировке.

sortOrder

если этот необязательный атрибут задан и имеет значение desc, то применяется обратный порядок сортировки.

cookie

в этом необязательном атрибуте указывается "закладка продолжения поиска". Для получения первого набора записей он должен быть пустой строкой. Для продолжения поиска он должен быть установлен в значение атрибута cookie сообщения с данными directoryData, присланного как результат предыдущего запроса.

Тело (необязательно):

набор элементов XML field. Каждый элемент должен иметь текстовое тело, содержащее имя получаемого атрибута. Если элемент field не указан, то возвращаются все неслужебные атрибуты записи Справочника.
Обратите внимание: если атрибут mail указан явно, то Сервер сформирует значение этого атрибута для всех записей объектов CommuniGate Pro, у которых он отсутствует.

Сервер присылает сообщение directoryData для каждой найденной записи.

modifyDirectory

Эта операция изменяет данные в Справочнике.

Атрибуты:name

DN записи Справочника, которая будет изменена. Символ $ заменяется на строку значения поддерева Справочника, в котором содержатся записи для текущего Домена Пользователя.

newName

если этот необязательный атрибут задан, то DN записи будет переименовано.

Тело (необязательно):

Представление XML атрибутов записи Справочника.
Если Тело пустое и отсутствует атрибут newName, то запись с данным DN будет удалена.

Пример:

C:<modifyDirectory id=«A001» name=«mail=user@example.dom,$»> 
C: <subKey key=«mail»>user@example.dom</subKey> 
C: <subKey key=«cn»>User J. Smith</subKey> 
C: <subKey key=«sn»></subKey> 
C: <subKey key=«objectclass»> 
C:  <subValue>top</subValue> 
C:  <subValue>person</subValue> 
C:  <subValue>organizationalPerson</subValue> 
C:  <subValue>inetOrgPerson</subValue> 
C: </subKey> 
C:</modifyDirectory> 
S:<response id=«A001»/>

Сервер присылает следующие сообщения с данными:

directoryData

Это синхронное сообщение данных отправляется для каждой записи Справочника, возвращаемой в ответ на запрос listDirectory.

Атрибуты:name

DN записи.

cookie

содержится только в последней записи результата поиска, только если запрос содержал этот атрибут и поиск может быть продолжен для получения большего числа результатов. Это значение надо использовать в повторных запросах listDirectory для продолжения поиска.

Тело:

Представление XML атрибутов Записи.

Наборы данных

Клиент может управлять наборами данных Пользователя - например, такими, как набор данных RepliedAddresses (авто-отвеченные).

Для доступа к Набору данных другого Пользователя, имя набора данных должно быть задано как ~accountName/datasetName или ~accountName@domainName/datasetName

datasetCreate

Эта операция создаёт набор данных Пользователя.

Атрибуты:dataset

имя создаваемого набора данных.

datasetRemove

Эта операция удаляет набор данных Пользователя.

Атрибуты:dataset

имя удаляемого набора данных.

ifExists

если значением этого необязательного атрибута является yes и набор данных не существует, то сообщение об ошибке не создаётся.

datasetAddAddress

Эта операция добавляет адрес в набор данных Пользователя.

Атрибуты:dataset

имя набора данных, в который будет добавлен адрес электронной почты.

realName

в этом необязательном атрибуте задаётся "настоящее имя" адреса электронной почты.

Тело:

Строка с адресом электронной почты.

datasetList

Эта операция получает данные из набора данных Пользователя.

Атрибуты:dataset

имя набора данных.

filterField, filter

эти необязательные атрибуты задают значение и имя атрибута записи. Если они указаны, то операция возвращает только те записи, у которых указанный атрибут имеет указанное значение.

mode

этот необязательный атрибут может быть указан, если указан атрибут filterField.
Если атрибут mode отсутствует или его значение равно eq, то запись попадает в результат если указанный атрибут имеет указанное значение.
Если значение атрибута mode равно beg, то запись попадает в результат, если значение указанного атрибута начинается с указанного значения.
Если значение атрибута mode равно end, то запись попадает в результат, если значение указанного атрибута оканчивается указанным значением.
Если значение атрибута mode равно contains, то запись попадает в результат, если в значении указанного атрибута содержится указанное значение.

Сервер отправляет сообщение datasetData для каждой найденной записи.

datasetListSubsets

Операция перечисляет все разделы Набора Данных Пользователя.

Атрибуты:dataset

имя набора данных. Можно указать пустую строка для перечисления всех разделов верхнего уровня.

Сервер отправляет сообщение datasetSubset для каждой найденного раздела.

datasetSet

Эта операция изменяет записи в наборе данных Пользователя.

Атрибуты:dataset

имя изменяемого набора данных.

Тело:

Элемент datasetData. Его атрибут name задаёт имя записи из набора данных, которую необходимо изменить или создать. Если он не указан, то для новой записи генерируется случайно имя.
Телом элемента должно быть представление XML изменяемых атрибутов данных.

datasetDelete

Эта операция удаляет запись из набора данных Пользователя.

Атрибуты:dataset

имя изменяемого набора данных.

name

имя записи, удаляемой из набора данных.

Сервер присылает следующие сообщения с данными:

datasetData

Это синхронное сообщение с данными присылается для каждой записи из набора данных, возвращаемой в ответ на запрос datasetList.

Атрибуты:name

имя записи из набора данных.

Тело:

Представление XML атрибутов записи из набора данных.

datasetSubset

Это синхронное сообщение с данными присылается для каждого раздела из набора данных в ответ на запрос datasetListSubsets.

Атрибуты:dataset

имя записи в разделе.

Тело:

отсутствует

Тарификация

Клиент может работать со средствами на балансовых Остатках Пользователя.

balance

Эта операция выполняет операцию Тарификации.

Атрибуты:accountName

имя Пользователя (необязательно). Если не указано, то операция применяется для Пользователя, которому принадлежит данная сессия.

localTime

если атрибут не указан или указан со значением иным, чем no, все значения атрибутов с отметкой времени должны быть указаны с использованием часового пояса из настроек Пользователя; результаты также используют этот часовой пояс.
Если значение равно no, все значения атрибутов с отметкой времени в запросах и результатах используют часовой пояс GMT.

Тело:

Представление XML словаря. Словарь содержит тип операции Тарификации (элемент op) и параметры самой операции.

Если операция генерирует какой-либо результат, то сервер возвращает сообщение balanceData.

Сервер присылает следующие сообщения с данными:

balanceData

Это синхронное сообщение с данными присылается, когда операция balance выдаёт какой-либо результат.

Атрибуты:accountName

имя целевого пользователя (необязательно, аналогично указанному в запросе операции balance).

Тело:

Словарь с результатами в представлении XML.

Помощники приложений

Клиент может вызывать Помощники Приложений.

callHelper

Эта операция вызывает Помощник Приложений. Если операция генерирует какой-либо результат, то сервер возвращает сообщение helperReply.

Атрибуты:name

имя Помощника Приложений.

mode

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

Тело:

(необязательно) представление XML для параметров запроса к Помощнику.

Сервер присылает следующие сообщения с данными:

helperReply

Это синхронное сообщение данных отправляется, когда операция callHelper генерирует какой-либо результат.

Атрибуты:name

имеет то же значение, что и в операции callHelper.

Тело:

(необязательно) представление XML для возвращаемых данных от Помощника.

Получение рекламы

Клиент может задействовать Внешнюю Рекламную Систему.

bannerRead

Эта операция получает рекламную информацию. Если операция генерирует какой-либо результат, то сервер возвращает сообщение banner.

Атрибуты:type

тип получаемой рекламы (зависит от приложения, например, prontoEmailTop, myClientLeftBanner).

Тело:

(необязательно) представление XML для параметров объекта из Внешней Рекламной Системы.

Сервер присылает следующие сообщения с данными:

banner

Это синхронное сообщение данных отправляется, когда операция bannerRead генерирует какой-либо результат.

Атрибуты:type

имеет то же значение, что и в операции bannerRead.

Тело:

(необязательно) представление XML для результирующего объекта из Внешней Рекламной Системы.

Синхронные скрипты

Клиент может использовать Синхронные Скрипты, расположенные на сервере.

runScript

Эта операция выполняет на сервере синхронный скрипт. В ответ сервер шлёт сообщение scriptResult.

Атрибуты:fileName

имя файла с синхронным скриптом (суффикс .scgp использовать не обязательно).

name

(необязательно) имя точки входа в скрипт.

Тело:

(необязательно) объект-параметр в представлении XML.

Сервер присылает следующие сообщения с данными:

scriptResult

Это синхронное сообщение данных отправляется, когда операция runScript генерирует результат.

Атрибуты:
Тело:

(необязательно) объект-результат в представлении XML.

Форматы данных XML

Элементы данных представляются в формате XML с использованием следующих соглашений.

Email

Этот элемент XML представляет сообщение электронной почты или его раздел MIME в соответствии с RFC822.

Тело:

набор элементов XML, содержащих поля заголовка сообщения электронной почты, такие как From, Date и т.д., не включая поля MIME, связанные с содержимым (такие как Content-Type),
и (необязательно) элемент MIME с телом сообщения.

Типом каждого XML элемента является имя поля:

<Subject>Hello, world!</Subject>

Категории полей:

Адреса: From, To, Cc, Bcc, Return-Path, Sender, Reply-To, Disposition-Notification-To, Recent-From, Recent-To, Return-Receipt-To, Errors-To

Телом элемента является адрес электронной почты в формате userName@domainName или в более общем формате userName[%domainA[%domainB]]@domainName.
Эти элементы могут содержать атрибут realName - декодированные из MIME части имени или комментарий адреса.
Если поле содержит несколько адресов, то создаётся несколько XML элементов, так, что каждый элемент содержит ровно один адрес.

Отметки времени: Date, Resent-Date

Эти элементы содержат:
атрибут timeShift - разница в секундах между местным временем, указанным в поле, и соответствующим GMT временем.
атрибут localTime, указывающий значение времени поля (в формате iCalendar) в часовом поясе, выбранном для текущего пользователя.
Телом элемента является глобальное значение времени поля (GMT) в формате iCalendar.

Pty

Телом этих элементов являются строки High или Low. Эти значения преобразовываются в числовые значения (и из числовых значений) поля заголовка X-Priority.

Phones: X-Telnum

Тело элемента является телефонным номером.
Эти элементы могут содержать атрибут type (WORK, CELL, HOME, AGENT и т.п.), указывающий на тип телефонного номера/адреса.
Если поле содержит несколько телефонных номеров, то создаётся несколько XML элементов, так, что каждый элемент содержит ровно один телефонный номер.

Unstructured

Все поля, не перечисленные в предыдущих категориях, относятся к этой категории.
Тело элемента содержит декодированное из MIME значение поля.

Пример:

From: «Mr. Sender.» <user1@example.com> 
To: user2@example.com (My Friend), 
 =?iso-8859-1?Q?=4Eot=20A=20Friend?= <user2@example.com> 
Date: Mon, 10 Apr 2006 13:15:48 -0700 
Subject: It's 1:15PM now, the meeting has started!

<EMail> 
  <From realName=«Mr. Sender.»>user1@example.com</From> 
  <To realName=«My Friend»>user2@example.com</To> 
  <To realName=«Not A Friend»>user3@example.com</To> 
  <Bcc>user1@example.com</Bcc> 
  <Date timeShift=«-25200» localTime=«20060410T151548»>20060410T201548Z</Date> 
  <Subject>It's 1:15PM now, the meeting has started!</Subject> 
</EMail>

MIME

XML элемент представляет тело сообщения или его часть (далее в этом разделе - "часть").

Атрибуты:partID

эта строка указывает размещение части MIME в сообщении. Она может использоваться для получения части сообщения.

estimatedSize

ориентировочный размер (в байтах) данных части, после декодирования её данных.

type

тип части Content-Type, без информации о подтипе.

subtype

подтип части Content-Type, если есть.

charset

кодировка части (если отсутствует, то подразумевается UTF-8).

contentID

строка Content-ID (не заключённая в угловые скобки).

disposition

строка Content-Disposition (без параметров).

description

строка Content-Description.

location

строка Content-Location.

class

строка Content-Class после удаления префиксов urn: и content-classes:.

Type-name

любой параметр name поля Content-Type и его значение, за исключением параметров boundary, charset и format.

Disposition-name

любой параметр name поля Content-Disposition и его значение.

Тело:

Тело элемента не является обязательным. Если оно присутствует, оно содержит данные тела части. 
Если Сервер не смог прочитать данные тела части элемента, то к элементу добавляется атрибут readError. Значение атрибута содержит код ошибки чтения. 
Если Сервер не смог разобрать данные тела части элемента, то к элементу добавляется атрибут parseError. Значение атрибута содержит код ошибки разбора. 
Формат элемента зависит от части Content-Type (символ "*" ниже обозначает любой Content-Type или подтип):

multipart/*

Ноль или более элементов XML MIME, в которых содержатся подчасти сообщения.

message/rfc822

Элемент XML EMail для вложенного сообщения.

text/rfc822-headers

Элемент XML EMail (не содержащий никакого элемента тела MIME).

text/directory, text/x-vcard

Ноль или более элементов XML vCard.

text/x-vgroup

Один элемент XML vCardGroup.

text/calendar

элемент XML iCalendar.

message/disposition-notification, message/delivery-status

элемент XML MIMEReport.

*/xml, */*+xml

Данные XML элемента тела.

text/*

Декодированный текст сообщения, в котором все символы конца строки заменены на символ Перевода Строки (0x0A).

Обратите внимание: Когда присылается сообщение, запрошенное операцией folderRead, тело элемента MIME включается только если:

• его Content-Type - один из поддерживаемых типов, перечисленных выше

• его Content-Disposition не равен attachment

• его размер плюс размер частей, уже включённых в данные XML ответа, не превышает значения атрибута запроса totalSizeLimit.

Пример:

From: <user1@example.com> 
To: user2@example.com 
MIME-Version: 1.0 
Content-Type: multipart/alternative;boundary=«abcd» 
Content-Description: Test Message 

--abcd 
Content-Type: text/plain; charset=«iso-8859-1»; 
format=flowed; paramX=«valueX» 
Content-Transfer-Encoding: quoted-printable 

=46rom where I stay, I can see & hear a lot! 

--abcd 
Content-Type: text/html; charset=«iso-8859-1» 
Content-Transfer-Encoding: quoted-printable 

<html><body bgcolor=3D«yellow»> 
<I>From where I stay</I>, I can see &amp; hear a lot! 
</body></html> 
--abcd--

<EMail> 
  <From>user1@example.com</From> 
  <To>user2@example.com</To> 
  <MIME Type=«multipart» subtype=«alternative» Description=«Test Message»> 
    <MIME type=«text» subtype=«plain» charset=«iso-8859-1» type-paramX=«valueX»> 
      From where I stay, I can see &amp; hear a lot! 
    </MIME> 
    <MIME type=«text» subtype=«html» charset=«iso-8859-1» type-paramX=«valueX»> 
    &lt;html&gt;&lt;body bgcolor=&quot;yellow&quot;&gt; 
    &lt;I&gt;From where I stay&lt;/I&gt;, I can see &amp;amp; hear a lot! 
    &lt;/body&gt;&lt;/html&gt; 
    </MIME> 
  </MIME> 
</EMail>

MIMEReport

Этот элемент XML элемент представляет сообщение с отчётом, таким как Оповещение об Открытии (Disposition Notification) или Отчёт о Доставке.

Атрибуты:

отсутствуют

Тело:

набор элементов XML, в которых содержатся поля заголовка отчёта, такие как Reporting-MTA, Final-Recipient и т.п.
а также (необязательно) элементы MIMEReport для тела отчёта.

Пример:

Subject: Delivery report: TEST - disposition and delivery 
From: <MAILER-DAEMON@remote.example.com> 
To: <sender@local.example.com> 
Date: Wed, 02 May 2007 00:33:13 -0700 
Message-ID: <receipt-39457791@remote.example.com> 
X-MAPI-Message-Class: REPORT.IPM.Note.DR 
MIME-Version: 1.0 
Content-Type: multipart/report; report-type=«delivery-status»; boundary=«_===39457791====remote.example.com===_» 


--_===39457791====remote.example.com===_ 
Content-Type: text/plain; charset=«utf-8» 

Message delivered to '<recepient@remote.example.com>' 
LOCAL module(account recepient) reports: 
Delivered to the user mailbox 


--_===39457791====remote.example.com===_ 
Content-Type: message/delivery-status 

Reporting-MTA: dns; remote.example.com 

Original-Recipient: rfc822;<recepient@remote.example.com> 
Final-Recipient: LOCAL;<recepient> 
Action: delivered 
Status: 2.0.0 

--_===39457791====remote.example.com===_ 
Content-Type: text/rfc822-headers 

From: «Sender Name» <sender@local.example.com> 
Subject: TEST - disposition and delivery 
To: recepient@remote.example.com 
X-Mailer: CommuniGate Pro WebUser v5.1.9 
Date: Wed, 02 May 2007 00:35:51 -0700 
Message-ID: <web-3990004@local.example.com> 
MIME-Version: 1.0 
Disposition-Notification-To: <sender@local.example.com> 
Content-Type: text/plain;charset=«utf-8»;format=«flowed» 
Content-Transfer-Encoding: 8bit 

--_===39457791====remote.example.com===_--

<EMail> 
 <Subject>Delivery report: TEST - disposition and delivery</Subject> 
 <From>MAILER-DAEMON@communigatepro.ru</From> 
 <To>sender@local.example.com</To> 
 <Date localTime=«20070502T003313» timeShift=«-25200»>20070502T073313Z</Date> 
 <Message-ID>&lt;receipt-39457791@remote.example.com&gt;</Message-ID> 
 <X-MAPI-Message-Class>REPORT.IPM.Note.DR</X-MAPI-Message-Class> 
 <MIME estimatedSize=«1433» subtype=«report» type=«multipart» Type-report-type=«delivery-status»> 
  <MIME charset=«utf-8» estimatedSize=«120» partID=«01» subtype=«plain» type=«text»>Message delivered to &#39;&lt;recepient@remote.example.com&gt;&#39; 
LOCAL module(account recepient) reports: 
 Delivered to the user mailbox 

  </MIME> 
  <MIME estimatedSize=«158» partID=«02» subtype=«delivery-status» type=«message»> 
   <MIMEReport> 
    <Reporting-MTA>dns; remote.example.com</Reporting-MTA> 
    <MIMEReport> 
     <Original-Recipient>rfc822;&lt;recepient@remote.example.com&gt;</Original-Recipient> 
     <Final-Recipient>LOCAL;&lt;recepient&gt;</Final-Recipient> 
     <Action>delivered</Action> 
     <Status>2.0.0</Status> 
    </MIMEReport> 
   </MIMEReport> 
  </MIME> 
  <MIME estimatedSize=«787» partID=«03» subtype=«rfc822-headers» type=«text»> 
   <EMail> 
    <From realName=«Sender Name»>sender@local.example.com</From> 
    <Subject>TEST - disposition and delivery</Subject> 
    <To>recepient@remote.example.com</To> 
    <X-Mailer>CommuniGate Pro WebUser v5.1.9</X-Mailer> 
    <Date localTime=«20070502T003551» timeShift=«-25200»>20070502T073551Z</Date> 
    <Message-ID>&lt;web-3990004@local.example.com&gt;</Message-ID> 
    <Disposition-Notification-To>sender@local.example.com</Disposition-Notification-To> 
   </EMail> 
  </MIME> 
 </MIME> 
</EMail>

Доступ по протоколу HTTP

Некоторые клиенты могут не поддерживать выполнение всех операций через протокол XIMSS. При создании сессии XIMSS, её идентификатор направляется клиенту обратно в сообщении с данными session. Сервер обеспечивает доступ к этой сессии через протокол HTTP.

Получение части сообщения

Для получения любой части сообщения, видимого в любом текущем открытом представлении Папки может использоваться следующий URL:

/Session/sessionID/MIME/folder/UID-partID-suffix[/filename]

где

sessionID

идентификатор текущей сессии XIMSS, присланный в сообщении с данными session.

folder

имя Представления папки или Календаря

UID

UID сообщения в Представлении папки или в Календаре.

partID

идентификатор запрашиваемой части MIME сообщения. Это строка в элементе XML MIME при получении сообщения с использованием операции folderRead. Если необходимо получить всё сообщение, то строка partID и следующий за ней символ - должны быть опущены.

suffix

режим получения:

• P.txt - получается полностью недекодированная часть (включая заголовки и тело).

• H.txt - получается часть с заголовками.

• B.extension - получается тело декодированной части. Вы можете использовать любое подходящее расширение имени файла. Ответ на запрос HTTP содержит Content-Type полученной части MIME.

• R/cid - строка cid должна быть URI-кодированной. Её декодированное значение указывает Content-ID части MIME. Сервер ищет все части MIME, "связанные" с текущей, и получает тело той части, у которой совпадает Content-ID.
  Эта возможность используется для преобразования URL типа cid: в сообщения в формате HTML.

filename

необязательное имя файла. Оно игнорируется сервером, но помогает браузеру пользователя сохранять файл с правильным именем.

Примеры:

C:GET /Session/1-2xklkdld8-djdkjk/MIME/INBOX/567-01-B.gif HTTP/1.1

C:GET /Session/1-2xklkdld8-djdkjk/MIME/INBOX/567-02-01-B.gif/Logo.gif HTTP/1.1

Возможно получить только порцию части сообщения при использовании заголовков HTTP Range. Если заголовки запроса не могут быть указаны, возможно использование следующих параметров строки запроса:

OffsetFrom

позиция (в байтах) начала порции (0 означает начало части).

OffsetTill

(необязательно) позиция (в байтах) байта, следующего за концом запрошенной порции.

Пример:

C:GET /Session/1-2xklkdld8-djdkjk/MIME/INBOX/567-01-B.gif?OffsetFrom=100&OffsetTill=200 HTTP/1.1

По этому запросу возвращается 100 байт (100..199 включительно) из файла в формате GIF, закодированного в указанной части MIME сообщения.

Получение данных о пользователе

С помощью запроса по указанному URL можно получить публичные данные пользователя или любой их атрибут:

/Session/sessionID/PROFILE/[propertyname[/index][/filename]]

где

sessionID

идентификатор текущей сессии XIMSS, присланный в сообщении с данными session.

propertyname

имя атрибута vCard, например, PHOTO. Если атрибут не указать, считывается объект vCard целиком.

index

если объект vCard содержит несколько значений для указанного атрибута vCard, можно указать порядковый номер (начиная с 0). Значение индекса принимается равным 0, если параметр не указан.

filename

любая строка, кодированная как URL.

Пример:

C:GET /Session/1-2xklkdld8-djdkjk/PROFILE/PHOTO/0/avatar HTTP/1.1

Этим запросом можно получить значение первого элемента атрибута «PHOTO» из объекта vCard публичных данных Пользователя.

Загрузка файла на сервер

Следующий URL может использоваться для загрузки файла на сервер в «набор загруженных файлов» сессии.

/Session/sessionID/UPLOAD/uploadID

где

sessionID

идентификатор текущей сессии XIMSS, присланный с сообщением данных session.

uploadID

строка, идентифицирующая этот файл в «наборе загруженных файлов».

Запрос по протоколу HTTP должен быть сделан:

• методом POST, с содержимым формата multipart/form-data, элемент fileData которого включает бинарное представление загружаемого файла, или

• методом PUT, с бинарным представлением загружаемого файла в теле запроса.

Когда файл загружается на сервер и добавляется к «набору загруженных файлов», Сервер возвращает код ответа 200. Если операция загрузки закончилась неуспешно, Сервер возвращает код ответа 500.

Загруженный файл сохраняется вместе с его значением Content-Type.

Если «загруженный набор файлов» уже содержит файл с заданным значением uploadID, то старый файл удаляется.

Скачивание файла

Следующий URL может использоваться для скачивания файла из Хранилища Файлов Пользователя сессии.

/Session/sessionID/DOWNLOAD/fileName

где

sessionID

идентификатор текущей сессии XIMSS, присланный с сообщением данных session.

fileName

имя файла в Хранилище Файлов Пользователя.
Обратите внимание: для того, чтобы загрузить файл из «набора загруженных файлов», указывайте fileName как

Экспортирование данных

Запросом на следующий URL можно экспортировать данные из папки или календаря:

/Session/sessionID/Export/folderName/fileName[?oldStyle=1]

Если folderName является именем открытого объекта Calendar, запрос извлекает текст в формате iCalendar, включающий все объекты VEVENT и VTODO, со всеми использованными в них объектами VTIMEZONE.
Если folderName является именем открытого Представления Папки, запрос извлекает текст в формате vCard, включающий все объекты vCard из объектов в этом Представлении Папки. При указании параметра oldStyle данные vCard экспортируются в формате vCard 2.1 и кодировке UTF-8, иначе используются формат vCard 3.0 и кодировка Unicode.

Экспортирование закрытого ключа и сертификата

Запросом на следующий URL можно экспортировать Закрытый Ключ и Сертификат Пользователя в формате PKCS12 (файл "PFX"):

/Session/sessionID/CertAndKey.pfx?PFXPassword=password[&PFXPassword1=password1]

Если указан параметр PFXPassword1, его значение должно быть таким же, как у параметра PFXPassword.
Данные S/MIME в сессии должны быть разблокированы.
Закрытый Ключ и Сертификат Пользователя помещаются файл в формате PKCS12, зашифрованный с помощью значения параметра PFXPassword.

Аварийное прекращение сессии

Следующий URL может использоваться для прекращения сессии без процедур очистки:

/Session/sessionID/KILL