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'

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”…