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

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

Multi-homing Jingle

I described in an earlier post how some edge cases of NAT traversal for media steams could be solved using a media relay proxy. This kind of proxy is widely used amongst well know peer-to-peer VoIP implementations, such as Skype or SIP based devices. SIP based application in most cases use media relay proxies co-located with SIP border controllers (for service providers) or SIP proxies. Skype uses its clients that are not behind NATs to proxy data for clients behind NATs.
While discussing this subject on the JSF mailing lists, an important question have drawn my attention: How would Jingle allow a media relay proxy to be reached when it is not co-located with the client's home server?

The current Jingle specification has been designed with direct peer-to-peer communication in mind, and does not provide built-in support for intermediary relays on either the media path or the signaling path. The Jingle syntax provides a way to redirect a session to a different remote party if the original target is unavailable for the appropriate media communication. This feature is handy when several devices with different capabilities are online for a given user JID, or when the user has set his client to re-route calls to a voice/video mailbox.

However, nothing in Jingle allows for the use of a relay or an intermediary media proxy of any sort. An intermediary proxy has several application use cases. One is the media relay proxy to perform NAT traversal as described in my previous post. But any simple IPBX would equally benefit from this extension. The current flavor of Jingle does not allow referring to an IPBX as a separate server, which is the most common architecture found either at service providers or in the enterprise. Anyone would understand the interest of integrating with IPBX. The "numbering" plan for the IPBX could be defined purely in terms of URIs rather than extension numbers for example. And obviously all the expected exchange functions would be provided by a specialized application, including transparent bridging with other signaling and media protocols.

To that aim the Jingle specification can easily be extended by adding

• A discovery mechanism for intermediary media proxies, which will as usual leverage XEP-0030 Service Discovery. It boils down to defining the proper categories and features in the XMPP registrar.
• A mechanism in the protocol to allow defining a remote party URI independently from the destination address of the wrapping stanza.

Contrary to a redirection, which is an indication given by the remote party, relaying has to be requested by the initiating party. Once again we can simply leverage existing XMPP extensions and implemented the forwarding by using XEP-0033 Extended Stanza Addressing with Jingle.
In the now traditional context of XMPP examples, assuming Romeo's client has discovered that Juliet is only reachable through a relay media proxy, it would issue a request similar to this:

<iq to='relay.capulet.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid=' juliet@capulet.com/balcony '/>
   </addresses>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='this-is-the-audio-content'>
      <description xmlns='http://jabber.org/protocol/jingle/description/audio'>
        ...
      </description>
      <transport xmlns='http://jabber.org/protocol/jingle/transport/ice'>
        ...
      </transport>
      <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
        ...
      </transport>
    </content>
        ...
  </jingle>
</iq>

Just including an extended address in the Jingle stanza opens up a host of possible new applications without modifying the actual Jingle negotiation. It exemplify once gain the flexibility of XMPP.

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

Jingle media relaying

In an ideal Internet, each device would have a routable IP address all devices would be able to communicate end to end without any intermediaries except routers. In reality, devices connected on the Internet are using a NAT (Network Address Translation) function present in the border router. Using NAT, it becomes possible to connect multiple devices to the Internet by only using one public IP address. On the other hand, it becomes impossible to initiate connections from the Internet. Traversing NAT in both directions becomes an issue when doing point-to-point communications. This is particularly true when using RTP for multimedia communications.

A device behind NAT does not know much about how it will be seen from the Internet, it only knows its own IP address and the ports where the application runs. When communication with the Internet is established, the NAT function maps the IP:port combination of the device on the private NAT interface to a temporary public IP:port combination on the public interface connected to the Internet. Furthermore, the RTP transport protocol usually uses a random port. This means that users cannot just open a port on their NAT device for RTP.

Media consists of one or multiple streams which are negotiated in an associated signaling, such as SIP or Jingle. The signaling protocol allows devices to negotiate a set of common media. The negotiation is performed conveying information about the media streams, such as address where the media will be received, codec types, bandwidth, etc... The problem is that the signaling conveys information about the private IP of the device when it is behind NAT. There are two ways to solve this issue.

One is using a signaling protocol able to negotiate dynamically a communication path for the media even after the initial session has been setup. ICE (Interactive Connection Establishment) is such a protocol, which allows devices to probe for multiple paths of communication by trying different ports and STUN techniques. With ICE support devices have a good chance to handle point-to-point communication without any intermediary media relay. But ICE is awaiting full specification, and therefore only experimental support is provided. In addition, depending on the type of NAT, the communication might not be established even when using ICE. In this case a media relay proxy with a public Internet address must be used.

To transparently establish a multimedia session through a media relay proxy, it is best to use a service that associate the media proxy with a signaling proxy. The media relay proxy does the actual RTP traffic forwarding between the parties involved in the conversation. Upon request from the signaling proxy, it allocates sockets for each media stream of a session. The signaling proxy will use the media relay proxy's IP address and socket's port to replace the original values in the signaling payload. For SIP this would be achieved by modifying the SDP payload, for Jingle this would require changing the transport candidate. After this is done, the parties involved in the conversation will contact the media relay proxy thinking they contact the other party.

This approach is needed because the media relay proxy would then be able to determine the addresses from where the media streams originate. This information is unknown when the signaling takes place, and can only be determined when the RTP streams actually start.
After the media relay proxy has allocated the sockets for each stream, it will listen for an incoming packet from each of the two parties. Once these are received, the media relay proxy is able to know where the packets should be forwarded and can start relaying them between the parties. However, if one party has a public Internet address, the media relay proxy is able to send packets to it before it receives a packet from it, since the party's IP:port is already known. Because of this, it becomes possible to chain media relay proxies between them.

It is interesting to note that the media relay proxy solution is independent from the actual signaling protocol. Several solutions already exist for SIP, with the added complexity that SIP itself will require a NAT traversal solution when transported over UDP. I will describe how a media relay proxy can be implemented in XMPP using the Jingle signaling. As explained above, the media relay proxy must be on the public Internet. The easiest approach would in my opinion consist in implementing the media relay proxy as a component of an XMPP server, and install it into a DMZ. Doing so has the advantage of leveraging the trust relationship between the Jingle client and the XMPP server and extending it to the media relay proxy.

The XMPP server would have to be modified to route the incoming Jingle traffic through the component, which will in turn intercept and modify the Jingle transport negotiation payloads:

• For raw UDP transport, the component will replace the original transport candidate using the IP:port of a newly created socket.
• For an ICE transport, the component will create a new candidate using the IP:port of a newly created socket, and discard any other candidate directly by either parties. As the proxy is always reachable, this connection will always be established.

This example demonstrate that existing multimedia NAT traversal techniques can easily be adapted for Jingle, with the added advantage that the Jingle signaling itself is NAT and firewall friendly, which is not the case of SIP. This use case can also be extended by support both SIP and Jingle on the same media relay proxy component to provide seamless media connectivity between SIP and Jingle clients.

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

Jingling the MUC

I discussed previously how the XEP-0045 specification already contains all the management features to handle Multi User Communication (MUC), beyond simple text chat rooms. At the same time, I was interested to see that discussions are taking place at the Jabber Software Foundation about ways to integrate screen sharing and remote control into XMPP, as well as performing shared XML editing or SVG based white boarding.

MUC provides a very appropriate framework where these different applications can be aggregated. I have already explained how MUC exposes the required components of a generic conversation spaces management. One of the most important characteristics of conversation spaces is the possibility to host public and private conversation in the same space. In essence, conversation spaces simultaneously allow:

• point-to-point exchanges between participants,
• client-server exchanges, the conversation space being the server.

I believe people have finally come to realize the utopia of considering XMPP as an universal multi-media transport, although there are still bursts of "can I do VoIP over XMPP" here and there… When it comes to multi-media, Jingle is obviously the appropriate answer in the XMPP world.

I nonetheless feel there are still some misunderstandings with Jingle’s concept of separating sessions' establishment operations (signalling) from communication (transport) when a conversation involves more than two parties. In fact this is rather simple. In a Jingle enabled MUC, in addition to the existing XEP-0045 specification the service will only need to implement:

• Jingle support for each multi-media conversation spaces in order to answer session requests made to the space JID.
• Jingle stanzas' forwarding for session requests made to a space's participant JID.

It is easy to understand that private Jingle session requests made though a MUC are strictly equivalent to session requests between two clients made through a standard XMPP IM server. It is equally easy to understand that the point-to-point media transport between the two participants' clients will take place out of band using the appropriate negotiated binary protocol.

The same scenario applies in a conversation space, when several participants share the same media during the conversation. The difference with the above case lies in the type of end points involved in the point-to-point communication. In order to share a particular media, a mediator system has to combine each individual media flows produced by the various participants into a single media flow. This mixer role is usually played by specialized bridges, or even IPBX, when it comes to voice and video. In the particular case of VNC, I am under the impression this protocol has always been used as a pure point-to-point communications between workstations. As the typical use in the context of a MUC would mostly involve a one-to-many communication (one master screen shown to many participants' clients), adapting VNC screen sharing would require implementing some sort of repeater system.
This same one-to-many communication also applies to streaming media servers that could be used to broadcast inside the conversation space.

In the end, I believe the MUC protocol bears much more than its current limited usage for text chat rooms. I have just tried to illustrate some of the extended possibilities. I am not saying it will be all done in one day, but the proper bricks are already in place.

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

Multi user communication

In the XMPP parlance, MUC refers to "Multi User Chat". The specification foreword highlights the textual aspect of the communication by referring to other similar text based systems.

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services.

In the wake of the growing use of XMPP as an application platform, I am convinced XEP-0045 go far beyond text chat rooms. The specification can easily be extended beyond text to any form of conversation space involving several parties. The word "room" is used throughout the document, and may appear somewhat linked to "chat room". But, leaving this restrictive interpretation aside, we can easily see that almost every concepts used can be applied to the wider scope of conversation spaces.

The first important aspect of the specification is the capacity of its definitions to be applied without changes outside the limitative text communication scope.
The specification provides an exhaustive list of spaces types, such as public (Open, Public) or private (Members-Only, Hidden) spaces, identified (Non-Anonymous) or anonymous (Fully-Anonymous) spaces, temporary (Temporary) or permanent (Persistent) spaces. One can refer to the specification for an exhaustive description of these types. The important point being that these types of spaces are somewhat independent of the actual means of communication used inside the space. They would apply equally well for text, voice or video, or any combination thereof.
Similarly, the specification goes to great length at defining the roles (Moderator, Participant, Visitor) and affiliation (Owner, Admin, Member, Outcast) any participant in a conversation space may acquire, as well as the rules and privileges a compliant implementation must provide in relation to these roles or affiliations. Once again, none of these definitions are specific to text communication. They remain valid for any kind of conversation space.

The second important point is the reliance on presence for the actual conversation spaces functioning. Entering or leaving a space is entirely driven by presence. And the XEP takes great care at defining the associated presence broadcast behavior.
The third important point is the definition of all the management actions that may be associated with a conversation space. For a space owner, it defines a wide range of configuration options. For a space administrator it allows to modify persistent information about user affiliations (e.g., banning) and to grant or revoke moderator privileges. Here again, there is nothing specific to text only communication.

The last important point lies in the possibility to use an XMPP address to refer to any conversation space, and any participant in the space. This fined grained addressing is the key to the extensibility of the "Multi User Chat" to "Multi User Communication". It is easy to imagine that a multi-media conversation space will use Jingle to extend its media capabilities beyond text only. As the conversation space is presence enabled, it will broadcast its capabilities to any client entering the space, while receiving the client's one. Similarly, the space will also broadcast the new participant's client capabilities to all existing participants, thus allowing multi-media private conversations to take place. A Jingle enabled client would then be able to negotiate a voice or video session with a multimedia space seamlessly. It does not matter if the multi-media implementation is entirely provided by the MUC service, or handed over to specialized audio or video bridges.

In the end, the MUC specification is a very important enabler for building advanced communication application, beyond text only. It provides a ready made framework to manage conversation spaces and participants. It is another perfect example of the maturity of the protocol and of the growing importance of presence in application. As I have mentioned earlier, XMPP has reached a stage allowing many application usages from its existing features set. It is just a matter of imagination and creativity…

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

Beyond file transfer

Following the official release of the latest GTalk client, I decided to scratch the surface of its file transfer implementation. Thanks to Brian McBarron’s answer posted on the JSF list explaining how to capture a detailed log of the client’s operation (run the client with the following arguments: /log verbose tstamp thread file), I was able to confirm that the GTalk client is indeed leveraging Google’s implementation of Jingle to control file transfer. This endorsement by Google is another commitment to open standards. As shown bellow, the receiver party’s presence is probed before the transfer, in order to make sure the target client understands the transfer protocol. This is returned in the presence stanza’s capabilities extension. It is interesting to note that the capability is named “share” rather than transfer.

<presence to="juliet@gmail.com" type="probe" />

<presence to="romeo@gmail.com/Talk.v969557A95E" from="juliet@gmail.com/Talk.v95286273DB">
  <priority>0 </priority>
  <c xmlns="http://jabber.org/protocol/caps" ext="share-v1 voice-v1" ver="1.0.0.95" node="http://www.google.com/xmpp/client/caps" />
  <x xmlns="jabber:x:delay" stamp="20060817T19:50:07" />
  <status>available </status>
  <x xmlns="vcard-temp:x:update">
    <photo>ae825c56c617f83a577b0cff43611d2076358c20 </photo>
  </x>
</presence>

The next exchange uses the actual Jingle signaling to negotiate a transfer session between the parties. I have only shown the session part, as the point-to-point transport negotiation is identical to a voice transport negotiation. Note again the description namespace for the application.

<iq to="juliet@gmail.com/Talk.v95286273DB" type="set" id="31">
  <session xmlns="http://www.google.com/session" type="initiate" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E">
<description xmlns="http://www.google.com/session/share">
  <manifest>
    <file size="34314">
      <name>
        About.jpg
      </name>
      <image width="150" height="133"/>
    </file>
  </manifest>
  <protocol>
    <http>
      <url name="source-path">
        /temporary/6b82cd1ca2f333d99bad2ea07ce33f33/
      </url>
      <url name="preview-path">
        /temporary/9c6b15f343aaabea3c6a106eb72b4c80/
      </url>
    </http>
  </protocol>
</description>
<transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="romeo@gmail.com/Talk.v969557A95E" id="31" type="result" from="juliet@gmail.com/Talk.v95286273DB"/>
<iq to="romeo@gmail.com/Talk.v969557A95E" type="set" id="49" from="juliet@gmail.com/Talk.v95286273DB">
  <session type="transport-accept" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E" xmlns="http://www.google.com/session">
    <transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="juliet@gmail.com/Talk.v95286273DB" id="49" type="result"/>

FIle transfer is an important adjunct to Jingle, as it confirms the signaling can be used well beyond voice or other video communication. This is not revolutionary per say, as session negotiation and signaling has been around with SIP for some time now. But only proprietary extensions of the SIP signaling have been so far implemented when it comes to widely deployed file transfer. The use of Jingle bears the promise of a much wider adoption for a standard based file transfer negotiation. Obviously, this is only Google’s implementation of Jingle, but except namespaces, nothing in it cannot be made into a JEP. And this is what the authors of this file transfer are committed to do.

Coming back to my initial remark about the GTalk client’s naming this new feature “share”, I believe this update is only the pre-release of a larger scoped real-time experience. Brian’s post on the JSF mailing list gives a good explanation of the layered design applied to the file transfer application. By adopting this architecture, I believe Google is effectively enabling far more than just file transfer:

• the transport protocol called “PseudoTCP” which is used in the p2p exchange is a Google re-implementation of TCP using UDP packets. The layered design would allow replacing this proprietary transport by a standard, such as SCTP, without disrupting the network stack so much.
• the application protocol is HTTP enables interesting things such as download previews of images, resume transfers, compress files, etc. Without being full fledge web servers, a GTalk client becomes an important part in enabling a real time collaboration application. Linking it to a workstation’s browser through some toolbar plug-in is probably not that difficult, and would makes an XMPP backed real time photo sharing and comment experience much more compeling than their web only siblings.

Although this latest release has received unjustified bashing from many ignorant self proclaimed visionaries, I believe on the contrary that it is paving the way toward wider scoped real time standards-based sharing services for communities, open to any and all that wish to interoperate with them.

Technorati Tags: XMPP, Jingle, Conversation spaces, Session signaling, File sharing, Google Talk, Antecipate

Jingle nostalgy

Kind of fun, some of the definitions of “jingle” on the web (define:jingle for search aficionados)

Jingles are memes constructed to stay in one's memory and people often nostalgically remember them decades after, even after the brand has ceased to exist.

And searching on “meme”, you will get to:

Just as genes propagate themselves in the gene pool by leaping from body to body via sperms or eggs, so memes propagate themselves in the meme pool by leaping from brain to brain via a process which, in the broad sense, can be called imitation. ...

So was the GTalk launch just a “me too”? I leave you to reflect on an answer…

In the meantime, I am waiting impatiently for the next Jingle specification version release. Peter, where have you been?

Hopefully, this version will incorporate some necessary enhancements such as

• the support for multiple media description,
• a better glossary,
• a clear disconnect from the GTalk inspired transport negotiation.
• …

Technorati Tags: XMPP, Jingle, Conversation spaces, Session signaling, Antecipate

We must not transport Jingle!

XMPP has from the beginning build a reputation of inter-operability through its ability to communicate with disparate instant messaging systems. Just look at the number of public IM transports in service today.

There is no reason why this inter-operability could not be extended to the VoIP or multimedia communication as well. The XMPP community is working at making Jingle a robust signaling framework, with the same extensibility in mind as the rest of the protocol. That said, VoIP services comes in ever increasing flavors and numbers, each with its own way of providing its service. Bridging between Jingle and VoIP providers using the same transport design as for public IM transports will not scale. Not from a protocol view point, but from an identity and addressing perspective!

In a traditional XMPP transport, the end user usually goes through a registration phase, providing some sort of credentials, and above all, a valid address handle for the target communication system. Existing transports either store this information locally on the hosting machine, or use some non standard mechanisms (see <xdb/> packets in jabberd) to delegate the storage to the associated XMPP server.

Doing so creates a large number of “identity islands”. One such islands for every installed transport, holding in some not always secure store the association of an address handle and credentials. I do not believe this to be a good practice from a security stand point. Neither is it an efficient design because of the multiplication of sensitive information in different locations.

If you do not expose yourself much by “trusting” your public IM credentials to an XMPP transport (except if you use your public IM account as a trader of course), it becomes a different game when you start using paying services, such as PSTN voice gateways. You would not be happy to have some happy GTalker charging your credit card by calling its Grandma at the other side of the earth…

We must not apply the current monolithic self contained transport design to Jingle. The context has evolved to a larger communication space. We have a good opportunity to learn from experience here. There are numerous discussions going on in the Internet digital identity world on the subject of minimizing identity exposure. Everybody complains about the ever increasing need to provide identity related information for all sorts of service available on the Internet. These security trends include, but are not limited to, making sure the end user is in control of its identity, as well as using assertions to derive authorization. Trends also clearly indicate the limitations incurred by using address handles as identity identifiers. This is not exactly how the original Jabber transport were built. I believe it becomes important to incorporate these new trends, ready ourselves and rethink our existing implementations, and prepare better ways of handling identity and querying about addressing.

Technorati Tags: XMPP, Jingle, Jabber, Addressing, Identity, Digital identity, Trust, Antecipate

Jingling in conversation space

Being a good listener, I am always surprised when starting a conversation to realize how different meanings’ interpretations often lead to a lengthy preliminary exchanges before reaching a common context understanding. As explained by Seth Ladd,

I believe meaning is relative, and that the reader, with their unique experiences and perspectives, will always interpret things in their own way. The readers, or consumers, will always have more power with regards to information interpretation.

Communication is a paradox of a subject, and what he says about readers attitude can easily be extended to mailing lists’ participants. I particularly like Seth’s final statement

It’s very possible that conversations between semantic web agents will be required to come to a sort of shared understanding.

I don’t know if participating to a mailing list thread makes us “semantic web agents”, but we definitively need this “shared understanding”. This is why I am adding to my previous post to further build that shared understanding around Jingle. I was prompted to do so remembering the difficulty I had on the JSF mailing list to convey the difference between Jingle as a framework and its application in setting up multimedia sessions. In fact, the confusion came from this word: “session”. Every time I used this word, I was referring to a communication taking place between participants in a conversation space, whereas my interlocutor was referring to the underlying RTP sessions…

I believe Jingle has all the qualities to become a widely adopted way to manage sessions in conversation spaces. We must be careful not to let Jingle be positioned as “yet another signaling” protocol, or it will only be perceived as a SIP imitation. This would be the worth positioning. Jingle is larger than just P2P VoIP, in the same way presence is larger than just instant messaging. Referring to my previous definition of “conversation space”, from a protocol stand point Jingle should allow the complete management of conversations in a given space. From the simple one-to-one phone call, to the more complex collaborative meeting mixing MUC, document sharing and multimedia streams.

This is unfortunately not the case at present time, as the Jingle glossary is both inconsistent and very limiting. For example, sessions are defined in JEP-166 as “a negotiated transport method and media description format connecting two entities”. The use of singular points to a single media/transport relationship. It is obvious using this definition, that we must use several Jingle sessions to become participant of in video conference. At least one Jingle session for audio, and one for video. Even SIP is doing better than this. A Jingle negotiation must allow negotiating several media descriptions at the same time. I believe we could even negotiate several media/transport relationships in a single Jingle negotiation. As an illustration, imagine a multimedia mobile phone becoming part of the previous video conference while roaming. The user has joined the conference while sitting in its favorite Internet cafe, with an adequate network connectivity. The conversation space is provided by a Jingle a multimedia conference server, and the negotiation is taking place between the mobile client and the server. Remembering its next appointment, the user decides to drive to a meeting outside town. Being a careful driver, it will decide to mute its microphone, hold the video streams, and only leave the incoming audio on, so it can listen while driving. The user also updates its presence state and PEP profile to indicate it is driving and cannot be disturbed. At some point, during the conference, documents are shown. The user decides to stop and have a look. It does it by re-enabling the video stream. It may decide to intervene in the conversation after un-muting its microphone. I believe the user experience will be greatly enhanced if all these media are part of a single conversation space, presented and managed as such. From an implementation perspective, it is easy to understand how control operations are more efficient when all media negotiations have already been carried out and referenced by a single session ID. Adoption requires ease of use and low client complexity. Its better to maintain states on a server and only pass a reference to a client. It is easier to group media streams together if the have a common root session identifier.

From a protocol definition stand point, I believe Jingle purpose must be widened beyond “peer-to-peer sessions” to manage conversation spaces sessions. With this definition, we open the perception of Jingle to multi-peer and client server sessions. I also propose to rewrite the definition of session as “the relationship linking together a dynamic set of multimedia senders and receivers and the data streams flowing from senders to receivers”. A wider definition in the protocol will result in allowing real multimedia (i.e. several media) management capability for a single communication space session.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, SIP, Session signaling, Conversation space, Antecipate

In the Google Jingle jungle

I find the presentation of Libjingle on the Google coder page a typical example of misleading documentation. Anyone reading this presentation is bound to assume that Jingle is for peer-to-peer communication only. Many are also referring to Google’s proprietary implementation as Jingle audio, which is a second misnomer. How could we create credible communication protocol if we cannot agree on a common language to describe the protocol usage and implemented technologies. My visit to the Libjingle pages came the other day as I was trying to separate reality from fiction behind the recent Jingle support announcements made by Asterisk and FreeSwitch. In fact, they only relates to the support of GoogleTalk. And this is not Jingle, whatever Google may say on the subject.

Google Talk uses a proposed extension to XMPP known as Jingle which can traverse many types of NATs, to establish peer-to-peer connections. The Jingle protocol is based on Interactive Connectivity Establishment (ICE), which is very successful in bypassing NAT. The core idea behind ICE is that the only way to determine the best way to connect to another user is to try every way, and use whichever works best. In that vein, when a peer-to-peer session is initiated, each client creates a list of possible addresses for itself. Each potential address is called a "candidate." Then, each client creates connections using every permutation of local and remote candidates possible and transmits data using the highest-quality connection.

Let’s have a look at the Jingle framework as proposed by the JSF. To date the Jingle media stack look just like this:

It is comprised of the main session management framework, media descriptions such as audio and video, and of  several transport descriptors. Three different transport negotiations JEPs are available within the Jingle framework. All of them use datagrams over UDP at the network level. Two of them rely on RTP as the transport protocol, and one is based on the Asterisk inter-exchange protocol.

Interpreting the description available on Google’s coder site, I am inclined to believe that what they call “Jingle audio” is in fact the combination of Jingle, Audio and the RTP-ICE transport. If this is the case, then the “Jingle support” for Asterisk and FreeSwitch is just a particular subset of the Jingle specification as highlighted bellow:

In reality, what has been implemented in the two IPBX is the support of GTalk, or more specifically the support of the Libjingle signaling, as it seems to be the library of choice for other XMPP clients in the making. I am certain every XMPP client developer will be eager to implement the specification as defined by the JSF. But they will also be forced to implement the GTalk distortion of the specification. And this will be a long status-quo, Google not being a philanthropy driven organization. They benefit from the hype created around Jingle and their use of an ‘open’ protocol such as XMPP. Will they spend the money to update all the GTalk clients to support the real Jingle as they claim remains to be seen. In the meantime, Google will benefit greatly from these open source PBX supporting their subset of the Jingle specification. This company has been great at leveraging open source for its own benefit. They will certainly not miss this opportunity of having two platforms allowing them to bridge between GTalk and SIP based VOIP networks, or to terminate GTalk calls on the PSTN…

But what of the rest of the world? I will try to define the base of a truly inter-operable Jingle implementation should be. Google explains the choice of ICE to negotiate and modify the RTP streams by issues related to NAT traversal. This is mentioned several time in their description. This is certainly plague for many VoIP clients, and identified as such in the recent H325 workshop. When asked what could be done about it, clever geeks came up with the clever idea of using ICE in GTalk. With a single clever move they left out all the VoIP clients using RTP on raw UDP for the media transport. When you think of it, this is just the vast majority of the SIP soft phones, and probably all the IP hard phones out there! Is this showing consideration for inter-operability? I doubt it. The enterprise market will obviously want to leverage the huge investments they made in SIP as a result of their listening to all the big telco vendors. A growing population on the Internet is using SIP based soft-phones as an alternative to the proprietary Skype. I would have thought one of the ways to show how superior XMPP is, would have been to enable voice communication with these SIP soft phones. I do not consider it such a distant dream to have a Jingle client holding a voice conversation with one of those SIP soft-phones, or IP hard phones. But that requires the real support of raw UDP in the Jingle libraries. It would mark the beginning of the kind of media inter-operability I mentioned in a previous post. Jingle to remain a player as a standard must extend the GTalk only model to include RTP/UDP transport. And as good protocol standards must define minimum mandatory requirements, I believe the base Jingle audio stack must look like this:

Implementing this base Jingle stack in clients and servers will greatly facilitate the emergence of XMPP as a strong VoIP player. Just look at the Libjingle media components, they are used by a number of public IM clients, and several IP phones. At least there is already compatibility at this level. Let’s make sure we do not miss the media transport compatibility. Doing so, Jingle will appear both protecting the investment through its support for legacy UDP/RTP transport, and extensible by its early adoption of ICE. On the server and IPBX side, I believe this extended support will make it easier for the community to quickly develop simple proxies or gateway to SIP, the other prominent signaling protocol.

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

Voice services use cases

I started a thread on the JSF protocol list earlier to define categories to be included in the JSF registrar for discovery of media services. I believe we have reached some consensus, but as a drawing is always worth a thousand words, I have illustrated a few use cases to show how these categories could be used.

In the JSF registrar lingua, gateways provide connections to other services/networks so that XMPP entities can communicate in certain ways with non-XMPP entities. On the other hand, proxies are server-side or middle-side helpers that enable you to communicate in certain ways with other XMPP entities. An entity can provide both a gateway and a proxy service, as the two categories are not mutually exclusive.

I have chosen three use cases, I believe easy to put in perspective with existing installations.

PBX front end: in this example, a Jingle gateway is facing the XMPP network and offering discovery, feature negotiation and jingle session signaling services to the client applications.

The drawing shows a Jingle soft phone client, but it could be any Jingle XMPP application, including another PBX front end. In this later case, it will be possible to build an overlay signaling network based on Jingle.

XMPP/SIP gateway: this example shows only a multimedia session negotiation gateway.

The drawing illustrate how two voice clients using these two different signaling protocols could negotiate an audio session. Again, the drawing shows soft-phones, but it could be any kind of SIP audio user agents communicating with any Jingle XMPP application.

Rate based routing: this example represents an XMPP only application, where several Jingle VoIP service providers are offering call termination to the PSTN at different competitive rates.

A Jingle enabled aggregator is exposed to the XMPP network through discovery, receiving instant call rate information from the different VoIP providers via JEP-60 PubSub. The Jingle client will initiate a voice session with the Jingle proxy, which in turns will decide according to its internal rates tables and rules to redirect the Jingle session to one of the VoIP services.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, SIP, Service discovery, Session signaling, Antecipate

What on earth is call control ?

When researching about VoIP, PBX or phone service, you will certainly come across these words: call control. You will find it everywhere reading telecom oriented documentation. On the other hand if you search for a reference to call control in the XMPP Jingle related pages, your result set will be mostly irrelevant. And this is not because (insert your favorite search engine here)'s crawler did not read these pages, but more simply because nobody actually took the time to describe it and associate it with Jingle. I am going to try and fill this void.

Call control is the manipulation of session and media relationship affecting the experience of participants in a "conversation space".

There are several definitions of “session” on the web. I could use this one: “Each instance of a service. Sessions start when the service is first provided and close when the service is ended. A user may be allowed to have multiple sessions active simultaneously.” In the context of multimedia communication, a service is simply what supports the ability to communicate between a pair of participants. In XMPP, the willingness to establish a service session relationship is managed by the session level of the Jingle framework.

The communication between the “participants” is supported by a variable number of communication media such as voice, video, text, etc. A session comprises a dynamic set of multimedia senders and receivers and the data streams flowing from senders to receivers. In XMPP, the choice of these media, their characteristics, as well as the dynamic modification of their usage rules is managed by the media and transport levels of the Jingle framework.

At this point, we can call a participant an entity able to send an original version of a media, or receives a media, and terminate a media. In short, a participant is a end entity in a conversation, using mutimedia senders and receivers. This definifion excludes the intermediaries entities such as a media mixer or a conference service.

And finaly, we can define a “conversation space” as the set of participants having access to all the media sent in the context of that space. A phone call is a simple conversation space, as is an IM chat session in XMPP. A MUC conference room is another conversation space, as is a voice conference call.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, IPBX, Session signaling, Conversation space, Call control, Antecipate

Phone numbers JID or extended address?

At this point, XMPP lacks a standardized way of addressing of a PSTN number. As usual, in order to achieve this definition, I would advocate re-using existing published standards and adapt them to the XMPP adressing scheme.

I see two different approaches to solving this issue:

• Create a syntax to express a phone number as a JID.
• Make use of the extended stanza addressing and include an existing URI scheme using the external uri form of the address element.

On one hand, XMPP entities are addressable with an URI containing a set of ordered elements formed of a domain identifier,  node identifier, and resource identifier. In short a JID looks like node@domain/resource. This form is similar to existing addressing schemes defined to represent a phone number. So it should be easy to define an appropriate syntax to incorporate a phone number in the node part of the JID. A possible approach could be to map the JID node to an  E.164 number (international public phone number) and create a JID of the form +15551234@domain/resource.

On the other hand, the extended addressing approach requires adding an address extension to every stanza targetting a phone number. But in this case the extension directly holds the phone number URI without any need to define an additional syntax for the JID. We could then use the tel URI for telephone number existing IETF standard. As this approach is also used by the SIP signalling protocol when dealing with phone numbers, it could simplify gatewaying to SIP based VoIP networks. An extended phone address would lokk like:

    <addresses xmlns='http://jabber.org/protocol/address'>
        <address type='to' uri='tel:+15551234@domain'/>
    </addresses>

Both approaches have pros and cons.

Pros: the phone JID is easy to understand and can be handled like any other JID, allowing for example to define contacts in a roster directly as phone numbers. The extended addressing decouple the phone number representation from XMPP, and is directly usable in gateways, and allow all the semantic of the phone URI without impacting XMPP.

Cons: the phone JID implies a specific semantic in the addressing scheme. In short, there is logic in the address, and a compliant implementation must decode the JID to extract the phone number. The extended addressing is slightly more difficult to implement and render in a traditional XMPP client.

If we have this standard addressing scheme in place, then it becomes easier to hide many of  third party providers addressing disparity behind a Jingle service implementation. My recommendation is to use the extended addressing approach, as it would be wrong to overload the XMPP JID scheme with adressing format logic. A JID’s primary role is to allow stanzas routing to a destination. We must keep it that way.

Technorati Tags: XMPP, Jingle, Jabber, Addressing, Phone number, Session signaling, Phone system, Antecipate

Media service discovery

In a previous post, I discussed how using XMPP could fulfill the requirements expressed by the H325 working group. XMPP networks provide a standardized ability to discover information about entities on the network. This mechanism allow to query for information  such as features offered or protocols supported by an entity, the entity's type or identity, and additional entities that are associated with the original entity in some way. This is an invaluable advantage over existing protocols when it comes to negotiating sessions in communication spaces. In a multimedia network architected around a clear separation between call control logic and service control logic, this capability will be put to use to discover multimedia services.

As explained in the XMPP enhancement final standard, this is a multi step process. The first step involves discovering the service address. This is achieved  by issuing a generic item discovery to one’s XMPP home server.

<iq type='get' from='romeo@montague.net/orchard'>
    to='shakespeare.lit'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

The server response will look something like:

<iq type='result'
    from='shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='people.shakespeare.lit'
          name='Directory of Characters'/>
    <item jid='jingle.shakespeare.lit'
          name='Play Media Gateway’/>
    …

  </query>
</iq>

The next step involves requesting information for each of the discovered services. The requesting party’s client application will loop through the discovered items to obtain each item’s identity and supported features. It will issue a targeted information query to each item address in turn. Among them, the media service information will receive:

<iq type='get' from='romeo@montague.net/orchard'>
    to='jingle.shakespeare.lit'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

And will return its information set in a response along the lines of:

<iq type='result'
    from='jingle.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        type='voice'
        name='Play Voice Conference'/>
    <identity
        category='directory'
        type='chatroom'
        name='Play Voice Conference'/>
    <identity
        category='proxy'
        type='voice'
        name='Play Private Exchange'/>
    <identity
        category='gateway'
        type='voice'
        name='Play Public Exchange'/>
    …
    <feature var='http://jabber.org/protocol/jingle'/>
    <feature var='http://jabber.org/protocol/jingle/media/audio'/>
    <feature var='http://jabber.org/protocol/jingle/info/dtmf'/>
    …
  </query>
</iq>

This simple (non normative) example illustrates how existing XMPP standards may be immediately put to use in the context of a multimedia network to easily discover the available multimedia services. In this specific case a client application has been able to discover a service providing voice conferencing, private branch exchange functions as well as gateway capability to the public phone network. Obviously the service is based on the Jingle framework, for which some features are advertised. And in addition, the client application only needs to know about Jingle. Nowhere in this step is the client aware of the service implementation, and this bodes well with the H325 requirement stating that

… intermediary devices and various service-providing entities may be present in the network to facilitate call establishment, similarly to the way that Gatekeepers or SIP proxies operate today. When a service is invoked, the service will be controlled from within the network, allowing the endpoint to remain ignorant of exactly what the service is or how it works.

The important concept here is the deconnection between the service implementation and the discovery mechanism. The next step for the client application would be the capabilities negotiation, but this is another matter.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, SIP, H325, Session signaling, Service discovery, Antecipate