[Standards-JIG] Smack Jingle Development - XEP for Media Proxy negociation

Scott Ludwig scottlu at google.com
Mon Oct 30 19:56:41 UTC 2006

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.

On 10/30/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> This is exactly the context in which a media relay server collocated with
> the XMPP home server makes perfect sense. In addition, media relay servers
> can be chained together.
> This is the simplest approach, as
> 1/ it does not require modification on the client side, which would be the
> case to add TURN support.
> 2/ it works with the current Jingle XEPs without addition.
> But as Peter points out, it is not the only possible solution, and I
> entirely agree that having RTP media relays as standalone Jingle services
> would be great.
> In this case, we would probably need an extension to Jingle to include the
> relay into the signaling path. Unless I am missing something obvious, in the
> current release of Jingle, the protocol only supports peer-to-peer
> negotiation. There is an option for redirecting a session, but nothing for
> relaying/forwarding a session request. I believe adding a relaying
> capability in Jingle will give us more flexibility. This would be similar to
> implementing the difference between the To header and the request URI in
> SIP, where the To header represents the actual remote target UA URI and the
> request URI the next hop to which the packet is sent.
> Think of it in a wider scope, as an RTP relay proxy is actually independent
> from the signaling protocol. It would open the door to multi-signaling
> protocol relay proxies, supporting both SIP, Jingle and [add your favorite
> signaling here], for example. It would also allow Jingle enabled IPBX to be
> used as stand-alone Jingle nodes in an internet wide VoIP network.
> My $0.02
> -----Original Message-----
> Date: Mon, 30 Oct 2006 11:53:02 -0700
> From: Peter Saint-Andre <stpeter at jabber.org>
> Subject: Re: [Standards-JIG] Smack Jingle Development - XEP for Media
>         Proxy   negociation
> To: Jabber protocol discussion list <standards-jig at jabber.org>
> Message-ID: <45464A0E.7060606 at jabber.org>
> Content-Type: text/plain; charset="iso-8859-1"
> Sure, it's cool if an XMPP server offers the RTP bridge as an extra
> service, since we already have the signalling channel open. But it
> doesn't have to be my "home" server that does this, right? I mean, it's
> quite similar to SOCKS5 Bytestreams, no?
> But hey, if we really want to simplify things, the XMPP client could
> tell its server that it wants to set up a media session with a contact
> and the server would do all the hard work of session establishment. :-)

More information about the Standards mailing list