Basic instincts

What an interesting statement issued here after yet another superficial interpretation of the well known and long identified dual model for IT applications distribution.

At present, there is no one company covering these issues comprehensively. Microsoft must build scalable presence, Google must build trust. At Jabber, Inc. we're watching this looming battle with the inherent interest of an arms dealer.

The author is by the way Jabber Inc's public relations person. The actual issues referred to in the post are

• The inherent need for a high trust level that must come associated with any application service provider.
• The scalability of the distribution system's architecture to support the service.

I somewhat agree that presence is called to play an increasing role in many upcoming applications, be they used in an ASP or edge model. But this is certainly not the unique constraint that one needs to consider for building a successful ASP infrastructure. Generic reliability, graceful degraded functions, high availability and self healing are just a few of the basic needs for a proper scaling architecture. Real time oriented data services will certainly also play a role. In that respect, Google probably has an edge.
On the other front, I am not certain any of the two contenders can pretend to inspire a sufficient trust level. But, contrary to infrastructure, this is not a technical matter.

To conclude, although I have unfortunately observed several times that many in the PR world often associate “public” with “dummies”, I find rather curious to compare carrots (the illusive trust level of a corporation) and apples (the forbidden fruit of seamless scalability). More interestingly, I am wondering if the author is not falling into that category of people spending 5 months of their year's time in front of a television or a computer. Beyond the natural mental mimetism which results from trying to penetrate DoD contractors defenses and sell them presence, too much exposure to WoW, "GI Jane", [insert here any other B TV series, video game or reality show] is the only rational explanation I could find to why the inherent interests of this company should be those of an "arms dealer" when the context is "live" services…

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Translating between otherwise incompatible networks

This is the most common definition given of a gateway in the telecommunication context:

A gateway is node that translates between two otherwise incompatible networks or network segments. Gateways perform code and protocol conversion to facilitate traffic between different architectures.

On the ground of this definition, the application that IBM has built on its Websphere J2EE server for Sametime is effectively a gateway. For that exact same reason, I believe that a very substantial leap of faith is required to envisage that it could lead to a multi-protocol presence server.
Fom the information available, the gateway is an application build on the JSR-000116 SIP Servlet API. It is in its way following a similar architecture of what IBM tout as the Websphere Presence Server. The SIP Servlet API is an attempt at leveraging developers' knowledge of HTTP web containers and extending it to SIP. On paper this is a sensible idea. In practice it has a few drawbacks.

• First, it is entirely based on the SIP protocol, which means that applications built on top of this technology will be SIP applications. As such, the SIP servlets are designed to process SIP requests and return SIP responses.
  That somewhat restrict the scope, as each network protocol has very specific characteristics which are rarely though of as "universal". Moreover, not every presence protocol uses a request/response paradigm in the way SIP does. XMPP for example uses simple notification packets to signal modification in presence sates, without requiring these packets to be answered.  In that respect, it becomes more difficult to mold XMPP into a servlet paradigm in the way it was possible with SIP. Consequently, the advantages expected from a common programming paradigm become somewhat blurred.
• Second, it relies on a J2EE server to run. One can argue that it is a proven robust architecture. I would simply say that J2EE servers were not invented to provide solutions to real-time communications problems, but rather to bring solution to transactional application problems in the enterprise. The table herewith summarizes the differences between the two contexts.

All in all, if the IBM gateway had been implemented using a more appropriate application server such as a JSR 22 JAIN SLEE API implementation, I would have been tempted to take the leap of faith. Unfortunately, this gateway architecture prohibits any use beyond bridging between SIP and other protocols. To be fair, the same inability applies to the equally shortsighted approach taken by Jabber Inc. A solution that only sees the world through the eyes of a particular protocol will always leave us far from what is necessary to build a multi-protocol presence server. For the simple reason presence encompasses more than just protocols…

Technorati Tags: XMPP, SIP, Presence, Antecipate

Speaking of cluetards...

Have you notice the drums roll and trumpeting around the latest Sametime interoperability announcement? I always find it entertaining to witness how incumbents can turn a failure to respond to their customers wishes into a world saving progress without even a blush!

At the end of the summer of 2004, I had the opportunity to see IBM in action at a workshop held by the Financial Service Instant Messaging Association on the subject of IM interoperability. FIMA had been worried very early on by the disparity of instant messaging protocols, both in the public and the enterprise IM space. So they set to give their least common denominator functional definition of interoperability, which when you think of it is not asking for the moon…
At the workshop, vendor presented their views, and it all went smoothly until the chair of the Jabber Software Foundation asked IBM why they wanted to support the still unfinished SIMPLE protocol as a federation protocol rather than XMPP which was already stable and widely used alongside Sametime in the financial industry.
Anyone either business savvy or a little familiar with Sametime's technical architecture would have though along the same lines. From an architecture standpoint, the multiplexers, community hubs and community server applications of sametime, with their permanent TCP links, can be functionally mapped one to one with XMPP client connectors, session managers and service components. From a business perspective, federating the existing large financial industry's Sametime islands with the expanding XMPP footprint would have help IBM keep an edge against the nascent Microsoft LCS expansion.
Instead, we were granted a flame from the IBM representative in favor of SIMPLE which was more typical of a Gorilla's behavior than a business representative:

If challenged by a younger or even by an outsider male, a silverback [Silverbacks are the strong, dominant troop leaders] will scream, beat his chest, break branches, bare his teeth, then charge forward.

In short, SIMPLE was the way to go, and everyone not endorsing it was stupid and doomed to fail. Well, two years after, IBM announced interoperability with XMPP, which instantaneously guaranties secure and controlled communication with any XMPP server, including those at Google. They also announced interoperability with AOL, but funnily enough they do not specify what protocol they use. You maybe interested to know that AOL offers both an LCS flavor of SIMPLE and XMPP to enterprises for federation with AIM. As there is no mention of interoperability with LCS in the Sametime announcement, it would be interesting to have a clearer insight on what they IBM is using for interconnecting with AOL. As to Yahoo!, well it is always a little difficult to have anything but a fuzzy statement from these guys. Anyway, the announcement said federation between Sametime and Yahoo messenger is on the "road map".

Ken Camp came up with a nice and illustrative contraction to apply to people unable to spot the appropriate answer to end-users' aspirations, cluetards… In this case, IBM is only different from the average by the size, just a large cluetard. If I were a financial Sametime customer, I would claim compensation for having been treated this way and left longing for so many years.
More importantly, this episode illustrates once again how large incumbent IT vendors are blind to real users' needs, when they are not in line with their core business. IBM business is in selling servers, not in providing communication between peoples. I find it amazing that a pure technical choice made by some ex-Ubique geek ended up depriving an important business community of an easy and beneficial way to conduct their business with small firms or other institutions.

Beyond this, Giacomo is in my opinion asking the right question: should we forget SIMPLE? In a perfect world, I would certainly answer positively. In the real world, it will take some time in view of the interests at stake. Having been involved in designing applications federating both protocols, I certainly have a unique perspective on the strength and weaknesses of each of them. From a technical standpoint, my only observation is that SIMPLE simply lacks the simplicity needed for a wide adoption.

• Except the Microsoft LCS there is no SIMPLE based instant messaging and presence (IMP) application in service outside the telecom industry. Anybody having looked closely at the actual protocol used by LCS will agree that it's actual compliance with SIMPLE stops short after the first SERVICE packet. Microsoft has leaned the hard way that SIMPLE was not ready for IMP, and has been obliged to supplement the lack of the protocol with LCS own extensions. Such things as multi client instances, message sessions, contact lists management, preferences, multi user conferencing are notably absent from the specification and have partially been implemented by Microsoft using non-standard extensions.
• From a user agent perspective, the closest to a "standard" SIMPLE client implementation is the Counterpath' eyebeam softphone and it XLite derivative. Their development team deserves the greatest respect for having incessantly been trying to accommodate the ever changing scope of XCAP, and the various contact lists management options that must be part of a "workable" SIMPLE solution. But while doing this, they had no time to automate the status change to "on the phone" when a SIP call was taking place…
• From a standard stand point, those who have red the 2500 plus pages from the 3GPP describing the use of SIMPLE for presence are well aware that, for example, list services, XCAP and a stable definition of rich PIDF are on the critical path for delivering the service as expected by the IMS architecture. XCAP is probably the most blatant example of wheel re-invention in this industry, where the oversized ego of the author is holding back an entire industry. More importantly, if one look at the SIMPLE RFCs and drafts authors, one can quickly infer that the standardization process is done by a vendor led consortium. As I have said before, almost every vendor led consortium has failed to impose any long lived interoperability standard on the Internet. I am afraid SIMPLE is another one of them, and it is time to realize it…
• Finally, there is the complexity of SIMPLE. It makes it difficult to grasp by the average application developer outside those versed in "voice over…". When adding together the rather rigid framework provided by SIMPLE and the vast differences in interpretations by various implementers, it makes this protocol look "elitist" when compared to XMPP. As I mentioned above, having designed and implemented converged systems supporting those two protocols simultaneously, I can vouch that any application programmer can grasp how XMPP works; the same is not true from SIMPLE.

As Ken put it, simplicity and elegance alway make winners and losers. Simplicity is unfortunately not the first quality of SIMPLE. As a result, it has not seen mainstream adoption by web application developers which are instead turning to XMPP. That said, SIMPLE will not go away easily in view of the heavy investments made by many cluetards. Unfortunately this state of affairs will help maintain the silo divide between the telecom and the internet worlds.

The term "elegance" finds its origin in the Latin "eligere" which also gave the derived term "election". In fashion as in real life, elegance implies making a choice. In the Sametime case, it was between remaining Incredibly Blind and Mediocre, or working at solving real end-users pain points. You can guess what choice was made…

Technorati Tags: XMPP, Jabber, SIP, Interoperability, Antecipate

Maps of every country unite!

Some time ago, I was researching XMPP presence indicators that could be embedded into a web or blog page. This is how I came across Jobble, a Google maps and XMPP presence mashup. I knew of other similar services, such as Jabber World Map, Jabber Google Map and Talk Maps. They all provide the same kind of information: a map with the presence state representation of online XMPP users. For some reason, I prefer the way the Jobble site presents the information. But it is only a matter of taste.

As I was toying with these different services, it appeared to me that they were used by different demographics, which were themselves geographically concentrated. For example, Jobble, which is a Polish project, has a vast majority of subscribers from north-eastern Europe. The same applies to Jabber World Map which is coming from the Netherlands. Talk Maps has a slight majority of users in Europe, but overall users are thinly spread. Curiously, north-american users don't seem to fancy this kind of service…
My second observation was that those of my contacts using these services were scattered on several separate maps. I would have liked to have them on the same map instead. This is how I thought of federating XMPP maps.

Putting people on a map is a way to make them feel closer, and somehow participate in a feeling of community. But when these communities do not intersect, the chances to communicate and establish new relationships remain low. I have discussed earlier why a closed community would ultimately be less sticky than an open one, and looking carefully at these services shows they somehow act as closed communities. I think that the choice of registering to a particular map service must only be governed by the features that can be derived from the user presence, and not from the presence collection itself. For example, someone may prefer the way Jabber World Map show online users when the mouse hovers above a symbol, other the traditional point and click approach of Google Maps found in Talk Maps. Furthermore, someone may want to develop a similar service using Yahoo flash based maps, to be able to add some overlays.

Unfortunately, the ways these services are implemented today only lead to a walled garden result. Each service is built around its own data store and does not communicate with the rest of the world. Furthermore, they only allow static geo-location mapping, leaving out mobile devices or traveling users. Thinking of it, it is not that difficult to modify these services and turn them into distributed geo-location providers. The base features I would expect of such services are summarized bellow:

• Single registration and management point. The options chosen for my geo-location information using a particular service may become available to other similar services without forcing me to register with each of them individually.
• Static and dynamic geo-location data support. I want to be able to specify either static longitude and latitude values for a fixed workstation, or have the service pick up this information dynamically from a particular client.
• Privacy and information propagation control. It may look strange to mention privacy amongst the expected features, as putting one's presence on a map is already revealing a lot. But I would expect the service to provide a way to control the propagation of these data outside the service through an appropriate combination of white and black lists.

Looking at possible implementation options, I believe we have to keep the current approach which exposes the service through a presence enabled bot. It has the immense advantage of being well understood by the average user.
As a first step, the bot would need to be modified to understand the Personal Eventing (PEP) extension notifications. This will cater for dynamic geo-location updates. As PEP implementation progress, the service will automatically get access to dynamic geo-location information as they are set on the end user device, and will be able to display it on the map along with the user's static data.  From an end user standpoint, this would also simplify the fine grain tuning of which piece of information is made available to the service directly at the PEP level.
The bot could also be adapted to support PEP subscriptions. This would be appropriate in case the user's home server or the user profile does not allow an automatic subscription to PEP when someone subscribes to the user's presence information.
Finally, the service itself would have to expose a user geo-location node as specified by the publish/subscribe XMPP extension.  It would not be necessary to implement a full fledged publish/subscribe service, but rather make the service understand only the appropriate subset dealing with the http://jabber.org/protocol/geoloc namespace. Another map service interested to get geo-location information would then subscribe to this node and receive any published modification.

<message from= "map.montague.net" to="map.capulet.com">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="n48ad4fj78zn38st734">
      <item id="a1s2d3f4g5h6bjeh936">
        <geoloc xmlns="http://jabber.org/protocol/geoloc" xml:lang="en">
          <country>Italy</country>
          <locality>Verona</locality>
          <lat>45.44</lat>
          <lon>10.996</lon>
        </geoloc>
      </item>
    </items>
  </event>
  <addresses xmlns="http://jabber.org/protocol/address">
    <address type="replyto" jid="romeo@montague.net/orchard"/>
  </addresses>
</message>

Another possible approach would be to make the service itself support presence subscriptions and have the geo-location information implemented in a PEP node.  This way the relationship between two map services would be entirely presence driven, enabling added control through presence states. For example, there would not be notification toward a service which does not appear available. This is important in period of maintenance, or can be used as a way to throttle down heavy traffic. Presence would also be used to propagate end user's availability states.

<presence from= "map.montague.net" to="map.capulet.com">
  <show>away</show>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type="replyto" jid="romeo@montague.net/orchard">
  </addresses>
</presence>

The end result would be a distributed geo-location information aggregation that could be leveraged through a standard and open protocol. Several local aggregators could be built by geographically close communities, but see their reach extended to the Internet as a whole because of the distributed design. From an end user stand point, there is not lock in, as it is possible to choose a service on the feature set offered and move to another service implementation without being forced to use yet another address handle. The combination of service based and PEP based filters would ensure a good level of privacy control.  And in the end my presence and geo-location information as seen by Jobble will be reflected on as Jabber World Map, Jabber Google Map and Talk Maps without forcing me to add a bot in my contact list for each different service.

Technorati Tags: XMPP, Jabber, Presence, Geo Location, Publish subscribe, Social network, Antecipate

The six oldest new ideas in chat…

Since I came across this post, I was looking for the proper illustration before coming back to it. In the end, the simplest and first impression is always the right one: this author does not have the slightest clue of what he is talking about…

First of all, he starts by being confused by the subtle difference between "chat" and "instant messaging". In effect, most of the "exemplifying" services or product he mentions are doing with instant messaging, and some of them offers multi user chat facilities. But instant messaging is not really news.

Interoperability. Ever since the invention of the telephone, interoperability has been the single requirement for any mediated communication system. In short we cannot decently consider this to be a new idea. Because of the early calcification forming into the innovative region of most corporate executives' brain, we unfortunately face a walled garden landscape for instant messaging (amongst other things). So suddenly discovering that "clearly, open standards are here to stay" is not properly visionary. Well as they say in China, "when the wise man point to the moon, the fool only sees the finger".
As a passing remark, unless I am mistaking, Trillian, Gaim, Adium and Miranda are multi protocol instant messaging client applications, not "services".

In-Browser Chat. This one is misleading because of the confusion between chat and instant messaging. But a simple search on the term chat will bring back 551,000,000 results which tends to indicate that chat has been in the news for quite some time. And when you carefully look at the results, you will find that many point to in-browser chat for so called "adults" services. But isn't this the oldest business in the world?
There are a number of browser based instant messaging clients which are trying to solve the interoperability issues mentioned above. For the same reasons that lead to the ineluctable disappearance of communication silos, only those services that rely on open protocols will remain. At that point in time, the end user will have the choice of installing a standard based client application on its workstation or use the same application hosted at a provider. The debate between hosted and non-hosted application has been part of the IT landscape ever since its beginning. This is not new either.

Location Based Chat. Geo location services have existed in mobile phone services since the early days of GSM. Before the web 1.0 bubble, some vendors were even touting geo location as "killer application". And it is still part of several mobile application services trying to bring contextual search to road warriors.
As I explained earlier, geo location can participate in bringing a sensation of "place" into mediated communication. But initial research on the subject dates back to the mid nineties. It is fair to say that most of the research was concerned about "virtual reality" worlds at the time. Obviously, instant messaging was not yet considered mainstream. This simply re-enforce the length of the road leading from ideas to their applications in different domains, but this has always been the case.

Flexible Identities. A quick look at this post will convince you that multiple personae have one of the longest research histories in the context of the Internet. You will also notice that there is a subtle distinction between "multiple personae" and "multiple facets" of one's identity. The same as between Doctor Jekyll and Mister Hide…
As a remark, the provided examples only implement precepts from the now defunct Presence and Availability Management forum on how granular presence was to be used to manage communication address handles, and when thinking of it, all the call forwarding features available in a PBX were already a way to "separate your private and professional faces". After ten years of "converged communication" talks, applying the same principles to instant messaging should not come as a real surprise.

Contextual Chat. In this case we are really talking about chat. This section presents a blurred mix of two different concepts. On one end there is the chat room client who can be embedded on different web pages, such as blog posts, and provide a fixed context for discussion. On the other end we have the "virtual presence" clients as browser's add-in which will work on any web page. The idea of being instantly aware of other users reading the same web page emerged early in the history of the Web. Implementation projects appeared in the fist half of the nineties with the advent of Virtual Places and other co-browsing initiatives. Ten to fifteen years on the Internet time scale are more like a century to me.

Rich Media Chat. As the author puts it "web cams and microphones have been on the web for a while", and it is only the commoditization of broadband network access and computing power that made "rich media", read internet audio and video, accessible to the mass. Already in the early days of video-conferencing, when only ISDN and leased lines were available, several systems were offering in-band instant messaging and even document sharing. Once again the idea dates back fifteen years. As for the previous section, speaking of novelty is not appropriate. That said, the trend to combine audio to instant messaging is natural as it mimic a real world behavior. The challenge will be to provide a seamless experience moving from one medium to the other across different devices.

The Internet has an immense magnifying power. It even allows us to quickly search a vast knowledge repository for information that would be relevant to make a post valuable. But using a flashy title is still far easier than providing relevant content: you only need to utter six words instead of a few hundred. Unfortunately the lazy approach based on making noise has been around since the beginning of time.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, Antecipate

XMPP.fm

The latest announcement of an XMPP based tool to support music fans communities got me thinking how easy this can be implemented by putting together the proper XEPs. Let us consider how to implement an XMPP internet music radio similar to Last.fm. Obviously we would want to put some "social" focus into it. So the scope is simple:

• Broadcast music to anyone joining the service, even on a temporary basis.
• Provide a music recommendation system.
• Provide discussion spaces amongst listeners.

From a protocol standpoint, the basic extensions we would need to provide this type of service are MUC for the community part, and PEP for the announcement part, obviously complemented by the user tune extension.

A very straightforward implementation route would be to create a presence enabled service to which any users could subscribe. The service will expose a number of "stations" implemented as MUC rooms corresponding to musical subjects of interest for the en users. So you may have rooms such as acoustic, alternative, ambiance, classical, dance, dark, experimental, folk, funk, groove, hip-hop, instrumental, jazz, lounge, metal, pop, punk, rap, reggae, rock, ska, techno, world, [add your own genre here]… To add the required "social" trend, one can imagine a system where users are able to tag and rate the music pieces and rooms are automatically created and added from these user preferences.

…kind of a lite social network system, featuring chat and commenting throughout…

The service "identity" is provided through some kind of DJ bot. End users subscribe to the presence of the bot, and are also automatically subscribed to the bot's personal eventing notifications. The bot also request to be subscribed to the user's tune events. Whenever a user come online, then it will receive XEP-0118 notifications from the bot describing what is currently playing in each active room. Obviously each notification will be augmented to include the URI of the corresponding room, to allow creating a "stations" list for the user to choose from.

Tuning to a station boils down to joining the associated MUC room, providing instant conversation between music lovers with similar tastes. These MUC room are augmented to allow direct presence subscription in the case end users prefer to tune directly to specific musical genre. Every "station" has its own DJ bot to which participants in the room can make suggestion as to the next piece of music to be broadcasted. The DJ bot is also in charge of notifying the room participants of the currently playing piece. It does it by simply posting notification to the room and relies on the standard MUC mechanisms to take over the distribution. This has the advantage of having the "station" past program automatically handled through the room history. The notification will be extended with the information about the physical connection URI in order to enable listening to the current track using the user’s workstation features.

Scrobbling tracks is directly available when the user set's its own user tune state. The notification is sent to the service DJ bot for collection and update of the appropriate statistics.

Additional “social” features could be implemented at each “station” level through the appropriate use of mood and activity publications and notifications. If participants are also able to publish their current room information through XEP-0194, the service could be enriched to provide what Wikipedia describes as:

The most-used community feature within Last.fm is the formation of user groups between users with something in common (for example, membership of another internet forum). Last.fm will generate a group profile similar to the users' profiles, showing an amalgamated set of data and charting the group's overall tastes.

I have already mentioned the lack of interest by the web 2.0 crowd in leveraging XMPP killer features. As one can see from the above quick jotting down, many of the puzzle pieces are readily available. In addition, they can be used from standard XMPP clients supporting MUC and PEP, which will be mainstream this year end. Those wanting to add all the bells and whistle of a multimedia UI can do so by building a flash based client with embedded audio and video players, and they will be ready to compete in the Media 2.0 broadcasting space without much technology investment. XMPP has reached a stage where a large number of applications can be built from its existing features set. It is still just a matter of imagination and creativity…

Technorati Tags: XMPP, Jabber, Chat, Flash, Publish subscribe, Social network, Antecipate

Sensing activities in MUC

I have discussed before why conversation spaces are not places themselves, but rather for people to make places in them. In physical places as well as virtual ones, adaptation and appropriation of the associated technology by users is a critical element in the emergence of a sense of place and appropriate behavior. In short, the sense of place cannot be inherent in the system itself.

Within a place, social navigation is navigation through information collections on the basis of information derived from the activity of others. In the real world, we act where we are. We talk to people around us, because voices can only be heard at a short distance; we get closer to things to view them clearly. Understanding proximity helps us relate people to activities and to each other. When we see a group gathered around a meeting table, we understand something about this peoples' activity, and we know that another person standing off to one side is likely to be less involved.

Just like in real life, place aware presence systems should allow users to move to areas where others are clustered, to join the crowd and see what's going on. Since actions and interactions fall off with distance, so distance can be used to partition activities and the extent of interaction. I have described here how the use of "social proxies" can be used as abstract artifact to induce additional social information. Amongst the "social proxies" that have been studied, I find the Bable experiments particularly interesting as it could be applied to multi user conversations, such as the MUC rooms available on many XMPP servers. The proxy's role is to provide cues about the presence and activity of participants in the current conversation. It is graphically represented by two concentric circles similar to the drawing herewith. The outer circle symbolizes the conversation room border, the inner circle the conversation subject. Every participant is represented by a colored dot. The way it works is that participants in a particular room are shown within the proxy outer circle. People in other rooms are positioned outside the circle. When people are active in the conversation, meaning they either "talk" or "listen", then their dots move towards the inner circle, and then gradually drift back out to the edge when their activity decreases. What is interesting is the way test users have reported their experience of using this type of proxy:

…our users report the social proxy is engaging and informative. They speak of seeing who is "in the room," noticing a crowd "gathering" or "dispersing," and seeing that people are "paying attention" to what they say (when other dots move into the center of the proxy after they post).

On the practical implementation side, XMPP provides a number of extensions that can be put to use to enhance existing MUC implementations to support this type of social proxy. Beyond the specificity of the social proxy, the expected enhancement falls under what I have been writing about as presence feedback.

• XEP-0085 associated with message stanzas moving averages over time calculated at the MUC room level could provide sensible indications about the "talking" activity of every participant. A "listening" activity indication could be derived from the automatic presence status generated by the client.
  
• XEP-0163 could be used at the MUC room level to notify the MUC clients of each participant's dots relative position changes to be displayed on the client interface. If we limit the proxy geometry to a Cartesian representation, we could easily derive an appropriate format for the associated data similar to the Geo Location XEP.
  
• Other MUC rooms' global activity could also be provided to further accentuate the overall places context. Obviously, the notion of proximity could also be put to use to induce the notion of semantically related room discussion contexts.

In the end, I believe it is not overly difficult to assemble all these XMPP extensions together in a MUC implementation and, as a result, give a better sense of other people's presence and the ongoing awareness of activity into the conversation space. All in all it would be an interesting step toward better structuring our activity in the rooms, and better integrating communication and collaboration.

Technorati Tags: XMPP, Jabber, Conversation space, Presence, Antecipate

Jingling call control

Third party call control is what makes applications such as "click-to-call" possible. Although I will not qualify "click-to-call" of killer application, its potential in traditional commerce or support applications is undeniable. In essence, third party call control is a must have when the communication sessions are managed by just more than individuals.

Although until recently third party call control was the guarded property of large telecom vendors, a new breed of call control gateway has made its appearance. These devices bridge Microsoft's LCS world with the open source world of Asterisk, and provide a way for the Office communicator client to control the open source IPBX:

• Use Office Communicator as a soft-phone to place calls, deflect calls, forward calls through Asterisk.
• Receive incoming call notifications, see who is calling and reroute to an alternate number.

Obviously I do not feel this kind of device important because of what they do for the Microsoft closed products, but rather because they do it through the use of a standard protocol. Office Communicator has a built in support for the ECMA-323 standard, which is also known as CSTA XML. CSTA in its binary disguise has been around telecom vendor's equipment for a while. But I am ready to bet that its XML version will gain more and more traction as it allows a much easier and quicker integration between communication equipments and business applications.

In the context of Jingle, supporting different forms of call control is mandatory if the protocol is to see adoption beyond the narrow context of peer-to-peer direct communications. And I believe that looking to integrate CSTA XML and Jingle is the way to go.

Technorati Tags: XMPP, Jingle, Call control, IPBX, Phone system, Antecipate

Streamlining remote probes

I wanted to finalize my original topic on improving XMPP presence handling model for subscribers hosted on distributed home servers by looking at presence probes.
XMPP differs from presence protocols such as SIP/SIMPLE by using persistent presence subscriptions, instead of transient subscriptions to be renewed for every session. In this model, an XMPP client publishes its presence states variations to its home server, which in turn generate the appropriate presence notifications.
Furthermore, an XMPP presence server is only responsible, and above all knowledgeable, of its own user's constituency.

When a user want to initiate a presence enabled session, it publishes an initial presence after login. This is intercepted by its home server, which is in charge of

• Responding to the client with the initial known presence state of every watched contact,
• Notifying every contact subscribed to receive the user's presence.

The home server then triggers two processes:

• A user's presence notification to all the watchers of its presence state,
• A probe of each user's subscriptions to receive the contacts' presence states.

When every contact in a user's buddy list is co-located on the same home server, the server has a complete view of each contact's presence state, and using a probe stanza is not necessary. But if the contact resides on a remote server, a probe stanza is sent to that server to trigger a presence state stanza in return. Mridul rightly point out that the current specification leaves open the possibility for a server to cache remote contacts presence states and derive initial presence for additional instances of these contacts from cache. I believe the specification must avoid remote presence state caching. The probing mechanism is a guarantee for the home server to always have the latest initial presence state of remote users.

I can now come back to the early concern of minimizing the network traffic generated by presence handling when subscribers are hosted on distributed home servers. It is to be noted once again that the two processes of notifying all watchers and probing to receive contacts' presence states are asymmetrical. I have shown previously how notifications could be optimized by using transient remote users' lists. Conversely, probing multiple contacts' presence states is a one time operation.
XMPP requires that probes be sent to a global URI (bare JID). In my opinion, to the contrary of notifications, the expected gain of grouping several JIDs in a single stanza are more limited. Leveraging XEP-0033 Extended Stanza Addressing to group JIDs in a single stanza may result in slight traffic improvement if the number of remote contacts located on a single server is important. But for a limited number of remote contacts, the gain will certainly be marginal, so the complexity of implementing this kind of mechanism should be carefully weighted against the actual traffic gain.

An illustration of this mechanism is given bellow, assuming the multi-probe support has previously been discovered through XEP-0030:

<presence to="prober.denmark.lit" from="horatio@denmark.net/palace" type="probe">
  <addresses xmlns='http://jabber.org/protocol/address'> 
    <address type="to" jid="rosencrantz@denmark.lit"/>   
    <address type="to" jid="guildenstern@denmark.lit"/>          
  </addresses>
</presence>
<presence to="horatio@denmark.net/palace" from="rosencrantz@denmark.lit/on-the-road"/>  
<presence to="horatio@denmark.net/palace" from="guildenstern@denmark.lit/motel"/>  

It is rather obvious that the overhead of discovering the support and using multiple addresses in a single stanza will offset the gain when contacts are spread up few at a time amongst many servers. That said, if a significant number of contacts are located on a remote server, the mechanism may prove valuable, not primarily because of the traffic reduction, but rather because all the probe targets are delivered in one single stanza. For the remote server it will generally be more efficient to process a series of JIDs in a single transaction without context switching, rather than processing several atomic stanzas each in its own transaction. I most other cases, the added complexity may not be worth implementing.

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Streamlining remote notifications

Mridul recent post highlights a point where XMPP could improve its presence notification model when presence subscribers are distributed amongst many servers. That said, the described behavior is by no mean specific to XMPP and is also found in SIP/SIMPLE early specification. As the issue exhibit some commonalities in both protocols, it is not extraordinary that the proposed solutions to decrease the network traffic generated by notifications revolve around notifying lists of subscribers instead of notifying each subscriber in turn. This is a rather common design in many publish/subscribe, where subscriptions' lists are advertised to the brokers nearest to the subscribers, with a task for them to perform the final notification. When applied in the context of XMPP, the driving idea is to delegate the atomic notification to the home presence server for the concerned domain.

Obviously the expected gain only results from a steamlined traffic between servers. The most noticeable gains would only be achieved when a particular user has more than one contact located on a remote server. In an adverse case presenting a widely spread distribution of remote subscribers (i.e. many remote subscribers each on different home servers), the gain would certainly be lower than expected.

The very nature of XMPP, with its persistent presence subscriptions, implies that the two cases in which a large number of presence packets will be exchanged are at the begining and end of a user’s session:

• When the initial presence is published after a user login,
• When the final presence is published at log out.

At a user login, an XMPP client delegates the appropriate presence notifications to the user’s home server; an initial presence will combine two separate processes:

• A notification of the user's presence to all the watchers of its presence state,
• A probe of each user's subscriptions to receive the contacts' presence states.

At logout time, only the notification of the final “unavailable” presence to all watchers is taking place.

I disagree with the way the problem is presented in the post, as the described use case assumes that the presence subscriptions between users on each server are symmetrical. Although that may account for a majority of cases, this cannot be extended as a generic case.

I also disagree with the underlying assumption that the two processes of notifying all watchers and probing to receive contacts' presence states are symmetrical. XMPP specifically differentiate between "presence-out" (outgoing notifications) and presence-in (incoming notifications). In effect, probes only occur once at the beginning of a user's session, whereas notifications will happen for every user's presence state change. As a result, I think these two processes have to be handled differently. I also believe support for these two processes would be best discovered and implememented independently by servers. Consequently:

• Probing multiple contacts' presence states is a one time operation and can leverage XEP-0033 Extended Stanza Addressing to group all target JIDs in a single stanza. The probe result can be returned by the contacts home server using the same mechanism.
• Notifying watchers requires establishing a transient dynamic watchers list on the contacts' home server. This list's address would then be used when sending notifications in order to minimize the inter-server traffic. The contacts' home sever will then be responsible for the local notification of every contact's resouces.

In this later process, I believe that XEP-0144: Roster Item Exchange would be more appropriate that XEP-0033 for the watcher list management. After all, the watcher list we are trying to build is nothing but a roster extract for the subscribers of a particular domain. The XEP-0144 extension provides all necessary management features to add/delete entries in the list. In our particular use case, I think the proper container is best provided by an InfoQuery stanza. An illustration of this approach is given bellow, which assumes the multi-notification service has previously been discovered through XEP-0030:

<iq to="notifier.denmark.lit"  from="horatio@denmark.net" 
       type="set" id="1234">
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action="add" jid="rosencrantz@denmark.lit"/>   
    <item action="add" jid="guildenstern@denmark.lit"/>          
  </x>
</iq>
 
<iq to="horatio@denmark.net" from="notifier.denmark.lit/a341ff7cd2"
       type= "result" id="1234"/>
…
<presence to="notifier.denmark.lit/a341ff7cd2" from="horatio@denmark.net/palace"/>

You will note how the notification service returns the list address in the InfoQuery result, and how this qualified address is used for sending the presence stanza. If the list needs to be later updated during the user's session, it can be achieved incrementally:

<iq to="notifier.denmark.lit/a341ff7cd2"  from="horatio@denmark.net" 
       type="set" id="3456">
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action="add" jid="hamlet@denmark.lit"/>   
  </x>
</iq> 
 
<iq to="horatio@denmark.net" from="notifier.denmark.lit/a341ff7cd2"
       type= "result" id="3456"/>

In order to keep the management of the list simple, I would make the list transient for the duration of a user's session only. The overhead of re-creating it for every user's login is largely offset by a management that do not have to deal with permanent remote lists. The watcher list can be removed either when the final presence "unavailable" is sent to the multi-notification service, or by using a specific InfoQuery request extended with XEP-0144.

The possible side effects related to glitches in communication between the servers will have to be addressed separately using the mechanisms that are currently under discussion at the JSF.

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Media relay hidden query

I received additional information following my last experiment on Google using media relay. It happens that the GTalk service also implements a full XMPP extension to provide information about its relay servers. This extension, which replaces the "google:relay" query is hidden behind the STUN extension which is documented on their developers' site.

Using my favorite client I was able to check that using the described query gives the result that can be seen bellow:

<iq type="get" to="romeo@gmail.com" id="1" ><query xmlns='google:jingleinfo'/></iq>
<iq from="romeo@gmail.com" type="result" to="romeo@gmail.com/psiC3BE970F" id="1" >
  <query xmlns="google:jingleinfo">
    <stun>
      <server host="stun.l.google.com" udp="19302" />
      <server host="stun1.l.google.com" udp="19302" />
      <server host="stun4.l.google.com" udp="19302" />
      <server host="stun3.l.google.com" udp="19302" />
      <server host="stun2.l.google.com" udp="19302" />
    </stun>
    <relay>
      <token>CAESHgoVamxzZWd1aW5lYXVAZ21haWwuY29tEOCJq4TsIRoQRWsKcIug9O8RySUrR05+tw==</token>
      <server host="relay.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay2.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay3.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay1.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay4.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
    </relay>
  </query>
</iq>

To conclude, it seems that current GTalk clients (1.0.0.100) are using the HTTP/XMPP combination I described earlier, and that future versions may use this XMPP only query to discover the relay servers. In the meantime, I suppose they are waiting for the extension to be final to add it to the existing documentation…

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, NAT, GoogleTalk, Antecipate

Relay or no relay, that was the question

The miracle of the blogosphere happened again. My little rant about Jingle media relaying produced the expected effect, and I now have the answer: Google is effectively using media relaying in GTalk to cater for the 8% of NAT traversal cases not covered by their implementation of ICE. According to the information source,

the client discovers the relay's host, port and other information using a proprietary XMPP extension. The client communicates with the relay service to allocate ports.

It's a proprietary protocol. The team would like to replace the proprietary protocol with TURN.

Earlier today I conducted a simple experience of placing a call between two GTalk clients, with diagnostic logging enabled. Then I looked for an indication of media relaying in the resulting log, and here are my findings.

Immediately after initializing the XMPP session, the client goes on sending the following stanzas before any IM application requests :

[007:201] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:48:29 2006
[007:201] [8a8]    <presence type="unavailable"/>
[007:201] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:48:29 2006
[007:211] [8a8]    <iq type="get" id="7">
[007:211] [8a8]      <query xmlns="google:relay"/>
[007:211] [8a8]    </iq>

The client eventually gets an answer from the server:

[007:581] [8a8] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Mon Nov 06 10:48:30 2006
[007:581] [8a8]    <iq to="romeo@gmail.com/Talk.v98734E454A" id="7" type="result">
[007:581] [8a8]      <query xmlns="google:relay">
[007:581] [8a8]        <token>
[007:581] [8a8]          CAESHgoVamxzZWd1aW5lYXVAZ21haWwuY29tEIO2uPPrIRoQEWhSGqW0sC45unw91a8uNg==
[007:581] [8a8]        </token>
[007:581] [8a8]      </query>
[007:581] [8a8]    </iq>

Later on during the exchange, it appears that the client is attempting a connection through HTTP to a relay.l.google.com host:

[138:820] [8a8] HTTPPortAllocator: starting request 1
[138:820] [8a8] HTTPPortAllocator: sending to host relay.l.google.com
[138:840] [8a8] HtmlWindow::GetHostInfo
…
[138:910] [38c] ReuseSocketPool - Creating new socket
[138:910] [38c] Resolving addr in PhysicalSocket::Connect
[138:910] [38c] === DNS RESOLUTION (relay.l.google.com) ===
…
[139:080] [38c] relay.l.google.com resolved to 216.239.37.126
[139:090] [38c] ReuseSocketPool - Opening connection to: relay.l.google.com:80
[139:391] [8a8] HTTPPortAllocator: HTTP request 1 succeeded with code 200

At this stage we enter the Google's Jingle transports candidates' negotiation. The client prepares the various candidates and then goes on trying them in sequence:

[139:401] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Udp (Step=0)
[139:401] [c8c] Jingle:Port[rtp:local:Net[0:192.168.254.100]]: Added port to allocator
[139:401] [c8c] Jingle:Port[rtp:stun:Net[0:192.168.254.100]]: Added port to allocator
[139:401] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:50:41 2006
[139:401] [8a8]    <iq to="juliet@gmail.com/Talk.v100C3349241" type="set" id="37">
[139:401] [8a8]      <session xmlns="http://www.google.com/session" type="transport-info" 
                                          id="3854034496" 
                                          initiator="romeo@gmail.com/Talk.v98734E454A">
[139:401] [8a8]        <transport xmlns="http://www.google.com/transport/p2p">
[139:401] [8a8]          <candidate name="rtp" address="192.168.254.100" 
                                                 port="1780" preference="1" 
                                                 username="GYPRLTG33vQGFOTZ" 
                                                 protocol="udp" generation="0" 
                                                 password="47CqsrM5wDUyYbiK" 
                                                 type="local" network="0"/>
[139:401] [8a8]        </transport>
[139:401] [8a8]      </session>
[139:401] [8a8]    </iq>

Following the specification the client determine the best connection from the candidates:

[140:462] [c8c] Jingle:Channel[rtp|__]: New best connection: Conn[0:rtp:local:192.168.254.100:1780->rtp:local:192.168.254.101:1237|C-w]
[140:462] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:50:42 2006
[140:462] [8a8]    <iq to="juliet@gmail.com/Talk.v100C3349241" id="83" type="result"/>

At this point, the client has established a preferred connection for direct RTP, but it nevertheless goes on and prepare a further connection through the relay, but as my call was local, it did not issued the corresponding candidate, instead connecting point-to-point through the local UDP candidate:

[141:464] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Relay (Step=1)
[141:464] [c8c] Jingle:Port[rtp:relay:Net[0:192.168.254.100]]: Added port to allocator
[141:464] [c8c] Connecting to relay via udp @ 216.239.37.126:19295
…
[142:525] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Tcp (Step=2)
[142:525] [c8c] Jingle:Port[rtp:local:Net[0:192.168.254.100]]: Added port to allocator
[142:535] [c8c] Jingle:Conn[0:rtp:local:192.168.254.100:1783->rtp:local:192.168.254.101:1240|--w]: set_connected

From this scenario, I can hazard a hypothesis about the way a GTalk client negotiates media relaying.

• The client uses a proprietary XMPP extension to query the relay service and receives an opaque token if the request is successful. I believe the token is destined to authorize a later use of the media relay to the client who made the request.
• The client then retrieves the appropriate relay parameters though HTTP, probably presenting the previous token as an authorization reference, and not through an XMPP interface as my source stated.
• The client then creates a transport candidate from the received parameters, and assign it a lower priority than the UDP and TCP candidates. It uses this candidate in the transport negotiation sequence. 

Although I am missing the proper test environment to verify my hypothesis, my first finding concens the inaccuracies in the description of an otherwise rather standard and expected technical solution. I leave you to decide why the mechanism has been described as XMPP, where in fact it appears to be a mix of HTTP and XMPP. I personally find this disturbing, as it can be leading to more inaccuracies of the sort finding their way into the Jingle specification. I am ready to accept that Google is concerned, but I do not believe disclosing this mechanism will ever put that company at risk. 

But, when I reflect on the position taken publicly by the authors of the XMPP Jingle specification in favor of using TURN to deal with media relaying negotiation, I am worried of the possible impact of their stand on the specification completion time and on the ensuing implementation by developers.

As I stated earlier, ICE and TURN are "work in progress" drafts, which have already been lingering at the IETF for over a year since Google announced the GTalk service. During that past year, the activity around the XMPP Jingle specification has been very slow to take up.

• On one hand, the specification has only recently been published toward a last call before JSF council approval.
• On the other hand, I believe the inherent complexity of media support libraries slows down the implementation of Jingle at the client level because developers need to master these new and unfamiliar concepts. 

Apart from notable support in open source IPBX, implemented by developers well versed in the intricacies of media communication programming, I only know of the the Jabbin project as a tentative implementation of a free Jingle client...

I believe it would not be realistic to push at all cost a Jingle specification highly dependent on forthcoming RFCs without any foreseeable time of publication of the said standards. The community would benefit more from an interim specification, leveraging instead existing RFCs, such as raw RTP, STUN and media relaying for NAT traversal, to be later updated when the ICE draft is made into an RFC. This approach would have the added advantage of being less complex from a programming stand-point, and would provide a more gradual learning curve for the developers to get accustomed to the subtleties of multi-media communication.

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, NAT, TURN, Antecipate

Media relay: the reTURN

I am coming back to the subject of using media relay proxies for hard to solve cases of NAT (Network Address Translation) traversals. From the ensuing discussions both on the JSF mailing lists, and through private mails, I have gathered two points which in my opinion illustrate perfectly why protocol definition requires an open mind of every moment. The first opinion was expressed as

I think we can both agree that relay is bad; it adds latency and requires server resources.

and the second as

Since you're already talking to a STUN server for ICE, it makes sense to get your media candidates from the STUN server (i.e., via TURN).

In the first case, the author is using what the list of "Fallacious Arguments" describes as a mix of Argument by Question and Changing the Subject to displace the problem. In his introduction to TURN, Jonathan Rosenberg expresses the fact that a media relay function comes at a cost:

Though a relayed address is highly likely to work when corresponding with a peer, it comes at high cost to the provider of the relay service. As a consequence, relayed transport addresses should only be used as a last resort.

But he does it in context, as someone writing a protocol enabling a media relay function. He does not question the validity of doing media relay, he merely points out that this is expensive, and he goes on explaining how, in his view, the protocol must be architected to allow the feature. We may have different opinions on how to tackle certain issues, but I respect his professional approach at writing protocols: he does not take a subjective view and question the legitimacy of using media relay, instead he propose a solution on how to do it. He does not presuppose a single usage of the technology; instead he admits that a use case may exist. He does not displace the problem to avoid it; he merely tackles it.

In the original discussion that led to the first point, the ICE negotiation used by Google in its version of Jingle was said to be successful in 92% of NAT traversal cases without the assistance of media relaying. Although this is a tremendous achievement, it still leaves out 8% of edge cases where this technique is ineffective. Taken from Google's perspective, this may look sufficient to serve its own users' population. But taken from a protocol perspective, it makes describing how the protocol must be extended to cater for these other cases necessary. And, following the concept of Argument from Authority, I will quote Jonathan Rosenberg again:

… if a client is behind a NAT whose mapping behavior is address or address and port dependent (sometimes called "bad" NATs), the reflexive transport address will not be usable for communicating with a peer.
The only way to obtain a transport address that can be used for corresponding with a peer through such a NAT is to make use of a relay.

I believe that at this point we have established media relaying as an integral part of the arsenal available to the developers to perform NAT traversals. Moving on to the second opinion, it is somewhat reminiscent of Causal Reductionism. Behind the very respectable attitude which consists in not re-inventing the wheel, lies a bias toward a particular solution because the author does not consider in which particular context this solution has been developed.

If we consider the context in which TURN was designed, I can safely pretend that it was strongly influenced by the SIP standardization effort. In essence, TURN was created to address a very real shortcoming is the signaling protocol: it has the same NAT traversal issues as the media streams because SIP allows the use of UDP as its own transport. This consequently implies that media relaying can only be discovered and negotiated on the same transport as the media itself. In comparison, Jingle does not experience the same shortcomings as SIP, as XMPP is vastly superior at dealing with NAT and firewall traversal. As a result, to the contrary of SIP, Jingle can be leveraged to provide the same answer than TURN to the question: what relaying IP:port address should my client use as a last resort?

A careful study of the TURN draft exposes how the shortcoming of the signaling layer (SIP) forces a large part of the signaling to be reincorporated inside the media transport. The solution proposed in the TURN draft also forces the TURN server to authenticate the streams, and by consequence to have access to user's authentication data. Knowing that a TURN server has to be exposed on the public Internet, I can only imagine how corporation will react at this requirement.

On the other hand, an XMPP extension to query and allocate an IP:port address on a media relay present at least two advantages:

• It would benefit from the inherent trust established at the user's login time on its home XMPP server.
• It would greatly simplify the media relay server, as the implementation of TURN is complex.

To conclude, I believe that the simplest solutions are always better at solving technical issues. In this particular case, the complexity of a TURN solution is not required to provide the expected service. A simple XMPP query can be devised to provide the same result.

Furthermore, I am certain that Google offering a VoIP solution in its GTalk service was the result of a thoughtful business process. But at the same time, Google hands off approach to motivate its developers, has left the implementation been only driven by a technical view point. When specifying the Jingle protocol, a problem arises if the same developers are also co-authors of the Jingle specification: they remain framed within the Google context of consumer oriented service and do not seem to apprehend the wider complexity of the enterprise. But it takes time to be able to recognise the difference between enabling solutions and building frameworks…

Technorati Tags: XMPP, Jabber, Jingle, SIP, VoIP, Session signaling, NAT, TURN, Antecipate

IPBX 2.0 anyone?

Andy Abramson had a struck of genius last night: he suddenly discovered that IPBX has a future in enterprises.

The future for Asterisk in my mind will be built upon adoption in the enterprise, not by small five to ten end point deployments

For all it is worth, I was under the impression the acronym meant something like "Private Branch Exchange", which does not hold any presumption on the size of what/who is privately using the exchange. As a matter of facts, nothing is precluding enterprises of any size to fall into that category.

Now one may ask why it has not happened yet, and why only "small five to ten end point deployments" are using Asterisk? Because Asterisk’s architecture is nothing but a POTS PBX with IP connectivity. In essence, it is similar to all the big telecom vendor's PBX offerings such as [add you favorite model from Alcatel, Avaya, Nortel, Siemens, etc… here], when they added VoIP support adaptors to make them "IP communication ready". At the core, these systems were still entirely subject to the tyranny of the "numbering plan". A rather rigid dependence, which is far from the flexibility provided by Internet's URIs.

In the end, Andy is right, the future of IPBX is in the enterprise, but any marketer fresh out of school would have said the same. On the other hand, I believe Andy is wrong and, because of its outdated architecture, Asterisk will not be wining this race. In my opinion, FreeSWITCH is a much better candidate to the title of IPBX 2.0 in the enterprise. It is build around the concept of what I would call a ubiquitous "signalling router" which captures the distributed nature of the Internet. Because of its routed architecture, this IPBX can be easily assembled in PBX grids and offer a host of standard IP signalling protocols for interoperability with many real-time communication and presence enabled systems. And obviously it knows how to bridge different media streams…

Technorati Tags: XMPP, Jingle, VoIP, SIP, IPBX, Phone system, Antecipate

Ostriches don't solve problems...

As reminded by Ken Kamp, entrepreneurs and executives sit around board room tables to discuss real business problems and look for real solutions to those problems. That does not include their existing phone systems, services, or expenses. Even less VoIP, SIP or Jingle… Let me illustrate by the following story.

The Capulet family has been running a flourishing wine business, and has succeeded by maintaining a tight focus on its core activities. They are well known for their almost real time customer service and their proximity sales service. Now that they are extending their reach well beyond the comfort of the provincial borders, they have signed up for the latest presence enabled real-time communication system provided by Veronizon.  The Capulets have long been running their own XMPP server for fast internal messaging. But they have to make sure all relevant business communications are seamlessly routed to the appropriate representative, without creating undue distraction. And this is precisely what the rule based presence engine of Veronizon's intelligent centrex service allow them to do. Obviously, the service offers all the necessary gateways to ensure that they could also reach their marquee customers or distributors wherever they are, and whatever communication system they use. And guess what, Veronizon charge its service on the number of rules held in the system, and by the number of time these rules are used. The communication time is free, which adds a compelling advantage in regards to the traffic based charges still in use at all other communication providers.

This is in my opinion a very likely scenario for many enterprises wanting to leverage IT and communications for what they are: a support for their business. And in this context what is any protocol's "raison d'etre" if not allowing the brightest entrepreneurs and service providers to propose adapted business problem solving responses to these enterprises.

If we examine the consequences for Jingle in enabling this type of service to be implemented outside the premises of the Capulet's business. We can easily see that the Jingle signaling path must be re-routed through the Veronizon centrex service in order for the relevant call routing decision to be made. Juliet which is working in the family's estate has programmed her personal centrex rule engine to forward immediately any call from Romeo to her. When Romeo select "initiate call" on his favorite client, Jingle will start negotiating a session with Juliet's client.

<iq to='juliet@capulet.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

The Montague XMPP server will faithfully route the request over S2S to the Capulet server. Following the contact with Veronizon, the Capulet server has received a new plugin that

• Filters all Jingle signaling stanzas,
• Reroute the filtered stanzas to the Veronizon centrex service.

thus making the service invisible and transparent to standard Jingle clients.

In order to enable the rerouting, the plugin modify the Jingle stanza by specifying the centrex service address as the new target, and adding a XEP-0033 extended address to retain the original target JID. The Capulet server can thus route the stanza to the centex service over S2S.

<iq to='centrex.veronizon.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid='juliet@capulet.com'/>
   </addresses>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

Upon receiving the stanza, the centrex service feeds the incoming request to Juliet's private rule engine, and determines that Juliet is currently available for taking Romeo's call on her "balcony" resource. The centrex service then modifies Juliet's JID to reflect her availability, and forward the stanza to the Capulet server over S2S for final delivery.

<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

In the end, customers don't care about what a protocol, a platform or any technical implementation is doing under the covers. They care about their business problems and solutions to those problems. Protocols and platforms are just the enablers for smart solution providers to deliver on their promises.

The danger for protocols' authors is to only consider the world through the lens of a 17 inches screen, as they may be losing sight of reality.  Just bluntly stating that a scenario is unlikely because one never thought of it or never came across it before will in no way make this scenario improbable. How many times have we heard stories about customers using an application or a protocol in a way nobody ever thought before? This is just how progresses are made. Protocol authors and developers often get sidetracked into how to achieve technical interoperability only. I unfortunately believe it is still rather common for them to proclaim that certain usage scenarios do not make any technical sense in the light of their own perception of the problems to solve, and to evade providing solutions by just “hiding their head in the sand”. Until they start to realize this attitude is not enhancing their reputation, they will be considered obstacles more than advantages by many solution providers who build solutions rather than platforms. And, as Ken put it, “those are the ones who will win in the market”…

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, Interoperability, Antecipate

They want to know everything

It appears that Google, tired of being reminded by its users, has finally implemented an important feature available on any other XMPP instant messaging server for its GTalk service: offline messages. And it has pushed the limit of integration by making these offline messages directly readable in GMail, as well as through any XMPP client.

All is good, all is great, until one reads the last line of the post:

Your Google Talk account needs to have a Gmail inbox with chat history enabled in order to receive offline messages, so make sure to turn it on now!

The offline message storage feature is only active if the chat messages history, which record all your conversations, is enabled in your account. In short, to capture the last message sent to someone who has just disconnected, Google needs to capture your entire chat history in real time. Come on! You are telling me no one in the army of Google's PhD level developers has been able to come up with a simpler solution to capture just these last second messages? I find this rather incredible.

Unless this scheme has been devised on purpose, forcing indirectly those who have made this very useful feature a top request to turn on the chat message history, and allow Google crawlers to search these messages…

Technorati Tags: XMPP, Google Talk, Digital privacy, Antecipate