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

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