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.