[Standards-JIG] Smack Jingle Development - XEP for Media Proxy negociation
jean-louis.seguineau at laposte.net
Mon Oct 30 20:18:08 UTC 2006
All valid points, Scott, no doubt. May I just point out that this points
address mainly the context where the Jingle clients negotiate an XEP-0176
(ICE)transport. Although I understand that this would be the ultimate
solution, we have to also take into account cases where raw UDP would be
In addition, if the media proxy is in the signaling path, the client would
not need to add the actual candidate, as the signaling part of the proxy
will do it. I agree that your point 2 is the most flexible as it caters for
case where direct connectivity can be achieved.
But you may also find cases, such as enterprise of service provider, where
media traffic will be forced to go through the media proxy. Just think about
accounting, or logging for compliance purposes.
In this case the proxy will have to strip out any candidate and add its own
instead. But this is not an issue as the proxy is always reachable.
In the end, we certainly need to come up with the appropriate disco for this
kind of proxy (how to discover the relay and stun servers over xmpp).
Adding a relaying capacity to Jingle will automatically solve your relay
session allocation, as it would become transparent to any client.
As to making the media proxy TURN, I would leave this to the implementation.
There are not that many TURN enabled media proxies around as TURN would
require a many SIP phones to be modified. You may not see this as an issue
for a consumer soft client, but it may be slightly different in an
enterprise ;) So I would rather have flexible support, with and without
> A couple points:
> 1> In Jingle, clients exchange address candidates. Once those
> candidates are exchanged, the enter into an ICE state machine, trying
> to establish connectivity through the local to remote address
> permutations. It's important that the client does this (not the
> server) in order to achieve the maximum traversal success rate.
> 2> One of the address candidates that gets allocated comes from a
> relay server. It has a lower priority, so it doesn't get used unless
> there is no other way to achieve connectivity.
> This is how Jingle works today. What isn't documented yet is:
> 1> how to discover the relay and stun servers over xmpp
> 2> how to talk to the relay server to allocate a relay session and
> address candidate
> 3> how to use this relay session from the client
> These will need to get documented. Ideally the relay server is
> ultimately TURN, so it won't need a specific XEP. The STUN server is
> standard stun.
More information about the Standards