[Jingle] rtpbridge

[Jeff Muller]

"Jeff Williams" <jeffw at gadgetworks.com> wrote in 
message news:90D1B307-A8A3-4FC3-84F8-970EE125B94C at gadgetworks.com...
STUN == P-to-P  socket *discovery*
RTPBridge == P-S-P bridged socket *connections*

RTPBridge is orthogonal to STUN.  You use one or the other.  RTPBridge
is something cooked up (outside of standards bodies) by the Ignite
guys to address the cases where STUN doesn't work for the simple
reason that you cannot reach a client port behind a NAT because it's
prohibited by router policy.  While a cool idea, it's unlikely to ever
get any traction for the reason that no SA is going to want their IM
server to carry the RTP streams for 2x ends of their entire user
community and their buddies.  (Plus if the XMPP community was going
this way it would probably look to TURN, and then only as a last,
desperate measure for any single P2P connection.)

In the Ignite world of products you have clients based on a Java
library called Smack.  Then Ignite has a separate server product
called OpenFire.  Your Smack-based client has to *invoke* client-side
RTPBridge as its stream/transport mechanism.  The fact that you're
using LibJingle pretty much means you have 0% chance of making this
work unless you implement RTPBridge in LibJingle.  Then if you do the
only server that will support it is OpenFire, and then only if it's
enable/configured.

STUN really is the way to go.  It's an imperfect solution, but it's
the work of a group that spans many different projects that all would
like to discover a client's socket behind a NAT firewall.  NAT
traversal *seems* like an easy problem on its face, but the nuances of
global network topology and router policy make it really tough.  And
there are some cases where you simply cannot connect to a client
socket behind a NAT unless someone makes a router policy change.  I
have no clue about the state of STUN support in LibJingle.

Welcome to our world!  :-)

Jeff

El Nov 24, 2008, a las 09:07 , Jeff Muller escribió:

>
> psa et al.,
>
> Also.... isn't this a way to get a password & username to use with  the 
> relay server (if your relay doesn't allow arbitrary connections)?
>
> I was told to email Thiago because he may have more info about  rtpbridge, 
> but he has not responded. Thiago, are you around?
>
> Here's my problem... our server guy has said that we have a relay  server 
> on our server because he added the rtpbridge, and he pointed  me to the 
> igniterealtime page ... so now I have to figure out how to  use it. I am 
> currently using (original) LibJingle as my stack, and I  don't want to 
> have to rewrite too much (more than I already have).  If the underlying 
> rtpbridge media relay server handles STUN Allocate  messages, and just 
> uses the xmpp messaging of <rtpbridge/> to sort  or "pre-allocate" ports 
> and handout passwords for them, then I just  need to know that, and any 
> other details to get it to work. If it's  something completely different, 
> it would be nice to know that too.
>
> Sorry to keep going on about this, but we're light on resources, and  I'm 
> just spending way to much time on this right now, with not a lot  of 
> success.
>
> Thanks for your patience :-)
>
> Jeff
>
>
>
>
>


Jeff,

Thanks. I realize the distinction. I guess I was thinking more of TURN, 
which I thought of as an extension of STUN messages (is that incorrect?).

My problem is that I have gotten to the point where I'm testing on networks 
where STUN will just not work. So, I need to develop an implementation for 
using a relay. Our server is OpenFire, and it is currently configured to use 
rtpbridge. However, there is almost no documentation on how to use it. I'm 
writing client C++ code, and don't have the time to reverse-engineer the 
server's Java. So, at this point, I'm just kinda poking around for 
information and trying to test different things.

I was trying to figure out if, once I get the rtpbridge candidate, do I need 
to do any other magic with the port, or do I just start talking to it as a 
"regular" ice-udp connection? Also, I need to figure out how to translate 
the info given by rtpbridge into a ice-udp candidate to send to the other 
end... if that's possible at all... but I can't really know, because I can't 
find any documentation on what all of the attributes of the rtpbridge 
messages mean.

So, although I can't really find sufficient documentation, I'm guessing that 
this is how rtpbridge works:

* you request a candidate
* the server responds with a candidate ip & port, and gives you a password.
  - what do you do with that password? Is it only needed for the subsequent 
<relay/> message? If so, then people would be able to arbitrarily open ports 
on the relay... which is why I was asking if the actual relay server 
supported STUN messages, in which you could pass a username and magic cookie 
(and password?).
* the "other end" does the exact same sequence.
* both side connect to the rtpbridge candidates, and issue a <relay/> 
message to the server, to tell it to "connect" both relays together.

It would be nice to know whether I'm in the right ballpark, or if I'm 
completely out of my mind.

People really seem to be steering me away from rtpbridge, but unfortunately, 
it's not really my decision at this point.

Thanks,
Jeff