Re: подписка на presence

От: Samarit <CGatePro_at_mx_ru>
Дата: Wed 02 May 2007 - 20:21:50 MSD

Vladimir A. Butenko wrote:
> On Wed, 02 May 2007 15:43:44 +0400
> "Samarit" <CGatePro@mx.ru> wrote:
>

>>> Cервер ожидает от клиента управления подпиской при помощи:
>>> а) XMPP
>>> б) XIMSS
>>> в) WebUser
>>> и, наконец, самое
>>> г) через SIP, при помощи доморощенных Microsoft-методов. Которые не 
>>> документированы, и которыми пользоваться не следует никому.
>>>
>>> Увы.
>>>  
>>
>>
>> А возможно ли в качестве SIP workaround сделать отсылку таким клиентам 
>> не NOTIFY (из package presense.winfo), a SUBSCRIBE (из package 
>> presense)? на такие запросы X-lite вроде как отвечает notify'ем.

>
> Так это будет точка-точка presence - это мало того,что не интересно, это
> еще и приводит к большому увеличению подписок (если у каждого много
> агентов), плюс - никакой аггрегации. Вот у меня два устройства - на
> одном Busy, на другом - online. Если пустить это напрямую, то Ваш агент
> должен будет не только обе подписки держать, но еще и аггрегироват их
> сам - чего он делать не будет, естественно.
>

Я имел в виду не совсем это, а как бы гибридное использование. T.e. сервер когда получает subscribe от watcher'a предназначеный для контакта   у которого User-Agent: X-Lite* или eyeBeam*, шлет такому контакту не NOTIFY, a SUBSCRIBE. Далее если он получает в ответ от хотя бы одного клиента NOTIFY (From: To: status - open) то сервер решает что подписка одобрена и в ростер пользователя помещает status - active), a если status - closed, то в ростер - deny. После чего сервер снова шлет subscribe с expires 0, т.е. отписывается от дальнейших notify со стороны клиента. И шлет Notify с Event: presense.winfo где статус становится active. А вот дальше как положено: клиент шлет publish на сервер и всем заинтересованным лицам уходят Notify с Event: presense.winfo с агрегацией и т.д.
Т.е. такой воркараунд для обмана клиентского ПО в виде опции с определением типа user agent.

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

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

Тоже верно. Но наверно можно реализовать в виде правил? т.е. если URI вида *@domain.com, то можно, иначе нет или например только из своего домена. По крайней мере сделать чтоб ростером можно было управлять администратору (через веб или CLI - сейчас это, как я понимаю, никак не настраивается).

>> Попутно еще вопрос: планируется ли сделать поддержку XCAP(когда он 
>> станет стандартом) в CGP и будут ли resource-lists,presrules 
>> интегрированы с roaster? (утверждается что eyeBeam это дело поддерживает)

>
> Да, будут. Лет через 15, когда Великие Творцы SIP выдавят из себя хоть
> какие-то стандарты. Пока они путаются в тех трёх соснах, которые сами
> понастроили.
> И если уж делать этот XCAP - то он все равно другой протокол - так
> почему тогда не XMPP/XIMSS использовать и не ждать?
>

в XMPP - на сколько я знаю пока нет стандартов на установление мультимедийных сессий, каждый решает проблему по своему (как например google talk)
XIMSS - желающих сделать чисто XIMSS клиент вряд ли много. SIP - реализаций полно, толковых мало :(

>> Евгений Туровский
>>

>
> Sincerely,
> Vladimir
Получено Wed May 02 16:20:17 2007