On Tue, 21 Nov 2006 16:28:29 +0600
Post by Victor SudakovКоллеги,
X-Lite моего визави посылает запрос методом PUBLISH, в теле запроса
PIDF, в котором написано например Away или Idle.
Должен ли этот PUBLISH доходить до моего UA?
Нет.
Post by Victor SudakovПока я вижу, что до моего
UA доходит не PUBLISH, а NOTIFY, в котором тело переписано
Communigate-ом по своему усмотрению.
Да.
Post by Victor SudakovЭто так и должно быть, или 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 по аггрегированному значению всех сегментов,
даже если есть только один сегмент.
Post by Victor SudakovRFC3903 читал, но ответ на данный вопрос не нашёл.
Заранее спасибо за разъяснения.
Пожалуйста. А что, eyeBeam опять что-то не понимает в посланном ему NOTIFY?
они там периодически что-то "правят", оно, соответственно, то потухнет, то
погаснет. Логи бы.
Post by Victor Sudakov--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Sincerely,
Vladimir