On 10/21/10 12:20 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierla<mico...@gmail.com>:
Hi, I don't agree. SIP end-to-end presence fails when coming to
privacy area as the watcher doens't receive the information from a
server, but from the watched user itself (so the watcher knows if it's
"online" or not). I've tryed end-to-end SIP presence and IMHO is just
a toy.
this kind of privacy is affecting the calls as well, for example. I can send
you a call or other SIP request to discover you are online/offline. So this
is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
Good point. But the fail about this point is in SIMPLE specs.
The fail is the SIP steering group, which divided to many subgroups
which don't actually interact one with another. SIMPLE group looks as
SIP as being the protocol only for im & p.
With xmpp, at least so far, there is the same group taking care of
everything.
I'm planning a spec for privacy rules in which a user stores in a
server privacy attributes for each contact in his buddylist. These
privacy attributes include "presence", "dialog", "voice", "im" along
with filtering rules (for example, I want to show my presence status
online/offline to a watcher, but I don't want to show him my
geolocation data).
So when an INVITE or SUBSCRIBE arrives to the proxy/server, the
privacy rules for this contact can be inspected so the presence/dialog
SUBSCRIBE or the INVITE (voice, video, MSRP) can be allowed, rejected
or "polite" blocked (480 User Not Online).
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending<presence> stanzas. XMPP
basic presence (online, offline and text note) works in this way. This
is, a XMPP client gets online and sends<presence> stanza to all its
non-blocked contacts to inform about its presence status.
However, other presence features in XMPP as the avatar, advanced
presence (like the music you are listening now), work with
publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it:
http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP.
So IMHO this mechanism is the most suitable also for SIP, but it must
be improved (the specs and features).
With a model where client and server must develop in parallel you have
always the chicken-egg problem.
But retrieving the contact avatar works in XMPP, doesn't it? :)
Never tried to look deep at it :-) , probably the xmpp client does it ok.
On the other hand, this is just exchange of content, like voice call is.
I can send to my peer a link to a web resource from where to download,
or, the clients can start a machine-to-machine session for a file
transfer. This actions are done upon my agreement on what to allow for
the other peer, whether I decided to store the rules locally or used a
remote storage engine like xcap or http server.
I don't like my provider to control everything related to my person. I
may have different avatars for different persons or locations.
While I said that some interaction between endpoint and core network has to
be done (e.g., centralized rooster, hosting avatars, etc), it must be pretty
much content agnostic. When the core network becomes an active player in the
final content delivery of what I send, then innovation is slowed down
considerably.
Imagine you have 30 contacts. Having 30 presence subscriptions for
each client is not very cool. This is solved with RLS subscription.
Indeed you reduce some traffic from client to server, but add complexity
and limitations to the core of the network.
I see a business case for such services, where you get value-added
features from the core. They exist for voice as well (e.g., transforming
your voice). If the provider offers it and I want it, I can opt in.
But end-to-end freedom of communication must exist. Presence update is a
communication to the other peer. Like we do with calls, e.g., permanent
redirect, there can be static rules for im and presence. But
requiring/imposing support of some functionality and control from core
network would not be successful in long term.
The concept is good but the final specification is a pain as it
requires a painful XCAP document pointintg to a painful list in a
painful resource-list document, along with exotic constrains (the
client must create a SIP URI unique in the server).
Now also imagine "distribute presence". You have 30 contacts. When you
get online you must send 30 presentities for all your allowed
contacts. Not very cool IMHO.
The server sends 30 notifies, so you save half of the communication.
There is a feature called parallel forking, we can branch a request in
as many destinations as we want. That doesn't imply states on server,
just a list stored in db.
And worse: Not all the information a watcher wants to retrieves
depends on the watched user itself. The avatar, the user profile (a
vCard) is retrieved from the server (this is true in XMPP, MSN,
Skype....), so "distribute presence" cannot work here. So, should we
implement two mechanims for retrieving buddy's information (one for
realtime presence status and other for permanent information stored in
the server? I don't think this is a good design.
I will comment separately later, this is getting big.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
