[Jingle] rtpbridge

[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.im> wrote 
in message news:4925F22F.20303 at stpeter.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
>
>
>
>