6 Oct
2009
6 Oct
'09
8:25 p.m.
Architectures of XMPP and SIMPLE (OMA specifications) for a full rich
presence environment:
- XMPP:
http://oversip.net/public/XMPP.jpeg
- SIMPLE (OMA):
http://oversip.net/public/SIP_SIMPLE_OMA.jpeg
--
Iñaki Baz Castillo <ibc(a)aliax.net>
6 Oct
6 Oct
8:28 p.m.
Iñaki Baz Castillo wrote:
Architectures of XMPP and SIMPLE (OMA specifications)
for a full rich
presence environment:
- XMPP:
http://oversip.net/public/XMPP.jpeg
- SIMPLE (OMA):
http://oversip.net/public/SIP_SIMPLE_OMA.jpeg
To be fair, that *is* a *bit* of an oversimplification of XMPP
mechanics. :-) But not much. I vote for XMPP.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
7 Oct
7 Oct
8:03 a.m.
New subject: [Kamailio-Users] SIMPLE vs XMPP: The Resolution
Iñaki Baz Castillo writes:
- SIMPLE (OMA):
http://oversip.net/public/SIP_SIMPLE_OMA.jpeg
why OMA? it is part of closed mobile operator walled garden that we
should have nothing to do with.
-- juha
11:48 a.m.
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
why OMA? it is part of closed mobile operator walled
garden that we
should have nothing to do with.
Yes, that's a good vision. The problem here is that IETF *didn't*
finish its work for SIMPLE and XCAP. Instead, IETF has published
half-done specifications.
I paste a mail I sent to IETF SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg08512.html
--------------------------------
After studying all the SIMPLE and XCAP stuff (and
implement part of it), I get a simple conclusion: XCAP and SIMPLE
specifications *don't* exist.
With it I mean that SIMPLE and XCAP (as specified by IETF) don't
provide a fixed and strict set of rules and specifications and it's
*impossible* to get interoperability. Some examples:
- RFC 5025 (pres rules) doesn't specify which is the default action to
perform is a watcher URI is not listed in the document.
- RFC 5025 doesn't clarify which should be the presence server
behavior if the same watcher URI appears in a rule with "allow" action
and also in a rule with "blocked" action. Which one has preference?
the first one? the second one?
- Again with RFC 5025: The pres-rules format is *really* wide and
ambiguous. There are 10000 ways to create a pres-rules document with
same meaning. It's *impossible* that two implementations could share
the same document. This is: vendor A softphone generates a valid
pres-rules document and uploads to the XCAP server. Vendor B softphone
(same SIP account) gets that document and, of course, it doesn't
understand it since it would use a completely different pres-rules
document format to get the same meaning.
I've realized that AG-Projects software implementing XCAP uses a
***custom*** pres-rules format based on 3 rules with id
"pres_whitelist" (action "allow"), "pres_blacklist" (action
"block")
and "pres_politeblocked" (action "politeblock"). Can I ask *why*?
just
because CounterPath softphones use a similar pres-rules format? This
is just a vendor specific format, no more. IETF doesn't specify it at
all so interoperability is not possible.
- In a presentity there can be a "note" element in various places:
- Inside the "tuple" section.
- Inside the "person" section.
- As a main element in the "presentity" element.
This is annoying and I've seen some implementations setting *all*
these "notes" with same text. But the fact is that nobody can know
which element will other implementation choose to show to the user.
- Resource list stuff: If a user adds a resource list in a pres-rules
rule the the presence server inspecting the pres-rules should also
read the resource-list. What about if the user modifies the
resource-list via XCAP? Then the XCAP server should notify a change to
the presence server in order it to inspect again the pres-rules. Does
IETF RFC's specify it? not at all.
So, what we have? nothing. We have a hyper-complex and ambiguous set
of specifications which don't provide interoperability at all. When I
read "this softphones implements XCAP" I understand "this softphone
implements XCAP so it works ONLY with same vendor's softphones, XCAP
server and presence server". Is this what we want?
OMA's XDM specification is a specification layer on top of XCAP/SIMPLE
documents which tries to create a fixed and strict subset of IETF
specifications in order to make it feasible for clients adoption. For
example it defines a very strict format for the pres-rules document.
It also defines the XCAP server behavior (XDMS server).
I really think that this should be a task of IETF rather than OMA. I
cannot understand why IETF has published such useless and half-done
documents, can I ask *why*?? sharing a simple budy list or privacy
rules is IMPOSSIBLE with IETF's specifications!!!. Anyhow this is what
we have.
Which should be the way to go? perhaps implement OMA's XDM specs?
(I've read XDM documents and they are designed to be SIP core agnostic
(valid for IMS or any kind of SIP core).
--------------------------------
If it's not clear in the quoted text, I also say that Kamailio
presence_xml module (that which reads the presrules document to
allow/disallow a subscription) doesn't follow the standard (since
there is no standard). Instead it follows its own rules (and these
rules could be different than a XCAP client expect, even if both
interpretations are valid according to XCAP RFC's).
Nowadays I'm reading OMA specifications. The *really* propose a good
and strict SIMPLE and XCAP (called XMD) specification. And this
specification is not just for IMS or mobile terminals, not at all,
it's SIP CORE agnostic, it's a set of specifications that can run in
*any* SIP environment.
Yes, I would prefer that IETF does its job and provides an usable,
feasible, strict and *interoperable* specifications, so common tasks
as sharing a buddy list or setting presence privacy rules could be
implemented by reading IETF documents. However it doesn't exist at all
in IETF world.
I paste a text appearing in OMA-RD-Presence_SIMPLE-V1_1-20080627-A.pdf:
---------------------------------------------------------------
4.1 OMA Presence Mandate
SIP/SIMPLE by IETF is accompanied with a set of Internet Drafts and
RFCs (such as RPID, Rich Presence Information Data
Format; CIPID, Contact Information in Presence Information Data
Format; and XCAP, XML Configuration Access
Protocol). 3GPP and 3GPP2 specify the practical implementations of
IETF specifications in IMS (IP Multimedia Subsystem)
and MMD (MultiMedia Domain) respectively. Both transport IP traffic
and use SIP as signalling protocol, and are commonly
known as SIP/IP Core. On top of all this, OMA SIMPLE presence service
specifications, developed in REQ and PAG WGs,
define a SIP/SIMPLE-based Presence Service.
The specifications mentioned above leave a number of degrees of
freedom open; for example, the tuples as defined by IETF
can be used any which way to convey Presence Information. Not even the
Presence Information content is specified. The
situation is akin to having a functioning phone line but no common
language between the conversing parties. This makes it
difficult to achieve interoperability between different vendor’s products.
OMA’s role is to create application level specifications for Presence
Service. This includes presence information semantics
and guidelines for presence applications, please see Figure 1. These
specifications shall be agnostic to the underlying network
technology, be it specified by 3GPP, 3GPP2, or by somebody else.
-----------------------------------------------------------------
So this is what we have. Nobody cares about SIP SIMPLE/XCAP and IETF's
specifications are not finished at all. So:
- We can create our own interpretation of IETF's documents (as
Kamailio's presence_xml module and OpenXCAP do) and create a
*propietary* implementation on top of half-done standards (even if
it's GPL software). And we end with our own rich presence capable
softphone, which only works with our own presence server and XCAP
server.
- Or we can follow a set of specifications on top of IETF RFC's made
by OMA, the only organization around the world which seems really
interested in SIP presence adoption.
Juha, I though as you but after trying to implement XCAP/SIMPLE
specifications I understood that it's *not* possible just with IETF's
docs. OMA specifications is the only good approach for the moment
(IMHO).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:42 p.m.
Iñaki Baz Castillo writes:
Yes, that's a good vision. The problem here is
that IETF *didn't*
finish its work for SIMPLE and XCAP. Instead, IETF has published
half-done specifications.
I paste a mail I sent to IETF SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg08512.html
inaki,
interesting reading. i haven't been on ietf mailing lists for quite
some time. perhaps there are no "ietf" people anymore left in ietf sip
related working groups, and they are currently only rubber stamping
oma/ims specifications. looks to be that way, because no-one responded
to your message.
i don't have anything against oma as long as they don't force me to use
a large number of walled garden servers (like is the case with ims),
whose only purpose is to milk the cow as many times as possible.
perhaps it thus makes sense to adopt from oma specs at least the xml
document specifications.
-- juha
3:57 p.m.
Juha Heinanen schrieb:
Iñaki Baz Castillo writes:
Using IMS/OMA on a technical basis does not require to adopt the telco's
business model.
E.g. IMS can be seen as an how-to achieve a scalable SIP infrastructure.
IMS defines lots of proxies (S-CSCF, P-CSCF, I-CSCF, ...), but in the
end it is a similar setup how big Kamailio installations are done today
e.g. load balancers, outbound proxy are similar to the P-CSCF, the
registrar is similar to the S-CSCF. Further, all the IMS components are
logical, functional components and you can also put all these components
into one node too.
Some people use direct DB backends, others use Radius, IMS uses Diameter
(more or less the same as Radius).
And, of course, no carrier/telco is forced to create its VoIP
infrastructure identical to the IMS defined architecture.
Probably IMS is a bit over engineered, but if you have big Kamilion (or
Asterisk) installations, you also end up with distributing the logical
components onto different nodes.
regards
klaus
Yes, that's a good vision. The problem here
is that IETF *didn't*
finish its work for SIMPLE and XCAP. Instead, IETF has published
half-done specifications.
I paste a mail I sent to IETF SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg08512.html
inaki,
interesting reading. i haven't been on ietf mailing lists for quite
some time. perhaps there are no "ietf" people anymore left in ietf sip
related working groups, and they are currently only rubber stamping
oma/ims specifications. looks to be that way, because no-one responded
to your message.
i don't have anything against oma as long as they don't force me to use
a large number of walled garden servers (like is the case with ims),
whose only purpose is to milk the cow as many times as possible.
perhaps it thus makes sense to adopt from oma specs at least the xml
document specifications.
-- juha
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
4:09 p.m.
Klaus Darilion writes:
Using IMS/OMA on a technical basis does not require to
adopt the telco's
business model.
klaus,
many years ago when i looked at ims, it placed lots of restrictions on
how request must be routed through the mace of proxies and what
information has to be transmitted between the proxies in order to be
able to bill the user many times by each participating operator. it was
not possible to place a call without being registered first, call
someone on the internet, etc. i don't think that any of that has
changed. i thus got the impression that telco business model was in
fact built-in in the interface specifications.
-- juha
4:12 p.m.
7 okt 2009 kl. 15.09 skrev Juha Heinanen:
Klaus Darilion writes:
Don't forget the IMS koncept of "SIP roaming" that doesn't fit the
IETF's view of life on Earth and the rest of the Universe.
Otherwise, I'm sure that we can get a lot of good stuff from both 3GPP
and OMA work. But far from all of it is useful. You have to be very
selective.
/O
Using IMS/OMA on a technical basis does not
require to adopt the
telco's
business model.
klaus,
many years ago when i looked at ims, it placed lots of restrictions on
how request must be routed through the mace of proxies and what
information has to be transmitted between the proxies in order to be
able to bill the user many times by each participating operator. it
was
not possible to place a call without being registered first, call
someone on the internet, etc. i don't think that any of that has
changed. i thus got the impression that telco business model was in
fact built-in in the interface specifications.
4:30 p.m.
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
inaki,
interesting reading. i haven't been on ietf mailing lists for quite
some time. perhaps there are no "ietf" people anymore left in ietf sip
related working groups, and they are currently only rubber stamping
oma/ims specifications. looks to be that way, because no-one responded
to your message.
i don't have anything against oma as long as they don't force me to use
a large number of walled garden servers (like is the case with ims),
whose only purpose is to milk the cow as many times as possible.
perhaps it thus makes sense to adopt from oma specs at least the xml
document specifications.
That's exactly my point Juha.
I would stop reading OMA specs right now if I suspect they are
designed for a closed/vendor/operator environment :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:15 p.m.
Iñaki Baz Castillo schrieb:
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
IMO does not matter who produces a specs - if it is useful let us use it.
klaus
inaki,
interesting reading. i haven't been on ietf mailing lists for quite
some time. perhaps there are no "ietf" people anymore left in ietf sip
related working groups, and they are currently only rubber stamping
oma/ims specifications. looks to be that way, because no-one responded
to your message.
i don't have anything against oma as long as they don't force me to use
a large number of walled garden servers (like is the case with ims),
whose only purpose is to milk the cow as many times as possible.
perhaps it thus makes sense to adopt from oma specs at least the xml
document specifications.
That's exactly my point Juha.
I would stop reading OMA specs right now if I suspect they are
designed for a closed/vendor/operator environment :) 
5:25 p.m.
On Wed, Oct 7, 2009 at 4:15 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Iñaki Baz Castillo schrieb:
Klaus has gone directly to the point: this is not about religion but
about pragmatism.
Cheers,
--
Victor Pascual Ávila
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
IMO does not matter who produces a specs - if it is useful let us use it.
inaki,
interesting reading. i haven't been on ietf mailing lists for quite
some time. perhaps there are no "ietf" people anymore left in ietf sip
related working groups, and they are currently only rubber stamping
oma/ims specifications. looks to be that way, because no-one responded
to your message.
i don't have anything against oma as long as they don't force me to use
a large number of walled garden servers (like is the case with ims),
whose only purpose is to milk the cow as many times as possible.
perhaps it thus makes sense to adopt from oma specs at least the xml
document specifications.
That's exactly my point Juha.
I would stop reading OMA specs right now if I suspect they are
designed for a closed/vendor/operator environment :)
5:31 p.m.
Victor Pascual Avila writes:
Klaus has gone directly to the point: this is not
about religion but
about pragmatism.
yes and one pragmatic solution might be to add a xmmp server to the
infrastructure so that user can use the same uri both as a sip uri and
xmmp uri depending on client's capabilities.
-- juha
5:47 p.m.
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
yes and one pragmatic solution might be to add a xmmp
server to the
infrastructure so that user can use the same uri both as a sip uri and
xmmp uri depending on client's capabilities.
noooooo!!!
SIP & XMPP integration is a hack!! It's just a dirty workaround,
nothing else. It requires management and maintenance of two different
protocols, two different QoS, two authentication mechanims... what
about dialog subscriptions for call pickup and so? dialgo presence
with SIP and user presence with XMPP? oh nooo please....
Yes, it's true that until now the only feasible IM and presence
solution is XMPP, but we are in SIP side! and we must extend the usage
of SIP for IM and presence (even if implementations are not mature
yet...). We must help in the adoption of SIMPLE/XCAP under feasible
specs (OMA?). If we insist on using XMPP then we are not helping at
all :(
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:56 p.m.
Iñaki Baz Castillo writes:
SIP & XMPP integration is a hack!!
user simply chooses, based on ua capability, which protocol to use. why
can't the same authentication data be used for both?
Yes, it's true that until now the only feasible IM
and presence
solution is XMPP, but we are in SIP side! and we must extend the usage
of SIP for IM and presence (even if implementations are not mature
yet...).
this sounds religious and not very practical.
-- juha
6:10 p.m.
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
Of course, it was a pseudo-joke :)
However I think that we cannot rely forever on XMPP to fill the
IM&presence requeriments in our VoIP/SIP networks. At some point we
have to bet on SIP for IM and presence. Of course, this step requires
having a *good* set of specificacions and good server implementations,
let's work on it!
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Iñaki Baz Castillo writes:
Of course both protocols can share the authentication backend
(DB/LDAP/Radius...) but the fact is that authentication is done by two
servers instead of just one, so issues as nonce reusage and such
possible vulnerabilities appear twice in different ways.
SIP & XMPP integration is a hack!!
user simply chooses, based on ua capability, which protocol to use. why
can't the same authentication data be used for both? Yes, it's
true that until now the only feasible IM and presence
solution is XMPP, but we are in SIP side! and we must extend the usage
of SIP for IM and presence (even if implementations are not mature
yet...).
this sounds religious and not very practical. 
13 Oct
13 Oct
1:01 p.m.
On 07.10.2009 17:10 Uhr, Iñaki Baz Castillo wrote:
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
Of course, it was a pseudo-joke :)
However I think that we cannot rely forever on XMPP to fill the
IM&presence requeriments in our VoIP/SIP networks. At some point we
have to bet on SIP for IM and presence. Of course, this step requires
having a *good* set of specificacions and good server implementations,
let's work on it!
Not being a fan of "one size fits all" and happy to blend protocols to
get best servicing, still using a mixed environment results sometime in
divergent servicing and user experience. SIP has the advantage of
offering advanced routing mechanisms at application level (headers),
while XMPP is using DNS and TCP. I think is not possible to have same
flexibility for im&p with xmpp like for calls with sip.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
Iñaki Baz Castillo writes:
Of course both protocols can share the authentication backend
(DB/LDAP/Radius...) but the fact is that authentication is done by two
servers instead of just one, so issues as nonce reusage and such
possible vulnerabilities appear twice in different ways.
SIP & XMPP integration is a hack!!
user simply chooses, based on ua capability, which protocol to use. why
can't the same authentication data be used for both?
Yes,
it's true that until now the only feasible IM and presence
solution is XMPP, but we are in SIP side! and we must extend the usage
of SIP for IM and presence (even if implementations are not mature
yet...).
this sounds religious and not very practical.
1:54 p.m.
El Martes, 13 de Octubre de 2009, Daniel-Constantin Mierla escribió:
Not being a fan of "one size fits all" and
happy to blend protocols to
get best servicing, still using a mixed environment results sometime in
divergent servicing and user experience. SIP has the advantage of
offering advanced routing mechanisms at application level (headers),
while XMPP is using DNS and TCP. I think is not possible to have same
flexibility for im&p with xmpp like for calls with sip.
Yes, I've been doing some ngrep of XMPP flow and it seems really simpler than
SIMPLE. However it also seems strictly designed to the typical osage of an
user who opens its XMPP software, manages his buddies (permissions and so),
sends messages and participates in chat rooms.
While this covers 95% of the required cases, I'm not sure if XMPP is enough
flexible and extensible to cover other future areas in which presence is more
than "alice is online but bob cannot view alice's status as he's blocked by
her".
--
Iñaki Baz Castillo <ibc(a)aliax.net>
7 Oct
7 Oct
6:03 p.m.
-----Original Message-----
From: users-bounces(a)lists.kamailio.org
[mailto:users-bounces@lists.kamailio.org] On Behalf Of Iñaki
Baz Castillo
Sent: Wednesday, 07. October 2009 16:48
To: Juha Heinanen
Cc: users(a)lists.kamailio.org
Subject: Re: [Kamailio-Users] SIMPLE vs XMPP: The Resolution
2009/10/7 Juha Heinanen <jh(a)tutpro.com>om>:
Hi Inaki
You could include the presence of a SIP endpoint (your phone) as another resource into
your XMPP state. If one of your SIP phones is in a call, the XMPP resource will be e.g.
busy.
If you "set DND on the SIP phone", it could be easily mapped to a XMPP state,
i.e. somehow trigger the resource to become busy as well.
I think also integration at this level is something worth to consider. Not "SIMPLE
users interact with XMPP users" but to let each protocol do what its good at (chat
through XMPP and call through SIP). I have not met too many SIMPLE users to chat with yet
anyways :) The user could have a single URI and there would be no confusion.
Sebastian
>
> Yes, it's true that until now the only feasible IM and presence
> solution is XMPP, but we are in SIP side! and we must extend the usage
> of SIP for IM and presence (even if implementations are not mature
> yet...). We must help in the adoption of SIMPLE/XCAP under feasible
> specs (OMA?). If we insist on using XMPP then we are not helping at
> all :(
>
>
> --
> Iñaki Baz Castillo
> <ibc(a)aliax.net>
yes and one pragmatic solution might be to add a
xmmp server to the
infrastructure so that user can use the same uri both as a
sip uri and
xmmp uri depending on client's capabilities.
noooooo!!!
SIP & XMPP integration is a hack!! It's just a dirty workaround,
nothing else. It requires management and maintenance of two different
protocols, two different QoS, two authentication mechanims... what
about dialog subscriptions for call pickup and so? dialgo presence
with SIP and user presence with XMPP? oh nooo please....
5522
days inactive
5529
days old
19 comments
8 participants
participants (8)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Olle E. Johansson -
Schumann Sebastian -
Victor Pascual Avila