Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 13 Oct 2012 20:29:16 +0300

I have been asked many times about the deployment status of SIMPLE in the context of emergency services. I couldn't provide a good answer.

Here is the issue that the emergency services folks are facing: the emergency services authorities are currently in the progress to switch to IP-based emergency services networks (which includes IP-based PSAPs).

Our story so far (IETF, EENA, NENA, etc.) was that they have to implement a SIP-only based solution and everyone else who wants to send emergency calls to them has to perform the translation from whatever protocol they are using. 
Note that emergency calls here refers to a multi-media communication (voice, text, real-time text, video, data).

While the situation is pretty good for voice for text based communication it is far from clear what the SIMPLE deployment status is. 

The interworking between SIP-based voice and XMPP text messaging is not standardized either. Does anyone have any information?

So, what story should I tell these emergency services folks?
Help appreciated. 

Ciao
Hannes

PS: Luckily the address book issues is not applicable to emergency services. 

Sent from my ASUS Pad

Adrian Georgescu <[email-masked]> wrote:

>Hi Olle,
>
>As a developer I can only concur with your assessment about the address book. In my case, it took four years of development and 15,000 lines of Python code, which is a high level language to assemble what one would call a SIP SIMPLE presence enabled address-book application where each contact is Presence aware. And of course there is no chance to have other SIP clients work with the same model. I had to navigate and connect the dots between countless disparate IETF documents like 
>
>http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Presence
>
>This complexity is beyond the reach of regular programmers that do not live deep inside the SIP world. Who has years to waste for such a task? A comparison with what other functionality, like setting up an audio call or a multiparty conference requires in terms of effort, may give a better image of the complexity for doing Presence with SIMPLE.
>
>http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png
>
>Complexity aside, on the good side I have discovered that:
>
>1. IM, File Transfers and Multiparty chat work very well with MSRP, it is straight forward to implement and is well interoperable
>2. Inter-domain signaling and media works well even to XMPP domains for both Presence, IM and multi-party chat
>
>What could be considered 'broken' is the lack of a standard model for storing a generic and extensible address-book with presence-rules so that several different clients can work together under the same account without generating conflicting XCAP documents.
>
>I would not call SIMPLE a failure just because things are complex, as they really are. XMPP is not a walk in the park either when you try to do with it more that it was designed for.  Just look at the forest of incompatible options between same the clients of Google namely Talk, Hangouts and Gmail interfaces, you can recognize same issues as with SIP. Add voice into the equation and you recognize the same complexity as with SIP trying to do Presence. What Google did well is to abstract the address book for all of their own clients so that the problem is well hidden.
>
>What could be done to make SIMPLE better and achieve its original goal, would be to standardize an XCAP address book application with presence rules built-in that can be interpreted in a single way by all developers.
>
>Adrian
>
>On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote:
>
>> Hello,
>> 
>> The SIMPLE workgrup chartar says:
>> 
>> "The IETF has committed to 
>> producing an interoperable standard for these services compliant to 
>> the requirements for IM outlined in RFC 2779 (including the security 
>> and privacy requirements there) and in the Common Profile for Instant 
>> Messaging (CPIM) specification, developed within the IMPP working 
>> group."
>> 
>> From testing various SIP clients with SIMPLE support, I think the IETF is far away from this goal - the "interoperable" part.
>> 
>> I see a mixture of Proprietary, OMA and IETF documents being used in different ways for address books, presence and messaging. It is really hard to get a simple red/green indication  to work across clients using XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is just not working, without loosing a lot of data or creating crashes.
>> 
>> I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The results scare me. Due to lack of a reference profile (or the existence too many non-compatible reference profiles)  it seems like developers have tried to pick parts from various sources to create a solution that works for networks with their own clients. Most of them follow some sort of standard, but the result does not create any acceptable level of interoperability.
>> 
>> I think a base requirement is 
>> 
>> * To be able to use the same buddy list with different clients without loosing data
>> * To be able to add friends to the buddy list and see their presence states 
>> 
>> I tihnk it's time for the WG to focus on interoperability tests, document these short-comings and find ways to solve them. Otherwise we will end up with a standard that only works in single-vendor installations, which is not what I call "an interoperable standard" as is the goal in the very first paragraph of the charter. If possible invite the OMA to work with us and merge their documents with the IETF standards.
>> 
>> SIPit 30 in February could be a good place for a meeting and practical test, dicussion about what's missing and possibly ways forwards. Reports from such an event could be brought back to the IETF and be the basis for work to reach some level of interoperability.
>> 
>> Right now any multi-vendor solution based on SIMPLE is just not possible to sell, because it won't work. This means that customers that want open standards to be a guarantee of some level of vendor-independence won't get what they want.
>> 
>> We seriously need to fix this and get some running, interoperable code. Or just conclude with the statement "SIMPLE failed, use xmpp instead".
>> 
>> /O
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/simple
>> 
>
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/simple

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 13 Oct 2012 20:47:51 +0200

> The interworking between SIP-based voice and XMPP text messaging is not standardized either. Does anyone have any information?
It's going to be hard to translate. We had a workshop on that years ago. The architecture is very different. There are efforts,
recently in sylkserver, you can play with. I have some presentation on slideshare as "oej" covering the differences as we saw them then.
If you add xcap and server-side buddy lists it's even harder.

> So, what story should I tell these emergency services folks?
Good question. Basic SIP MESSAGE doesn't involve much of SIMPLE, but it has it drawbacks. MSRP, as Adrian said, works well. 

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 13 Oct 2012 18:12:40 -0600

On 10/13/12 11:29 AM, Hannes Tschofenig wrote:

> The interworking between SIP-based voice and XMPP text messaging
> is not standardized either. Does anyone have any information?

It's funny you should ask. Emil Ivov, Enrico Marocco, and I have been
working on that a bit here:

http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/

I am also planning to soon resurrect the entire series of documents I
had underway several years ago, draft-saintandre-sip-xmpp-* (core, IM,
presence, etc.).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 Oct 2012 09:29:46 +0300

Hi Peter,

I am aware of this work and the effort that happened before it but for 
some reason I got the impression that there was very low energy behind it.

My impression was that the telcommunication operator community don't 
seem to care about it there is still the believe that a pure SIP-based 
approach will lead to success (and XMPP is not on their radar at all) 
and the XMPP community does not seem care about SIP.

Is this understanding wrong?

Ciao
Hannes

On 10/14/2012 03:12 AM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlB6A3gACgkQNL8k5A2w/vzh+wCg4lajuJTMDRwd0gBZNXaPk18S
> Ls4AoIaiLEL1q75NM09qISSDHUdUhSD4
> =NDw2
> -----END PGP SIGNATURE-----
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 14 Oct 2012 09:33:47 +0200

14 okt 2012 kl. 08:29 skrev Hannes Tschofenig <[email-masked]>:

> Hi Peter,
> 
> I am aware of this work and the effort that happened before it but for some reason I got the impression that there was very low energy behind it.
There are many clients around that support both XMPP and SIP and there used to be very few clients supporting SIMPLE, so the requirements for interoperability on protocol level has not been huge. 

Today we have more clients supporting SIMPLE, so there may be a new level of interest.

> 
> My impression was that the telcommunication operator community don't seem to care about it there is still the believe that a pure SIP-based approach will lead to success (and XMPP is not on their radar at all) and the XMPP community does not seem care about SIP.
Which may not be a bad thing. Being sarcastic, the interest in SIP from the operator community has given SIP a lot of ISDN features that XMPP luckily doesn't have... ;-)

The architecture is fundamentally different. In XMPP, the server forwards XMPP messages called stanzas, but doesn't keep or aggregate any status. In SIMPLE, the server aggregates presence states and we can ask the server about an entitys current status and change it. This lead to some interoperability challenges, like the SIP subscribe query with expires:0. A jabber server can't answer that.

> Is this understanding wrong?
The interesting thing with XMPP is that it powers a lot of applications that you don't see as classical IM or presence, with buddy lists. The XMPP developer meetings are full with cool developers presenting really interesting projects powered by XMPP. So you might have applications in the telecom world that build on XMPP, but very few people know about it. 

XMPP did one thing right that SIP did not. There are two RFCs - one for the core protocol and one for the first application - IM and presence. SIP could have benefited from one RFC for the core protocol and a separate for "telephony". 

/O

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 Oct 2012 14:37:57 +0300

> Today we have more clients supporting SIMPLE, so there may be a new level of interest.

Could you give me a few examples?

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 14 Oct 2012 15:11:31 +0200

> Could you give me a few examples?

I've tested Zoiper, Bria, Jitsi and Blink (for Mac).

On the server side you have Kamailio (which I used), OpenSIPS as well as a separate server for Xcap called OpenXCAP.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 14:02:58 -0400

> If you add xcap and server-side buddy lists it's even harder.

ISTM that while there is difficulty in mapping presence between xmpp and 
sip, there is much less difficulty in mapping IM messages between xmpp 
and msrp. The latter is the part that is needed for emergency services.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Oct 2012 12:39:36 +0200

> On the server side you have Kamailio (which I used), OpenSIPS as well as a separate server for Xcap called OpenXCAP.

We should assume that 99% of SIMPLE implementations in the "open
internet" are buggy, but IMHO it makes sense taking into account the
complexity of the so many RFC's required for implementing a not
complete presence/permissions/buddylist platform. The only good
implementation (AFAIK) is Blink and its related server stuff (after
YEARS of work) and, finally, it can only interoperate *well* with
other Blink instances.

So we have really complex specs that use partial SIP subscription to
partial XML documents distributed in HTTP/XCAP servers, with XML
resource-list documents that can just store "display name" and "uri",
and include *absolute* references (including HTTP schema, domain,
path...) to other XML nodes within the *same* document (but they
usually point to other XML documents in the same or *any* other
HTTP/XCAP server). This is just annoying, nobody in the Internet world
can deploy something like this and make it to properly work, but in
the other side we have tons of XMPP clients and servers which
interoperate very well when sharing buddy-list and permissions.

What was the purpose of IETF in SIMPLE presence stuff? The specs are
so ambiguous and complex that nobody knows what exactly to implement.
We need a "Presence Profile" for the OPEN Internet ("implement exactly
this and this and this in this exact way"), and not just for telcos
private networks (OMA/RCS...). Let's be honest: the only environments
in which SIMPLE presence stuff can "work" is within private networks
or walled wardens, with their own clients and servers managing XML
documents that will never be readable/writable by end users or open
SIP clients.

Then we have OMA that adds a layer on top of IETF SIMPLE specs (so we
have stuf like "my-oma-PoC-users"...), and we also have RCS which is
an extra layer on top of OMA specs... (¿?¿?¿?¿?). XMPP presence is
defined in a single RFC and implementors make it to work without
problems (at least basic presence and buddylist/authorization rules
management).

Why is SIMPLE-presence so difficult? Some keys:

- A "presence" NOTIFY can contain multiple tuples for the same AoR,
but there is no way to correlate them between different instances of
the same AoR (GRUU??).

- A PIDF body can contain exotic information (state basic: "close",
contact: "mailto:[email-masked]"). It is just imposssible to
render it in client side.

- The pres-rules document (according to OMA specs) contains HTTP
absolute links to the resource-list document, but the resource-list
document also contains HTTP links to XML nodes within the same
document. This is really annoying, what would happen if the service
provider has to change its domain or upgrades from HTTP to HTTPS? all
the XCAP documents would get invalidated! Why a document must point to
other document and that document to others? why does a URI list
contain a link to other lists with links to others? it's really HARD
to inspect both the pres-rules and resource-list documents and decide
how to draw my buddylist and who is blocked and who is not. That
should be a single task.

The buddylist should be a SINGLE "document" in which each contact has
attributes (i.e. presence watching allowed or not, visible in the
buddy list or not, groups, tags, vcard info, and so on). A single
"document" hopefully managed via SIP (we have TCP so why to add HTTP
to the SIP ecosystem?). I don't want to subscribe to a XCAP server,
receive notifications with *partial* XML diffs and/or retrieve the XML
document new fragment via HTTP/XCAP. Too many points of failure and
inconsistency.

IMHO the keywords that define all the SIMPLE presence stuff are
"weak", "fragile" and "complex", so complex. The most basic operation
(so easy in any other IM/presence protocol) becomes the hardest task
in SIP (see the lines of code in Blink for the presence stuff and the
years it took to make it to work). Why so hard? take a look to RCS
specs, they provide NOTHING that XMPP does not provide since years,
why to build a so complex spec and infrastructure that provides less
than MSN 10 years ago but in a much more complex and expensive way?

So, is this a failure of the IETF? No idea, what I really don't know
is *what* the purpose of the IETF was when it designed all those
specifications that don't explain how to build a single addressbook to
be shared by different SIP devices. It seems like SIMPLE presence
RFC's are just a skeleton in which telcos or vendors can add their
custom extra layers for their private networks, and it seems that
nobody cared about the open Internet when writting SIMPLE presence
specs. What should I implement in a generic open source SIP client for
interoperating with others and sharing a full-featured addressbook?
There is no response for this question yet.

NOTE: I spent more than a year implementing all the RFCs/OMA specs in
my own XCAP/XDMS server and SIMPLE/XCAP clients. After having a
working and strict implementation of a XCAP/XDMS server and a client
capable of rendering the info from both the pres-rules and
resource-lists all together, I decided to drop all my effort. Too many
lines of code and wasted weeks for implementing nothing cool or new.
IMHO life should be easier.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Oct 2012 08:27:54 -0600

On 10/14/12 12:29 AM, Hannes Tschofenig wrote:
> Hi Peter,
> 
> I am aware of this work and the effort that happened before it but
> for some reason I got the impression that there was very low energy
> behind it.

Recently I have received a number of statements of interest in
SIP-XMPP interworking. Partly this is because of dual-stack clients
that use SIP for voice and video but XMPP for messaging and presence
(thus the "CUSAX" I-D).

> My impression was that the telcommunication operator community
> don't seem to care about it there is still the believe that a pure
> SIP-based approach will lead to success (and XMPP is not on their
> radar at all) and the XMPP community does not seem care about SIP.
> 

In my experience, some operators and enterprise software vendors are
indeed interested in SIMPLE<=>XMPP interworking for messaging and
presence because, even if they support SIMPLE for messaging and
presence, they want to provide gateways to XMPP so that they can offer
connections to contacts on large XMPP services like Google Talk. Thus
it is helpful for those folks to have specs showing how to translate
between SIMPLE and XMPP for addresses, presence, single messages,
one-to-one chat, and multi-user chat (the series of specs that I plan
to resurrect here soon).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 17 Oct 2012 10:08:28 +0200

Hi Olle,

(sorry if this has been answered down the thread, I'm catching up)

> The architecture is fundamentally different. In XMPP, the server forwards XMPP messages called stanzas, but doesn't keep or aggregate any status. In SIMPLE, the server aggregates presence states an…

That particular example, SUBSCRIBE with expires 0, can be seen as a 'presence probe', aka 'give me the last known state' and XMPP can do this with a presence stanza of type 'probe'.

--
Saúl Ibarra Corretgé
AG Projects