[Jingle] rtpbridge

[Jeff Muller]

Does anybody have any better description on how to use rptbridge service
(from the client side) than can be found at
http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy ?

In addition to documentation of the semantics of attributes like "sid", it
would also be nice to know what "portb" in the <candidate/> tag is for.
Also, it's not exactly clear how to use the <relay/> request. what are
"hosta", "hostb", "porta", and "portb"?

Finally, how does this exactly fit into the jingle <candidate/> messages?

Any help or pointers would be appreciated.

Thanks,
Jeff

[Peter Saint-Andre]

Jeff Muller wrote:
> Does anybody have any better description on how to use rptbridge service
> (from the client side) than can be found at
> http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy ?
>
> In addition to documentation of the semantics of attributes like "sid",
> it would also be nice to know what "portb" in the <candidate/> tag is
> for. Also, it's not exactly clear how to use the <relay/> request. what
> are "hosta", "hostb", "porta", and "portb"?
>
> Finally, how does this exactly fit into the jingle <candidate/> messages?
>
> Any help or pointers would be appreciated.

IIRC, this rtpbridge was a non-standard, XMPP-aware NAT traversal and
media relaying solution developed by the folks at Jive to get around the
need for deploying STUN and TURN servers and then using ICE during the
transport negotiation (since the Jive developers thought that support
for STUN, TURN, and ICE would not be commonly available anytime soon).
In Jingle itself we decided not to go down that road, since we'd prefer
to use existing standards for NAT traversal and media relays.

/psa

[Jeff Muller]

Peter,

Aside from finding out what your relay server addresses are, don't you still
need a way to actually get an ip and ports to use as specific media relay
ports? Sorry if this is well-known stuff, but I've had a hard time finding
pointers to all of the right info I need. Googling for "media relay", "srv
records", "stun", etc., yields lots of result, and lots of standards
documents, and there's only so much time in the day (and one of me, for this
particular aspect of the effort). So, any quickie pointers would be greatly
appreciated.

and to broaden the topic a little...

I know I can do SRV lookups for xmpp and stun services, but I couldn't
clearly find if there's a lookup for jingle media relays (_one_ of the
reasons for using jingleinfo and/or rtpbridge). Also, is rtpbridge just a
"transaction" layer that really just relies on the existence of a separate
"standard" media relay server? If so, where is the media relay server
standard defined? Is that what a STUN ALLOCATE request is? Again, sorry if
I'm being dense, it's just not clear enough to me since I'm trying to learn
as I code (or more accurately, learn in-between coding and debugging).

Thanks again,
Jeff


"Peter Saint-Andre" <stpeter (AT) stpeter (DOT) im> wrote
in message news:4925F22F.20303 (AT) stpeter (DOT) im...
> Jeff Muller wrote:
>> Does anybody have any better description on how to use rptbridge service
>> (from the client side) than can be found at
>> http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy ?
>>
>> In addition to documentation of the semantics of attributes like "sid",
>> it would also be nice to know what "portb" in the <candidate/> tag is
>> for. Also, it's not exactly clear how to use the <relay/> request. what
>> are "hosta", "hostb", "porta", and "portb"?
>>
>> Finally, how does this exactly fit into the jingle <candidate/> messages?
>>
>> Any help or pointers would be appreciated.
>
> IIRC, this rtpbridge was a non-standard, XMPP-aware NAT traversal and
> media relaying solution developed by the folks at Jive to get around the
> need for deploying STUN and TURN servers and then using ICE during the
> transport negotiation (since the Jive developers thought that support
> for STUN, TURN, and ICE would not be commonly available anytime soon).
> In Jingle itself we decided not to go down that road, since we'd prefer
> to use existing standards for NAT traversal and media relays.
>
> /psa
>
>
>
>

[Jeff Muller]

Sorry for the previous top-postings (old habits don't die). I continue
below...

>> Jeff Muller wrote:
>>> Does anybody have any better description on how to use rptbridge service
>>> (from the client side) than can be found at
>>> http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy ?
>>>
>>> In addition to documentation of the semantics of attributes like "sid",
>>> it would also be nice to know what "portb" in the <candidate/> tag is
>>> for. Also, it's not exactly clear how to use the <relay/> request. what
>>> are "hosta", "hostb", "porta", and "portb"?
>>>
>>> Finally, how does this exactly fit into the jingle <candidate/>
>>> messages?
>>>
>>> Any help or pointers would be appreciated.
>>
>> IIRC, this rtpbridge was a non-standard, XMPP-aware NAT traversal and
>> media relaying solution developed by the folks at Jive to get around the
>> need for deploying STUN and TURN servers and then using ICE during the
>> transport negotiation (since the Jive developers thought that support
>> for STUN, TURN, and ICE would not be commonly available anytime soon).
>> In Jingle itself we decided not to go down that road, since we'd prefer
>> to use existing standards for NAT traversal and media relays.
>>
>> /psa
>>
>>
>>
>>

"Jeff Muller" <xmpp (AT) mullercentral (DOT) com> wrote
in message news:gg77k7$e8o$1 (AT) ger (DOT) gmane.org...
> Peter,
>
> Aside from finding out what your relay server addresses are, don't you
> still need a way to actually get an ip and ports to use as specific media
> relay ports? Sorry if this is well-known stuff, but I've had a hard time
> finding pointers to all of the right info I need. Googling for "media
> relay", "srv records", "stun", etc., yields lots of result, and lots of
> standards documents, and there's only so much time in the day (and one of
> me, for this particular aspect of the effort). So, any quickie pointers
> would be greatly appreciated.
>
> and to broaden the topic a little...
>
> I know I can do SRV lookups for xmpp and stun services, but I couldn't
> clearly find if there's a lookup for jingle media relays (_one_ of the
> reasons for using jingleinfo and/or rtpbridge). Also, is rtpbridge just a
> "transaction" layer that really just relies on the existence of a separate
> "standard" media relay server? If so, where is the media relay server
> standard defined? Is that what a STUN ALLOCATE request is? Again, sorry if
> I'm being dense, it's just not clear enough to me since I'm trying to
> learn as I code (or more accurately, learn in-between coding and
> debugging).
>
> Thanks again,
> Jeff
>
>
> "Peter Saint-Andre" <stpeter (AT) stpeter (DOT) im>
> wrote in message
> news:4925F22F.20303 (AT) stpeter (DOT) im...

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 Williams]

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
>
>
>
>
>

[Olivier Crête]

On Mon, 2008-11-24 at 10:14 -0800, Jeff Williams wrote:
> STUN == P-to-P socket *discovery*
> RTPBridge == P-S-P bridged socket *connections*

In the standard world, there is TURN, which is a standard to relay
connections.

--
Olivier Crête
olivier.crete (AT) collabora (DOT) co.uk
Collabora Ltd

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkq9BIACgkQHTiOWk7ZorsVaQCfYLUikfQhpU y2yIHOZFePT+Ps
oZUAnioMnR1hcPCiGh9m5AopQoJIv8K2
=YsiB
-----END PGP SIGNATURE-----

[Jeff Muller]

"Jeff Williams" <jeffw (AT) gadgetworks (DOT) com> wrote in
message news:90D1B307-A8A3-4FC3-84F8-970EE125B94C (AT) gadgetworks (DOT) 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

[Jeff Williams]

http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy

El Nov 24, 2008, a las 11:27 , Jeff Muller escribió:

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

[Jeff Muller]

"Jeff Williams" <jeffw (AT) gadgetworks (DOT) com> wrote in
message news:5A99C100-B7A1-48BD-A055-7E1C9F8D3ECA (AT) gadgetworks (DOT) com...
http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy

El Nov 24, 2008, a las 11:27 , Jeff Muller escribió:

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

Sorry, but nothing on that page addresses any of my questions from my
original post (which referenced that very web page), nor any of the
subsequent questions.

[Unnikrishnan V]

Added by Matt Tucker <http://wiki.igniterealtime.org/display/~matt>, last
edited by Thiago Rocha
Camargo<http://wiki.igniterealtime.org/display/~thiago>on Nov 25, 2008
??


you can contact them :-)

thanx
unni


On Tue, Nov 25, 2008 at 7:57 PM, Jeff Muller <xmpp (AT) mullercentral (DOT) com> wrote:

> "Jeff Williams" <jeffw (AT) gadgetworks (DOT) com> wrote in message
> news:5A99C100-B7A1-48BD-A055-7E1C9F8D3ECA (AT) gadgetworks (DOT) com...
> http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy
>
> El Nov 24, 2008, a las 11:27 , Jeff Muller escribió:
>
>
>>> So, although I can't really find sufficient documentation, I'm guessing
>> that this is how rtpbridge works:
>>
>>
> Sorry, but nothing on that page addresses any of my questions from my
> original post (which referenced that very web page), nor any of the
> subsequent questions.
>
>
>

[Peter Saint-Andre]

Jeff Muller wrote:

> I was told to email Thiago because he may have more info about
> rtpbridge, but he has not responded. Thiago, are you around?

The last I heard, he was doing some work for Nimbuzz:

http://www.jivesoftware.com/jivespace/people/thiagoc

Unfortunately he's not on this list. I've cc'd him and invited him to
join the list.

/psa

[Peter Saint-Andre]

Jeff Williams wrote:
> 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.)

Right. As I understand it, rtpbridge was a stop-gap because the Openfire
folks didn't want to wait for TURN.

/psa