Re: Пожалуйста, объясните про PUBLISH

On Tue, 21 Nov 2006 16:28:29 +0600
  "Victor Sudakov" <CGatePro@mx.ru> wrote:
> Коллеги,
>
> X-Lite моего визави посылает запрос методом PUBLISH, в теле запроса
> PIDF, в котором написано например Away или Idle.
>
> Должен ли этот PUBLISH доходить до моего UA?
Нет.

> Пока я вижу, что до моего
> UA доходит не PUBLISH, а NOTIFY, в котором тело переписано
> Communigate-ом по своему усмотрению.

Да.

> Это так и должно быть, или SIP
> proxy должен просто довести PUBLISH-запрос до моего UAS, не внося в
> запрос изменений?

Нет.

Работает это так. Если аккаунт. У него - 20 endpoints (телефоны, прогграммки, что угодно). Теперь некоторые устройства решают воспользоваться неким "Event Package". Например, presence. Но - могут и любым другим поддерживаемым сервером.

Для чего начинают слать в сервер PUBLISH. Заметим, что именно сервер является адресатом (собственный аккаунт). На что внутри данных "event package" для этого аккаунта сервер создает "сегменты" - у каждого устройства свой сегмент. Имена сегментов возвращаются клиентам, так что они в дальнейшем могут обновлять свои данные, а не плодить новые сегменты (поля SIP-ETag в запросах PUBLISH).

В результате имеем в аккаунте 10 сегментов для 10 устройств этого аккаунта. Далее влючаются мозги сервера. При кажом изменении сегмента (и при удалении-добавлении оного), он данные из всех сегментов "аггрегирует". Для presence алгоритм в общих чертах такой: если все away - то away, если хоть один online- то online, если хоть где-то Busy - то Busy.

А если бы пакет был не "presence", а "money", и каждое устройсто (кошелёк) сообщало бы сколько в нём денег - то функция аггрегирования была бы просто арифметической суммой значений в каждом сегменте (с конвертацией валют :-).

В случае пакета presence есть еще одна заморочка CGatePro - а аккаунта могут быть залогиненные XIMSS и XMPP клиенты. Каждый из которых тоже рассказывает серверу о своих presence. Это никуда не записывается, но сервер считает "общий презенс" и для них - всех активных клиентов этого аккаунта. А результирующий "presence" - это аггрегация (по той же формуле) SIP-презенаса и этого XMISS-XMPP презнеса. Ежели Вы откроете WebAdmin и войдете в этот аккаунт, в закладку Status - то увидите все задействованные Event Packages и все сегменты с их значениями. А в верху будет указано аггрегированное значение, для Presence - два: по сегментам, и с учетом XIMSS/XMPP клиентов. Теперь - с другой стороны. Кому-то хочется увидеть чей-то Presence. Или еще что-то. Для этого он посылает SUBSCRIBE на данный аккаунт с указанием event package (например, presence). Сервер смотрит на это дело, и в зависимости от package - либо отвергает запрос (не аутентицирован, нет прав - например, Вы не сможете подписаться на мой "reg" package - чтобы следить за моими register), либо подписывает без вопросов, либо ставит в лист ожидания, либо (в случае presence) смотрит в Roster (Buddy List) и либо отвергает, либо принимает, либо ставит в ожидание.

Когда подписка установлена, то каждое изменение *аггрегированного* значения package приводит к рассылке NOTIFY всем подписчикам. Именно аггрегированного. То есть если у меня два телефона, и на одном я говорю - то есть статус его и аггрегированый - Busy - то чтобы ни происходило со вторым - аггрегированный статус не поменяется, и никаких NOTIFY посылаться не будет.

В SUBSCRIBE клиент пишет, какие форматы данных он понимает. Их для одного package может быть много. Например, для Presence CGatePro понимает 5 - включая 2(или 3?) разных Микрософтских, сделанных, видимо, разными группами, о существовании друг друга (как и о существовании головного офиса где-то в Америке) не подозревавшими.

Когда создается NOTIFY, то смотрится, что за форматы этот клиент понимает. Если сервер поддерживает более одного из указанных клиентом форматов - то тут уж сервер сам выбирает, что ему больше нравится.

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

> RFC3903 читал, но ответ на данный вопрос не нашёл.
> Заранее спасибо за разъяснения.

Пожалуйста. А что, eyeBeam опять что-то не понимает в посланном ему NOTIFY? они там периодически что-то "правят", оно, соответственно, то потухнет, то погаснет. Логи бы.   

> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:sudakov@sibptus.tomsk.ru

Sincerely,
Vladimir Получено Tue Nov 21 19:51:27 2006