20 Oct
2010
20 Oct
'10
3:51 p.m.
---------- Forwarded message ----------
From: Elwell, John <john.elwell(a)siemens-enterprise.com>
Date: Wed, Oct 20, 2010 at 9:45 AM
Subject: Re: [dispatch] proposed SIXPAC charter
To: Peter Saint-Andre <stpeter(a)stpeter.im>im>, "dispatch(a)ietf.org"
<dispatch(a)ietf.org>
I find this a worthwhile topic to pursue. I had been wondering whether
this activity would turn out to be more of a profiling exercise, and
whether the IETF might not be the best choice of venue for such work.
From the current draft charter it looks like there will
be at least
some protocol extension work, for which I believe the IETF is the
correct venue. On the other hand, the Unified Communications
Interoperability Forum (UCIF) is seeking to advance the state of play
on XMPP interoperability, and if we were just talking about a profile
or BCP, that might have been a better venue. Perhaps the IETF should
focus on requirements and protocol extensions, and consider whether
the BCP work would be better done elsewhere. Or at least, there should
be some coordination with other activities relating to XMPP
interoperability.
John
-----Original Message-----
From: dispatch-bounces(a)ietf.org
[mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre
Sent: 19 October 2010 21:17
To: dispatch(a)ietf.org
Subject: [dispatch] proposed SIXPAC charter
Earlier this year, some folks in the RAI area proposed an
initiative to
define a few small extensions to both SIP and XMPP that would make it
easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on
feedback provided on the DISPATCH list and received from the RAI ADs,
I've taken the liberty of rewriting the proposed charter, in the hopes
that fresh text will spur a more conclusive discussion. I'm
mostly just
trying to help the proponents put their best foot forward, so if folks
here have more feedback I'd expect that people like Simo Veikkolainen
and Emil Ivov will be able to engage in further discussion.
/psa
###
SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
==============================================================
===========
Problem Statement
Both the Session Initiation Protocol (SIP) and the Extensible
Messaging
and Presence Protocol (XMPP) are widely deployed technologies for
real-time communication over the Internet. In order to offer
a complete
suite of features as well as communication across multiple networks,
several user-oriented software applications support both SIP and XMPP,
and more software developers have expressed interest in building such
"dual-stack" solutions. Unfortunately, it is difficult to provide a
good end-user experience in such applications because SIP and XMPP are
not aware of each other. For example:
- XMPP presence does not include availability states related to a SIP
voice call or video call (e.g., "on the phone"), thus preventing an
a dual-stack endpoint from showing presence-based
communication hints
- There is no correlation between an XMPP IM session and a SIP voice
or video session, thus preventing a dual-stack endpoint
from providing
integrated user interfaces and communications history
- SIP accounts and XMPP accounts are not directly correlated
in contact
lists or vCards (and not all deployed services support
storage of such
information), thus preventing a dual-stack endpoint from
knowing that
a contact has both SIP and XMPP capabilities
Although some proprietary solutions exist to the foregoing
problems, it
would be preferable to define standardized solutions for the sake of
improved interoperability.
Objectives
Because both SIP and XMPP are easily extended through new SIP headers
and XMPP elements, it should be possible to provide tighter
integration
within dual-stack SIP/XMPP user agents to improve the user experience.
Any such extensions should meet the following criteria:
- Be completely optional and backwards-compatible for all endpoints
- Work without changes to deployed infrastructure such as existing
SIP and XMPP servers, B2BUAs, firewalls, etc.
The SIXPAC WG will define a small number of SIP and XMPP extensions to
solve the following use cases in dual-stack endpoints:
- Including SIP-based availability states in XMPP presence (limited to
basic presence and availability states only, not the full range of
PIDF extensions)
- Correlating an XMPP IM session with a SIP voice/video session, and
vice-versa
- Advertising a SIP account address over XMPP and an XMPP account
address over SIP
Additional use cases are out of scope, including anything
related to or
requiring server integration, multiparty communication, SIP-based IM
and presence, XMPP-based voice and video, file transfer, generalized
service discovery and capabilities exchange, full protocol translation
in communication gateways, shared credentials across both SIP and XMPP
accounts, rich presence extensions for features such as geolocation,
etc. Although such topics are important and interesting, they are out
of scope for this group.
However, in addition to the protocol extensions explicitly mentioned
above, the group may also define best practices related to the
implementation and deployment of dual-stack SIP/XMPP endpoints,
including topics such as user agent configuration.
Deliverables
- Use cases and protocol requirements
- XMPP presence extension for SIP-based availability states
- Media session correlation extensions for SIP and XMPP
- Contact address advertisement extensions for SIP and XMPP
- Best practices for implementation and deployment of dual-stack
endpoints
Milestones
Feb 2011 Submit use cases and protocol requirements document to
IESG (Informational)
Oct 2011 Submit XMPP presence extension document to IESG
(Standards Track)
Oct 2011 Submit media session correlation extensions document to IESG
(Standards Track)
Oct 2011 Submit contact address advertisement extension document to
IESG (Standards Track)
Oct 2011 Submit best practices document to IESG (Informational)
###
_______________________________________________
dispatch mailing list
dispatch(a)ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--
Victor Pascual Ávila
20 Oct
20 Oct
4:11 p.m.
2010/10/20 Victor Pascual Avila <victor.pascual.avila(a)gmail.com>om>:
I find this a worthwhile topic to pursue. I had been
wondering whether
this activity would turn out to be more of a profiling exercise, and
whether the IETF might not be the best choice of venue for such work.
From the current draft charter it looks like there will be at least
some protocol extension work, for which I believe the IETF is the
correct venue. On the other hand, the Unified Communications
Interoperability Forum (UCIF) is seeking to advance the state of play
on XMPP interoperability, and if we were just talking about a profile
or BCP, that might have been a better venue. Perhaps the IETF should
focus on requirements and protocol extensions, and consider whether
the BCP work would be better done elsewhere. Or at least, there should
be some coordination with other activities relating to XMPP
interoperability.
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that
some work is being done in this area confirms the failure of SIMPLE.
IMHO it's better to define a new specification for presence in SIP
*from scratch* forgetting all about SIMPLE (all means all).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:38 p.m.
El Wed, 20 Oct 2010 13:11:22 +0200
Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
2010/10/20 Victor Pascual Avila
<victor.pascual.avila(a)gmail.com>om>:
Anyways, integrating such new specification with xmpp with extensions, gws or
whatever method is a win-win strategy.
I find this a worthwhile topic to pursue. I had
been wondering whether
this activity would turn out to be more of a profiling exercise, and
whether the IETF might not be the best choice of venue for such work.
From the current draft charter it looks like there will be at least
some protocol extension work, for which I believe the IETF is the
correct venue. On the other hand, the Unified Communications
Interoperability Forum (UCIF) is seeking to advance the state of play
on XMPP interoperability, and if we were just talking about a profile
or BCP, that might have been a better venue. Perhaps the IETF should
focus on requirements and protocol extensions, and consider whether
the BCP work would be better done elsewhere. Or at least, there should
be some coordination with other activities relating to XMPP
interoperability.
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that
some work is being done in this area confirms the failure of SIMPLE.
IMHO it's better to define a new specification for presence in SIP
*from scratch* forgetting all about SIMPLE (all means all).
5:57 p.m.
2010/10/20 Jon Bonilla <manwe(a)aholab.ehu.es>es>:
El Wed, 20 Oct 2010 13:11:22 +0200
Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
IMHO it's a surrender. XMPP is doing nothing (at
protocol/specifications level) to "integrate" with SIP. Istead they
are developing VoIP features from scratch.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
"Integrating" XMPP into SIP is a
workaround IMHO, but the fact that
some work is being done in this area confirms the failure of SIMPLE.
IMHO it's better to define a new specification for presence in SIP
*from scratch* forgetting all about SIMPLE (all means all).
Anyways, integrating such new specification with xmpp with extensions, gws or
whatever method is a win-win strategy. 
21 Oct
21 Oct
1:21 p.m.
On 10/20/10 2:57 PM, Iñaki Baz Castillo wrote:
2010/10/20 Jon Bonilla<manwe(a)aholab.ehu.es>es>:
I think it is just failure of one model
over-complicated, the Presence
Agent.
SIP has also end-to-end presence and it was/is working perfect in most
of the cases. What is missing there is the ability to store/receive
buddy list, but that can be fixed easy (via xcap or not).
Initially, SIP started as a protocol for end to end communication, where
the power was in endpoint's hands. Later, when telcos and mobile
operators came in, new standards were written to move "intelligence" in
the core network, with the principle "smart core stupid endpoints". If
you look at classic telephony, the devices are very cheap, even 5 bucks,
suitable to pick up the receiver and just accept call or dial, no other
functionality.
This was the wrong bet the big telephony companies did. The last years
proved indubitable that people like smart tools in their hands -- look
at smart phones market grow.
Another bad prediction was bandwidth in mobile networks. I remember the
times when "sip compression" was seen as the only and mandatory solution
to have -- just look at the specs for it and you can understand that PA
specs are maybe nicer. SIP messages are less than 1% of a voice call,
not to mention video where you can just completely ignore the signaling.
In presence and im, SIP is a part of communication, but again, not much
savings.
To have a future, the endpoints should have the power. Migration to voip
happened because everyone wants just a carrier (IP network) and
services, not a control of the network on capabilities of endpoints.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
El Wed, 20 Oct 2010 13:11:22 +0200
Iñaki Baz Castillo<ibc(a)aliax.net> escribió:
IMHO it's a surrender. XMPP is doing
nothing (at
protocol/specifications level) to "integrate" with SIP. Istead they
are developing VoIP features from scratch. "Integrating" XMPP into SIP is a
workaround IMHO, but the fact that
some work is being done in this area confirms the failure of SIMPLE.
IMHO it's better to define a new specification for presence in SIP
*from scratch* forgetting all about SIMPLE (all means all).
Anyways, integrating
such new specification with xmpp with extensions, gws or
whatever method is a win-win strategy.
2:20 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I think it is just failure of one model
over-complicated, the Presence
Agent.
SIP has also end-to-end presence and it was/is working perfect in most of
the cases.
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.
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).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:38 p.m.
Hello,
On 10/21/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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.
I think it is just failure of one model
over-complicated, the Presence
Agent.
SIP has also end-to-end presence and it was/is working perfect in most of
the cases.
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. 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.
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.
If you think about very popular solutions for real time communication
out there, the patters is smart endpoint, dummy core network, and in
most of the cases (skype, yahoo), same provider for both sides.
Telephony providers must understand they have to come with services
provided by them in order for me to pay. If they put barriers because
they want to charge the services I am capable alone to do, then I skip them.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
2:57 p.m.
Daniel-Constantin Mierla writes:
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.
i agree and i implemented xcap_auth_status() function just in order to
be able apply xcap rules also to MESSAGEs and INVITEs. there should be
different events for those though.
-- juha
3:09 p.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
There is no invite-rules neither message-rules specifications for
XCAP, neither for XDM (OMA additions), just pres-rules. So we would
end implementing a supposed "standard" but always introducing custom
specifications to make it "logical". Then clients should also
implement these custom extra layers of specs in order to interoperate
properly.
When it's required to add custom specifications it means that:
- The core "standard" specifictions are not good or not enough.
- Interoperability will be a pain.
For me SIMPLE/XCAP is dead many months ago.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
i agree and i implemented xcap_auth_status() function just in order to
be able apply xcap rules also to MESSAGEs and INVITEs. there should be
different events for those though.
6:11 p.m.
On 10/21/10 12:09 PM, Iñaki Baz Castillo wrote:
2010/10/21 Juha Heinanen<jh(a)tutpro.com>om>:
There is no invite-rules neither message-rules
specifications for
XCAP, neither for XDM (OMA additions), just pres-rules. So we would
end implementing a supposed "standard" but always introducing custom
specifications to make it "logical". Then clients should also
implement these custom extra layers of specs in order to interoperate
properly.
When it's required to add custom specifications it means that:
- The core "standard" specifictions are not good or not enough.
- Interoperability will be a pain.
For me SIMPLE/XCAP is dead many months ago.
if ever it was really born :-)
Still there are some good concepts that can be re-used.
I see xcap as a service offered by the telephony provider, maybe in the
way CPL was designed and somehow forgotten -- iirc, with CPL you can
block users.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
i agree and i
implemented xcap_auth_status() function just in order to
be able apply xcap rules also to MESSAGEs and INVITEs. there should be
different events for those though.
3:20 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Good point. But the fail about this point is in SIMPLE specs.
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).
But retrieving the contact avatar works in XMPP, doesn't it? :)
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. 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. 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.
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.
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.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:35 p.m.
On 10/21/10 12:20 PM, Iñaki Baz Castillo wrote:
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.
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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.
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. 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).
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.
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. 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. 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
7:15 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
There is a lot to discuss about it, even more than the sum of RFC's
about SIMPLE XD
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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
Then blocking a user not to view your avatar is not possible. Sending
the image into a SIP message (as XMPP mainly does) is better IMHO.
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 have a non very powerful phone, why should you send me advanced
presence information if my device cannot render it? will you send a
photo to my Linksys ATA? why should I receive information I'm not
capable of rendering? why should I receive information I haven't
asked?
As I said before, XMPP solves this problem with publish-subscribe
mechanism when coming to advanded presence (not just "online - I'm at
home").
Subscriptions (including filters in the subscription) can help with
this. Sending direct presence doesn't allow it. XMPP confirms this.
I don't like my provider to control everything
related to my person. I may
have different avatars for different persons or locations.
This is not impossible with centralized logic IMHO.
But end-to-end freedom of communication must exist.
Presence update is a
communication to the other peer.
Only if such peer has asked you for such information, am I wrong?
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.
Yes, but as I said before, how can a watcher get information from you
when you are offline (this is, you cannot send such information from
your device to the watcher)?
Couldn't the watcher get your vcard or your avatar neither your
offline status information? if this feature makes sense (and IMHO it
does as exists in all the IM/presence protocols) how to implement it
without subscription?
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.
So then I cannot filter some information to some specific watchers
(i.e: I want a specific watcher not to see my geolocation).
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.
8:23 p.m.
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
There was not at all a discard of subscriptions. That must exist, the
discussion was who and how should handle subscriptions.
Do you get my ring-back tone from my phone when you call and I am
offline? You get the voicebox service which I set for such cases. For
presence you may get as well a pre-defined state or document.
Like with voicemail, I can record a message and say "Hi, you called XYZ,
leave the message..." or simple "Leave the message after...". Same I can
publish my vcard for such cases or not, combined with black-white lists,
the privacy can be controlled in the same way for all SIP based services.
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
If you mean that by current specs, could be. I was referring to what
seems better for me. Any kind of end-to-end content exchange should be
processed by end device rules.
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
Then blocking
a user not to view your avatar is not possible. Sending
the image into a SIP message (as XMPP mainly does) is better IMHO.
I send to you because you asked. If you don't subscribe to that
resource, I don't send it.
Where did you get the I idea that everything is sent to everybody?
On the other hand, if your phone subscribes to my shoes-size-changes, my
phone can notify you using 2d barcode payload, but the server does not
know how to mix it, would you feel better paying NNNN bucks for the
device and the provider tells you it is not supported?
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 have a non very powerful phone, why should you send me
advanced
presence information if my device cannot render it? will you send a
photo to my Linksys ATA? why should I receive information I'm not
capable of rendering? why should I receive information I haven't
asked?
I have also many questions why you have such questions now. Nobody is
sending anything if not asked.
As I said before, XMPP solves this problem with
publish-subscribe
mechanism when coming to advanded presence (not just "online - I'm at
home").
Again, this is not presence specific, imo. If I call you and you are not
registered, I get to your voicemail, or to your mobile, or ... If I am
not online and you ask for my presence, the request can be replied with
some default/predefined states.
When I become online, I have my list of buddies and take care to tell them.
Subscriptions (including filters in the subscription)
can help with
this. Sending direct presence doesn't allow it. XMPP confirms this.
Centralize logic should be the routing, not the content of
communication. That can come extra, as additional service, if I want to
opt in for it.
For me, a man-in-the-middle like presence server trying to understand
everything would be like an English voice analyzer on server for each
call dropping everything that couldn't be understood as good English. So
if you want to talk with your parents and the provider does not support
Spanish, you have two options:
- screw the provider
- tell your parents by snail mail they have to use english when in a
call with you
I don't like my provider to control
everything related to my person. I may
have different avatars for different persons or locations.
This is not impossible
with centralized logic IMHO. But end-to-end
freedom of communication must exist. Presence update is a
communication to the other peer.
Only if such peer has asked you for such
information, am I wrong? 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.
Yes, but as I said before, how can a
watcher get information from you
when you are offline (this is, you cannot send such information from
your device to the watcher)? Couldn't the watcher get your vcard or your avatar
neither your
offline status information? if this feature makes sense (and IMHO it
does as exists in all the IM/presence protocols) how to implement it
without subscription?
If your client is able to send such details, then it has the list with
who is allowed and disallowed.
As I said, this list can be stored on server, so you can retrieved. But
I do not see the reason why the server must know what my client can
publish and to mix/process it.
Rooting the debate:
- subscription mechanism is good, the bad part now is who interprets it
- storing various resources, being it your voicemail message, redirect
number, white-black lists, is an useful service
- all signaling optimization attempts were big failures (see sip
compression)
- today, more than ever, trends are for smart end devices
- to be successful, a new technology has to be _simple_ : easy to
implement and use, without complex dependency constraints to deploy
Failing again to see that by time an "optimization" spec is implemented,
the bandwidth and processing power are far ahead, may be a safe bet for
disaster.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
So then I cannot filter some information to some specific watchers
(i.e: I want a specific watcher not to see my geolocation).
8:24 p.m.
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
There was not at all a discard of subscriptions. That must exist, the
discussion was who and how should handle subscriptions.
Do you get my ring-back tone from my phone when you call and I am
offline? You get the voicebox service which I set for such cases. For
presence you may get as well a pre-defined state or document.
Like with voicemail, I can record a message and say "Hi, you called XYZ,
leave the message..." or simple "Leave the message after...". Same I can
publish my vcard for such cases or not, combined with black-white lists,
the privacy can be controlled in the same way for all SIP based services.
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
If you mean that by current specs, could be. I was referring to what
seems better for me. Any kind of end-to-end content exchange should be
processed by end device rules.
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
Then blocking
a user not to view your avatar is not possible. Sending
the image into a SIP message (as XMPP mainly does) is better IMHO.
I send to you because you asked. If you don't subscribe to that
resource, I don't send it.
Where did you get the I idea that everything is sent to everybody?
On the other hand, if your phone subscribes to my shoes-size-changes, my
phone can notify you using 2d barcode payload, but the server does not
know how to mix it, would you feel better paying NNNN bucks for the
device and the provider tells you it is not supported?
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 have a non very powerful phone, why should you send me
advanced
presence information if my device cannot render it? will you send a
photo to my Linksys ATA? why should I receive information I'm not
capable of rendering? why should I receive information I haven't
asked?
I have also many questions why you have such questions now. Nobody is
sending anything if not asked.
As I said before, XMPP solves this problem with
publish-subscribe
mechanism when coming to advanded presence (not just "online - I'm at
home").
Again, this is not presence specific, imo. If I call you and you are not
registered, I get to your voicemail, or to your mobile, or ... If I am
not online and you ask for my presence, the request can be replied with
some default/predefined states.
When I become online, I have my list of buddies and take care to tell them.
Subscriptions (including filters in the subscription)
can help with
this. Sending direct presence doesn't allow it. XMPP confirms this.
Centralize logic should be the routing, not the content of
communication. That can come extra, as additional service, if I want to
opt in for it.
For me, a man-in-the-middle like presence server trying to understand
everything would be like an English voice analyzer on server for each
call dropping everything that couldn't be understood as good English. So
if you want to talk with your parents and the provider does not support
Spanish, you have two options:
- screw the provider
- tell your parents by snail mail they have to use english when in a
call with you
I don't like my provider to control
everything related to my person. I may
have different avatars for different persons or locations.
This is not impossible
with centralized logic IMHO. But end-to-end
freedom of communication must exist. Presence update is a
communication to the other peer.
Only if such peer has asked you for such
information, am I wrong? 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.
Yes, but as I said before, how can a
watcher get information from you
when you are offline (this is, you cannot send such information from
your device to the watcher)? Couldn't the watcher get your vcard or your avatar
neither your
offline status information? if this feature makes sense (and IMHO it
does as exists in all the IM/presence protocols) how to implement it
without subscription?
If your client is able to send such details, then it has the list with
who is allowed and disallowed.
As I said, this list can be stored on server, so you can retrieved. But
I do not see the reason why the server must know what my client can
publish and to mix/process it.
Rooting the debate:
- subscription mechanism is good, the bad part now is who interprets it
- storing various resources, being it your voicemail message, redirect
number, white-black lists, is an useful service
- all signaling optimization attempts were big failures (see sip
compression)
- today, more than ever, trends are for smart end devices
- to be successful, a new technology has to be _simple_ : easy to
implement and use, without complex dependency constraints to deploy
Failing again to see that by time an "optimization" spec is implemented,
the bandwidth and processing power are far ahead, may be a safe bet for
disaster.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
So then I cannot filter some information to some specific watchers
(i.e: I want a specific watcher not to see my geolocation).
8:35 p.m.
Daniel-Constantin Mierla writes:
I send to you because you asked. If you don't
subscribe to that
resource, I don't send it.
if all intelligence is in the UA, how about subscriptions themselves?
do i need to receive them even when my UA does not implement SUBSCRIBE
request or i don't want to get spammed by them from unknown sources?
in my opinion, some control in the network is useful especially when i
have to pay per volume on my mobile device.
-- juha
8:53 p.m.
On 10/21/10 5:35 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
This is sorted out by location server. iirc, you implemented the
filtering based on allowed methods.
I send to you because you asked. If you don't
subscribe to that
resource, I don't send it.
if all intelligence is in the UA, how about
subscriptions themselves?
do i need to receive them even when my UA does not implement SUBSCRIBE
request or i don't want to get spammed by them from unknown sources? in my opinion, some control in the network is useful
especially when i
have to pay per volume on my mobile device.
Going beyond the above consideration
where a solution already exists and
it is in place for many years, my concern was how long pay-per-volume
will last thinking of current smart phone market pressure that worth to
make a complex design costing fortunes to implement (e.g., IMS) and how
much will turn in profit for a narrow niche.
There are other services sending shorter or longer notifications heavily
used on mobiles, e.g., twitter, facebook. People are using them more
than any presence system. Skype is largely used as well, with no
intelligence in the network for processing the content.
Therefore, in the context of Inaki's building new specs for presence,
the near future predictions and current market trends must play a major
role.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
9:16 p.m.
Daniel-Constantin Mierla writes:
This is sorted out by location server. iirc, you
implemented the
filtering based on allowed methods.
yes, that takes care of sending subscribe to ua that does not support
it. the sad thing is that there are UAs on the marker that don't
advertise their supported methods in register request.
Going beyond the above consideration where a solution
already exists and
it is in place for many years, my concern was how long pay-per-volume
will last thinking of current smart phone market pressure that worth to
make a complex design costing fortunes to implement (e.g., IMS) and how
much will turn in profit for a narrow niche.
just today i heard in radio news that some operators who currently have
flat rate data service are planning to go for metered one. they claim
that with current flat rates, it is not possible to keep on upgrading
mobile network capacity. i don't think that vodafone, for example, is
offering flat rate data service anywhere in the world. i hope that i'm
wrong, but i would not at this stage count on flat rate mobile data.
and it is not just the cost, i simply don't want to get SIP spammed by
unauthorized sources.
-- juha
9:29 p.m.
On 10/21/10 6:16 PM, Juha Heinanen wrote:
This is true (ie, some mobile operators limiting the flat rate), but the
main reason is voice/video communication over 3g, bypassing their voice
services, whatever they say publicly.
Regarding the spam, I guess it would be more annoying to get calls from
unauthorized sources, so should be no difference between authorizing
voice, im, presence or something else via sip.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Daniel-Constantin Mierla writes:
Fortunately is more present than xcap support and even better, easier to
implement.
This is sorted out by location server. iirc, you
implemented the
filtering based on allowed methods.
yes, that takes care of sending subscribe to
ua that does not support
it. the sad thing is that there are UAs on the marker that don't
advertise their supported methods in register request. Going beyond
the above consideration where a solution already exists and
it is in place for many years, my concern was how long pay-per-volume
will last thinking of current smart phone market pressure that worth to
make a complex design costing fortunes to implement (e.g., IMS) and how
much will turn in profit for a narrow niche.
just today i heard in radio news that
some operators who currently have
flat rate data service are planning to go for metered one. they claim
that with current flat rates, it is not possible to keep on upgrading
mobile network capacity. i don't think that vodafone, for example, is
offering flat rate data service anywhere in the world. i hope that i'm
wrong, but i would not at this stage count on flat rate mobile data.
and it is not just the cost, i simply don't want to get SIP spammed by
unauthorized sources.
8:37 p.m.
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
[...]
There is a lot to discuss about it, even more than the
sum of RFC's
about SIMPLE XD
The problem with specs is like in life with ideas. Each of us has
many
ideas but either they prove unrealistics on a second thought or even
they seem good sometime there is no enough time to implement all.
These specs are like ideas written down and published.
Back to first paragraph. Are XMPP, MSN, Skype doing processing to these
documents, or are they just pure storage systems for them with a
white/black list access policy? In other words, I can publish my vcard
and then tell the server if X ask for it, don't send my email address,
just my web site address?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
9:20 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Back to first paragraph. Are XMPP, MSN, Skype doing
processing to these
documents, or are they just pure storage systems for them with a white/black
list access policy? In other words, I can publish my vcard and then tell the
server if X ask for it, don't send my email address, just my web site
address?
In both XMPP and MSN the avatar and vcard are retrieved by a watcher
from the server if the watched gives the watcher permissions, so the
server *does* interpret the permissions rules in behalf of the user.
How to achieve this logic in a non-centralized architecture? I cannot
imagine it.
So, if we assume that the "server" must be active part on the
subscription (it must interpret permissions and know about
subscriptions) then, why to implement in other way (direct/end-to-end
presence) presence status retrieval when the watched user is online?
two mechanisms?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:45 p.m.
On 10/21/10 6:20 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Maybe is a misunderstanding here. Hope you haven't understood that there
will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources.
Authorizations rules exist and we apply them for many years for voice
calls. But we don't authorize typically the content (e.g., not allowed
to speak Spanish on a call).
Back to first paragraph. Are XMPP, MSN, Skype
doing processing to these
documents, or are they just pure storage systems for them with a white/black
list access policy? In other words, I can publish my vcard and then tell the
server if X ask for it, don't send my email address, just my web site
address?
In both XMPP and MSN the avatar and vcard are retrieved by a watcher
from the server if the watched gives the watcher permissions, so the
server *does* interpret the permissions rules in behalf of the user.
How to achieve this logic in a non-centralized architecture? I cannot
imagine it. So, if we assume that the "server" must be
active part on the
subscription (it must interpret permissions and know about
subscriptions) then, why to implement in other way (direct/end-to-end
presence) presence status retrieval when the watched user is online?
two mechanisms?
Interpreting the permission of routing to a resource (being it my
vcard,
voicemail, my phone, etc) is there and should be reused. With some
phones you have DND on it, or with some services you have it in the
server (managed via ivr or web or a special key on the (Snom) phone
sending an update to server).
The problem right now is interpreting the content - presence information
is content. If the server does not understand the Event you subscribe
to, bye bye...
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
10:15 p.m.
Daniel-Constantin Mierla writes:
The problem right now is interpreting the content -
presence information
is content. If the server does not understand the Event you subscribe
to, bye bye...
i agree with that. in one sip ua is was not possible to configure
voicemail uri. it assumed that it is the same as ua's own uri and that
sip proxy is "smart" enough route the subscribe to user's voicemail
server based on "message-summary" in Event header. i argued that
requests should be routed by proxy on r-uri only. they accepted that
and made it possible to configure voicemail uri.
-- juha
10:37 p.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
i argued that requests should be routed by proxy on
r-uri only.
Hi, this is not true in all cases. For example when a user
sip:alice@dom.com sends a PUBLISH with presence information, the RURI
MUST also si sip:alice@dom.com, so if the proxy routes it to the
locations of Alice there would be a crazy loop.
The proxy must be ready to route a request not just based on the RURI
but also on the method and also on the Event type (a PUBLISH for
"presence" must be routed to the presence server while a PUBLISH for
"dialog" must be routed to some other server).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:55 p.m.
Iñaki Baz Castillo writes:
The proxy must be ready to route a request not just
based on the RURI
but also on the method and also on the Event type (a PUBLISH for
"presence" must be routed to the presence server while a PUBLISH for
"dialog" must be routed to some other server).
inaki,
method is part of first line and could be used for routing, but never
Event header, because then you are immediately in the situation that
where innovation is killed when proxy has not heard of event "foo".
-- juha
11 p.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
method is part of first line and could be used for
routing, but never
Event header, because then you are immediately in the situation that
where innovation is killed when proxy has not heard of event "foo".
Then how do you get the proxy routing "Event: presence" PUBLISH to a
server-1 and "Event: dialog" PUBLISH to server-2?
Also, innovation would also be killed in case the proxy receives an
initial request with unknown SIP method.
This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS...
but what should it do with CHICKEN? depending of the nature of the
method, it's important/required that the proxy knows it to route it
properly.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:04 p.m.
Iñaki Baz Castillo writes:
Then how do you get the proxy routing "Event:
presence" PUBLISH to a
server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported.
Also, innovation would also be killed in case the
proxy receives an
initial request with unknown SIP method.
This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS...
but what should it do with CHICKEN? depending of the nature of the
method, it's important/required that the proxy knows it to route it
properly.
i agree and therefore presence spec is badly broken when/if it says that
request uri in publish should the same as the uri of presentity.
request uri should be that of presence server for the event in question
and from header should tell whose presence is being published.
-- juha
11:08 p.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
Probably. Iasked exactly this question about PUbLISH and RURI in
sip-implementors and got the response I've told to you in my previous
mail.
The advantaje of PUBLISH having same RURI as From URI is the fact that
the client doesn't require to be provisioned with a "presence server
URI".
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Iñaki Baz Castillo writes:
Could you explain it please?
Then how do you get the proxy routing
"Event: presence" PUBLISH to a
server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported. Also,
innovation would also be killed in case the proxy receives an
initial request with unknown SIP method.
This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS...
but what should it do with CHICKEN? depending of the nature of the
method, it's important/required that the proxy knows it to route it
properly.
i agree and therefore presence spec is badly broken when/if it says that
request uri in publish should the same as the uri of presentity.
request uri should be that of presence server for the event in question
and from header should tell whose presence is being published.
11:20 p.m.
Iñaki Baz Castillo writes:
Could you explain it please?
there is not much to explain. request uri must tell where request is
routed. if that is not enough, then proxy needs to get involved with
application level stuff, which locks its use to well known
applications.
Then how do you get the proxy routing "Event:
presence" PUBLISH to a
server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported. The advantaje of PUBLISH having same RURI as From URI
is the fact that
the client doesn't require to be provisioned with a "presence server
URI".
yes, and the disadvantage is that proxy needs to be provisioned for all
possible events/headers people may ever invent, i.e., task impossible.
-- juha
11:24 p.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
IMHO inspecting a specific header (Event) when the request is PUBLISH
is not so much effort for a proxy. More below.
The fact is that I agree with you. But note that with REGISTER the
same occurs. It's very common an architecture in which the client is
just provisioned with a domain name, which resolved to its proxy, and
such proxy router the REGISTER to a registrar server (even if the RURI
of the REGISTER just contains the proxy's domain).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Could you
explain it please?
there is not much to explain. request uri must tell where request is
routed. if that is not enough, then proxy needs to get involved with
application level stuff, which locks its use to well known
applications. The advantaje
of PUBLISH having same RURI as From URI is the fact that
the client doesn't require to be provisioned with a "presence server
URI".
yes, and the disadvantage is that proxy needs to be provisioned for all
possible events/headers people may ever invent, i.e., task impossible.
11:41 p.m.
Iñaki Baz Castillo writes:
The fact is that I agree with you. But note that with
REGISTER the
same occurs. It's very common an architecture in which the client is
just provisioned with a domain name, which resolved to its proxy, and
such proxy router the REGISTER to a registrar server (even if the RURI
of the REGISTER just contains the proxy's domain).
rfc3261 allows that the ua is configured with address of registrar. in
fact, there are sip UAs that allow configuring registrar differently
from proxy. if proxy happens to know about registrar or some presence
events, it is good luck. you cannot assume it.
-- juha
22 Oct
22 Oct
12:19 a.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
rfc3261 allows that the ua is configured with address
of registrar. in
fact, there are sip UAs that allow configuring registrar differently
from proxy.
Yes, but isn't nicer provisioning a UA just with AoR, password and
domain letting DNS NAPTR/SRV and routing in the proxy to do their
magic? :)
if proxy happens to know about registrar or some
presence
events, it is good luck. you cannot assume it.
Typically if a provider offers presence service its proxy should be
ready for that.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:31 a.m.
Iñaki Baz Castillo writes:
Yes, but isn't nicer provisioning a UA just with
AoR, password and
domain letting DNS NAPTR/SRV and routing in the proxy to do their
magic? :)
you need to draw the line somewhere regarding how much magic proxy does
and knows about. there are many levels to it: method, event, content,
etc.
-- juha
12:56 a.m.
2010/10/21 Juha Heinanen <jh(a)tutpro.com>om>:
Until now, I've only needed routing logic based on method and event
(for PUBLISH). No more cases.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Yes, but
isn't nicer provisioning a UA just with AoR, password and
domain letting DNS NAPTR/SRV and routing in the proxy to do their
magic? :)
you need to draw the line somewhere regarding how much magic proxy does
and knows about. there are many levels to it: method, event, content,
etc.
1:39 a.m.
On 10/21/10 9:31 PM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
talking about provisioning, this is another PITA with SIP.
Why not providing just ip/domain, username and password? Then the reply
of 200ok for register can contain the other details, like SIP AoR,
outbound proxy address, even a new registrar address - first
registration to be just service discovery (maybe using a different
method first time). Simple format, keyword=value, if you understand the
keyword, use the value, otherwise ignore.
Ok, ok, I know the answer, according to RFC you can use the SIP phone
without a server and call by IP:port, so you have to be able to set your
own details. Right ... we all use it this way and it is very easy to do
such dialing with any of the hardware phones today...
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Yes, but isn't nicer provisioning a UA just
with AoR, password and
domain letting DNS NAPTR/SRV and routing in the proxy to do their
magic? :)
you need to draw the line somewhere regarding how much magic proxy does
and knows about. there are many levels to it: method, event, content,
etc.
21 Oct
21 Oct
10:34 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Daniel, after re-reading your mails I strongly think we agree more
than we think ;)
I also *hate* the mechanism in which the server MUST inspect the
document content in order to filter it and notify the watched with a
filtered version. This is a pain, and that is the base of SIMPLE in
which multiple presentities must be merged in the server, in which the
server must inspect the XML nodes of the resulting presentity and
filter it for each watched based on privady rules and deliver it via
NOTIFY. I hate it.
So what I have in mind is a different approach. Imagine this case:
- Alice has two active resources, both of them publishing basic
presence status ("online"/"busy".... "I'm at home" /
"I'm at work
very unhappy"). These PUBLISH have "Event: presence+status".
- There is also a geolocation presence agent which in some way get's
the registration location of both resources of Alice and generates two
PUBLISH "Event: presence+geolocation" (one in behalf of echa
resource).
- The server DOESN'T merge these 4 presentities. Instead it stores in
a database each one with fields "event", "content".
- Alice has a buddylist in the server in which there is a contact Bob
for which Alice allows showing him "presence+status" information, but
not "presence+geolocation".
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE
body he is interested in "presence+status" and "presence+geolocation"
events (as Bob's device doesn't understand/implement other presence
information and couldn't render it).
- The presence server accepts the subscription (as it checks in
Alice's buddylist that Bob is authorized for "Event: presence").
- The presence server also inspects in Alice's buddylist that Bob is
just allowed for "presence+status".
- So the presence server sends Bob just two NOTIFY's (never merging
documents), the first one containing the presecen+status of Alice's
resource-1 and the second one containing the presecen+status of
Alice's resource-2.
Advantages of this model:
- The server NEVER NEVER NEVER inspects the content of a PUBLISH.
- The subscriber (Bob) can tell the server which events he is
interested in (not to receive information it cannot render).
- The watched (Alice) can decide which events each watcher is allowed to.
Another subject is the permanent information (i.e. "vCard") which is
stored in the server. How the client (Alice) stores its vCard/avatar
into the server is out of the scope of this brief description, but for
sure we don't want XCAP. IMHO a new SIP method is required (in my idea
the new method STORE makes sense).
- Alice set privacy attributes for her buddy Bob, so it allows him to
watch these information:
- presence+status
- vcard
This information is stored within Bob buddy in Alice's buddylist (in
the server).
- Alice uses STORE method to store a vcard in the server.
- Now Bob subscribes to "Event: vcard" of Alice.
- The server inspects Alice's buddylist and finds that Bob is allowed
for retrieving the vcard of Alice.
- The server then sends Bob a NOTIFY containing the vCard of Alice.
- Alice's gets online and upload a new version of her vCard (or
changes it offline via web...).
- The server then sends Bob a new NOTIFY with the new vCard.
Does this fit better your concept of presence? :)
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
In both XMPP
and MSN the avatar and vcard are retrieved by a watcher
from the server if the watched gives the watcher permissions, so the
server *does* interpret the permissions rules in behalf of the user.
How to achieve this logic in a non-centralized architecture? I cannot
imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that there
will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations
rules exist and we apply them for many years for voice calls. But we don't
authorize typically the content (e.g., not allowed to speak Spanish on a
call).
11:39 p.m.
2010/10/21 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
- Bob susbcribes to Alice's presence by
*indicating* in the SUBSCRIBE
body he is interested in "presence+status" and
"presence+geolocation"
events (as Bob's device doesn't understand/implement other presence
information and couldn't render it).
Posible example of such SUBSCRIBE:
-------------------------
SUBSCRIBE sip:alice@dmain.com SIP/2.0
From: sip:bob@domain.net;tag=asdasd
Event: presence
Content-Type: application/subscription+json
{
"filter" : [ "status", "geolocation" ]
}
--------------------------
This tells the presnce server that the watched wants to subscribe to
"presence" event of Alice, but just for "status" and
"geolocation"
information (maybe called sub-events).
Just an idea.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
22 Oct
22 Oct
1:21 a.m.
On 10/21/10 7:34 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Daniel, after re-reading your mails I strongly think we agree more
than we think ;)
perhaps was more a misinterpretation of some of the comments send around
from different points :-) .
In both
XMPP and MSN the avatar and vcard are retrieved by a watcher
from the server if the watched gives the watcher permissions, so the
server *does* interpret the permissions rules in behalf of the user.
How to achieve this logic in a non-centralized architecture? I cannot
imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that
there
will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations
rules exist and we apply them for many years for voice calls. But we don't
authorize typically the content (e.g., not allowed to speak Spanish on a
call). I also *hate* the mechanism in which the server MUST
inspect the
document content in order to filter it and notify the watched with a
filtered version. This is a pain, and that is the base of SIMPLE in
which multiple presentities must be merged in the server, in which the
server must inspect the XML nodes of the resulting presentity and
filter it for each watched based on privady rules and deliver it via
NOTIFY. I hate it.
So what I have in mind is a different approach. Imagine this case:
- Alice has two active resources, both of them publishing basic
presence status ("online"/"busy".... "I'm at home" /
"I'm at work
very unhappy"). These PUBLISH have "Event: presence+status".
- There is also a geolocation presence agent which in some way get's
the registration location of both resources of Alice and generates two
PUBLISH "Event: presence+geolocation" (one in behalf of echa
resource).
- The server DOESN'T merge these 4 presentities. Instead it stores in
a database each one with fields "event", "content".
- Alice has a buddylist in the server in which there is a contact Bob
for which Alice allows showing him "presence+status" information, but
not "presence+geolocation".
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE
body he is interested in "presence+status" and
"presence+geolocation"
events (as Bob's device doesn't understand/implement other presence
information and couldn't render it).
- The presence server accepts the subscription (as it checks in
Alice's buddylist that Bob is authorized for "Event: presence").
- The presence server also inspects in Alice's buddylist that Bob is
just allowed for "presence+status".
- So the presence server sends Bob just two NOTIFY's (never merging
documents), the first one containing the presecen+status of Alice's
resource-1 and the second one containing the presecen+status of
Alice's resource-2.
Advantages of this model:
- The server NEVER NEVER NEVER inspects the content of a PUBLISH.
- The subscriber (Bob) can tell the server which events he is
interested in (not to receive information it cannot render).
- The watched (Alice) can decide which events each watcher is allowed to.
Another subject is the permanent information (i.e. "vCard") which is
stored in the server. How the client (Alice) stores its vCard/avatar
into the server is out of the scope of this brief description, but for
sure we don't want XCAP. IMHO a new SIP method is required (in my idea
the new method STORE makes sense).
- Alice set privacy attributes for her buddy Bob, so it allows him to
watch these information:
- presence+status
- vcard
This information is stored within Bob buddy in Alice's buddylist (in
the server).
- Alice uses STORE method to store a vcard in the server.
- Now Bob subscribes to "Event: vcard" of Alice.
- The server inspects Alice's buddylist and finds that Bob is allowed
for retrieving the vcard of Alice.
- The server then sends Bob a NOTIFY containing the vCard of Alice.
- Alice's gets online and upload a new version of her vCard (or
changes it offline via web...).
- The server then sends Bob a new NOTIFY with the new vCard.
Does this fit better your concept of presence? :)
Maybe we are poisoned by the
current specs and still are stuck in some
concepts here.
There are two aspects:
1) real time communication routing - voice, im, presence states
2) offline resource routing - vcard, predefined-content documents
1) can always have a correspondent in 2) while some things in 2) might
not be in 1).
Normally every user wants to do 1), but if the peer is offline, then
server can have the capability to re-route to corresponding resource in
2) (like now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand
resources. Do I need to get a notification that you changed your vcard
immediately you do it? I would say no, I need to do it when I need to
email, send a snail mail, etc. which may happen when you are offline so
the server storage comes in the picture and sends it to me upon my
request and your authorization rules for that resource. That can be done
very easy in the reply body, without a need to create a dialog state in
the server and send notifies.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
2:21 a.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
There are two aspects:
1) real time communication routing - voice, im, presence states
2) offline resource routing - vcard, predefined-content documents
1) can always have a correspondent in 2) while some things in 2) might not
be in 1).
Normally every user wants to do 1), but if the peer is offline, then server
can have the capability to re-route to corresponding resource in 2) (like
now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand
resources. Do I need to get a notification that you changed your vcard
immediately you do it? I would say no, I need to do it when I need to email,
send a snail mail, etc. which may happen when you are offline so the server
storage comes in the picture and sends it to me upon my request and your
authorization rules for that resource. That can be done very easy in the
reply body, without a need to create a dialog state in the server and send
notifies.
Interesting proposal. Let me some questions:
1)
- Alice has two active resources (alice-1and alice-2).
- alice-1 uploads a new vCard.
How is alice-2 notified about that change if there is no possibility
of subscription to the vcard?
2)
IMHO avatar should be part of the vCard (as vCard already includes
photo and so):
- Alice is subscribed to Bob's presence (just presence).
- Alice retrieves the vCard (including avatar) of Bob. But there is no
subscription as you said.
- Bob uploads a new version of his vCard with a new photo.
How is Alice being notified about the change to display the new avatar?
3)
Where is the limit to say "this info requires subscription but this one not"?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:37 p.m.
On 10/21/10 11:21 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Why it needs to be notified immediately? I haven't said that there is no
subscription, but for some cases are just kind of "stateless subscription".
Phone sends subscribe for a resource and gets the document in the reply
if allowed or a negative reply if not allowed. Timestamps can be used to
mark it has not be changed (like in http).
There are two aspects:
1) real time communication routing - voice, im, presence states
2) offline resource routing - vcard, predefined-content documents
1) can always have a correspondent in 2) while some things in 2) might not
be in 1).
Normally every user wants to do 1), but if the peer is offline, then server
can have the capability to re-route to corresponding resource in 2) (like
now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand
resources. Do I need to get a notification that you changed your vcard
immediately you do it? I would say no, I need to do it when I need to email,
send a snail mail, etc. which may happen when you are offline so the server
storage comes in the picture and sends it to me upon my request and your
authorization rules for that resource. That can be done very easy in the
reply body, without a need to create a dialog state in the server and send
notifies.
Interesting proposal. Let me some questions:
1)
- Alice has two active resources (alice-1and alice-2).
- alice-1 uploads a new vCard.
How is alice-2 notified about that change if there is no possibility
of subscription to the vcard? 2)
IMHO avatar should be part of the vCard (as vCard already includes
photo and so):
- Alice is subscribed to Bob's presence (just presence).
- Alice retrieves the vCard (including avatar) of Bob. But there is no
subscription as you said.
- Bob uploads a new version of his vCard with a new photo.
How is Alice being notified about the change to display the new avatar?
Avatar and
photo in vcard can be different, but anyhow, not the scope here.
In the light of useless traffic that can cost and not only that, would
it bring benefits that the avatar is updated in realtime by your
application even it is in standby and you don't want to communicate with
that user? Or the application is asking for updates when is some
activity related to that user? If there is no activity for a long time,
it can do a periodic refresh, anyhow many SIP mechanisms require
periodic actions.
3)
Where is the limit to say "this info requires subscription but this one not"?
All require subscriptions, but in many cases is no state associated
with, just one time pull of status/document. I haven't thought
thoroughly, but I hope the servers don't need to know subscription
states, only authorization rules, which are just stored documents and
should be generic, not a language related to presence, but authorization
for any kind of resources.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
2:54 p.m.
2010/10/22 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hi Daniel, any "subscription" mechanism means PULL: the subscriber is
informed *by the server* about changes, so the server notifies the
user. In case of SIP this is achieved with a NOTIFY.
But you are speaking about PUSH: the interested user sends a periodic
request to the server to get possible new changes. IMHO this cannot be
called "subscription" neither "stateless subscription".
So, when you say "Phone sends subscribe for a resource and gets the
document in the reply" I would prefer "Phone sends a like-GET request
for a resource and gets the document in the reply". There is no way in
SIP to retrieve data without using subscription (which means the data
is sent in the NOTIFY, never in the 200 to the SUBSCRIBE). But here we
can introduce a new SIP method, As I told before, STORE method could
be use for uploading content or retrieving it (depending on a header,
URI parameter or whatever stil to define).
Do we agree here? :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1)
- Alice has two active resources (alice-1and alice-2).
- alice-1 uploads a new vCard.
How is alice-2 notified about that change if there is no possibility
of subscription to the vcard?
Why it needs to be notified immediately? I haven't said that there is no
subscription, but for some cases are just kind of "stateless subscription".
Phone sends subscribe for a resource and gets the document in the reply if
allowed or a negative reply if not allowed. Timestamps can be used to mark
it has not be changed (like in http).
2)
IMHO avatar should be part of the vCard (as vCard already includes
photo and so):
- Alice is subscribed to Bob's presence (just presence).
- Alice retrieves the vCard (including avatar) of Bob. But there is no
subscription as you said.
- Bob uploads a new version of his vCard with a new photo.
How is Alice being notified about the change to display the new avatar?
Avatar and photo in vcard can be different, but anyhow, not the scope here.
In the light of useless traffic that can cost and not only that, would it
bring benefits that the avatar is updated in realtime by your application
even it is in standby and you don't want to communicate with that user? Or
the application is asking for updates when is some activity related to that
user? If there is no activity for a long time, it can do a periodic refresh,
anyhow many SIP mechanisms require periodic actions.
3)
Where is the limit to say "this info requires subscription but this one
not"?
All require subscriptions, but in many cases is no state associated with,
just one time pull of status/document. I haven't thought thoroughly, but I
hope the servers don't need to know subscription states, only authorization
rules, which are just stored documents and should be generic, not a language
related to presence, but authorization for any kind of resources.
4954
days inactive
4956
days old
40 comments
5 participants
participants (5)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Jon Bonilla -
Juha Heinanen -
Victor Pascual Avila