El Martes, 6 de Octubre de 2009, Alex Balashov escribió:

I vote for XMPP.

The problem is that we *must* vote for SIP :)

2009/10/7 Juha Heinanen jh@tutpro.com:

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.

Juha Heinanen schrieb:

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.

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

perhaps it thus makes sense to adopt from oma specs at least the xml document specifications.

-- juha

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

7 okt 2009 kl. 15.09 skrev Juha Heinanen:

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.

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

2009/10/7 Juha Heinanen jh@tutpro.com:

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 :)

On Wed, Oct 7, 2009 at 4:15 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:

Iñaki Baz Castillo schrieb:

...

2009/10/7 Juha Heinanen jh@tutpro.com:

...

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 :)

IMO does not matter who produces a specs - if it is useful let us use it.

Klaus has gone directly to the point: this is not about religion but about pragmatism.

Cheers,

2009/10/7 Juha Heinanen jh@tutpro.com:

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 :(

2009/10/7 Juha Heinanen jh@tutpro.com:

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?

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.

> 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.

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!

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".