On Thu, 20 Oct 2005 03:35:46 +0400
"Vitaly Kirillov" <CGatePro@mx.ru> wrote:
> VAB> Нет, но и не запрещено.
> Если не трудно, то расскажите поподробнее. Есть ли в RFC прямой ответ
> на вопрос о том, как должен поступить сервер, если юзер не может
> принять сообщение прямо сейчас? Нужно отказать, положить в буфер, или
> сделать что-то еще?
Если Вы про стандартный IM, (который просто метод MESSAGE - ВНЕ ВСЯКИХ сессий), то он обрабатывается так же, как обрабатывается любой другой SIP метод - см. RFC3261. То есть подолбились во все указанные места, не достучались - вернули ответ. Причем быстро - не более 30 секунд ждем.
С другой стороны, INVITE работает точно так же - и любой звонок, который не может быть принят - отвергается. Никаких "voicemail" ни в каком стандарте нету.
Другое дело, что некий сервер в некий момент, увидев, что дело швах - или еще по какой причине (ничего это в стандартах нет) может направить звонок куда-нибудь еще. Например, как делает это CGatePro: если этот сервер сам был ответственен за target AOR - то есть звонили на его собственный аккаунт gg@cgatepro.dom , а не на zzz@somewhere.com - и звонок не был отвечен в течении указанного времени (либо вообще нет регистраций - некуда слать) - то CGatePro может "подсунуть" в AOR стек Signal Module следующий адрес zzzz#gg@cgatepro.dom, который будет обработан как запрос на запуск PBX программы zzzz от имени gg@cgatepro.dom. Которая может и ответить на этот звонок. А может и послать (например, увидев отсутствие аутентикации).
Никакого отношения это к стандартам не имеет. По стандарту - если запрос не дошел, то возвращается ошибка.
Что делать с юзером, который в Off-line с точки зрения presence - это совсем отдельная песня. Например, если у Вас есть SIP телефон, который presence не поддерживает - то Вы в off-line. Можно Вам посылать IM? Шут его знает. Но обычно те, кто делает IM - делают и Presence. И если делают его правильно, то всё будет работать. Пока, например, eyeBeam не сломали - то они через CGatePro вполне так общались с Windows Messenger в части presence.
Опять же, Вы можете захотеть:
а) указать серверу, что если у Вас есть активная регистрация, то чтобы
сервер делал вид, что Вы ему сообщили presence "online" (это если у Вас
клиент без Presence, а хочется)
б) сказать серверу, что ежели приходит MESSAGE (IM), а ответить на него Вы не можете (нет зарегистрированного, работающего, да еще и поддерживающего IM клиента), то принять мессаж, и послать его адресату как E-mail. Лучше - начать таки PBX сессию, в которой сказать на тот конец - "эта, меня немае, телефон сломат, говорит холодильник - всё, что вы мне наговорите будет записано и пришлепнуто к моей дверце" - то есть сделать некий диалог через IM, который бы позволил записывать не один мессаж, а уж сразу всё, что человек хотел сказать - раз ему так лениво запустить майлер.
Опять же всё это - никакого отношения к стандартам не имеет. Стандарты только говорят о том, как две "SIP Entity" говорят друг с дружкой. Понятие же "SIP Server" - вообще отсутствует. Те орлы, что писали SIP, имели гениальную идею избавиться от серверов вообще - мол, есть только простенькие proxy, а все "мозги" - исключительно в клиентах. То, что эта идея, мягко говоря, неумна - очевидно: сервер - это "мой представитель" в сети, я хочу в ней быть даже когда меня (моих клиентов) в ней физически нет.
Но одно из следствий этой "гениальной идеи" - то, что никаких "server-side features" Вы - практически - ни в одном стандарте не найдете.
> VAB> Можете так назвать. Но если все клиенты работают правильно, то зачем
> VAB> посылать сообщение кому-то, кто действительно в оффлайн?
>
> Т.е. веяние идет от Микрософта? То, к чему все давно привыкли решили
> взять и забрать.
> Пользователи ICQ/Jabber/Yahoo и пр., вы заблуждались, теперь вам эта
> фича не нужна, одумайтесь.
> Некоторые из причин:
> 1. Пользователь может поставить "invisible", т.е. не желает чтобы его
> видели в онлайне, однако сообщения принимать хочет.
> 2. Удобно хранить всю историю переписки с человеком в одном клиенте,
> независимо от того, в онлайне или офлайне находился в конкретный
> момент времени.
> 3. Намного проще обстоит дело со спамом. По крайне мере на текущий момент.
> 4. Не всегда корректно работает передача статусов.
>
> Кроме того, Windows Messenger не дает позвонить человеку если тот в
> оффлайне - это вообще никуда не годится. Может я хочу надиктовать
> сообщение в голосовой почтовый ящик или сервер поддерживает только
> голый SIP т.е. не умеет обрабатывать статусы.
Есть такой адрес: bill.gates@microsoft.com. Направлять Ваши претензии по
поводу его продуктов сюда - немного не по адресу, не находите?.
WM хорош только тем, что:
а) работает.
б) умеет делать вещи КРОМЕ IM и Voice/Video - например, shared whiteboard,
remote assistance.
То, что и voice в нем отвратный (без хачанья registry там даже кнопочек нет - как с приложениями работать), видео - вообще смешное, а IM - так себе - никто и не спорит. Возьмите клиент, который лучше.
> VAB> Хм. Умеет. Это называется E-mail. Который тем и отличается от IM. И
>Windows
>кому-то,
А при чем тут? CGatePro глубоко фиолетово, в каком presence состоянии находится клиент. IM и presence СТАНДАРТАМИ никак не связаны. Если Вы пошлете message на юзера, который в offline, то он пойдет на все его зарегистированные клиенты, и если один из них ответит OK - то всё будет OK. А вот если никто не ответит - то надо либо отвечать Вам "увы нам, увы" - либо делать приложение, которое будет эти Message кушать и что-то с ними делать - см. выше.
> Почему нужно решать за пользователя, что он хочет сделать в настоящий
> момент - e-mail или IM?
*МЫ* это не решаем. Если Вы воспользовались клиентом с такой "парадигмой" - то, наверное, Вам имеет смысл поменять клиентскую программу.
> VAB> Что такое "новый Yahoo"? у них у всех - самоделки, "основан на SIP" -
>это то
>формой напоминают.
>http://andyabramson.blogs.com/voipwatch/2005/05/yahoo_is_upgrad.html
Ну хорошо. Вот, например, Микрософт и его Windows Messenger и LCS. Там таки
действительно SIP. За "небольшими" исключениями:
а) все мессажи должны быть "подписаны". При помощи чего, и что именно - как
понятно, никто не сказал.
б) для любого профессионального использования устройства как телефона в нем
должен работать call transfer. А он у них работает. Только требует, чтобы в
запросе был хедер "Refer-Cookie". C КАКИМ-ТО содержимым. Каким - опять же,
никто не сказал.
Ну и как это - SIP или не SIP? Учтем, что проблему #1 мы таки решили, но это
лишь значит, что мы поддерживаем "SIP" и "Микрософтовский SIP".
> VAB> Сыграло. Но Гугл пока - это тоже самоделка, так как никакого доступа
>наружу
> Best regards,
> Vitaly mailto:kv@aha.ru
Sincerely,
Vladimir
Получено Thu Oct 20 06:17:19 2005
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:14:16 MSK