Tuesday, May 09, 2006

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

Labels: ,