xmpp at mullercentral.com
Fri Nov 21 15:01:55 CST 2008
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
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).
"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.
More information about the Jingle