[Standards] Re: updated STUN discovery proposal
stpeter at jabber.org
Mon Apr 30 17:05:09 CDT 2007
V Unni wrote:
> Was going through stun-discovery proposal. Just wondering this concept
> can be extended as a service discovery than just stun discovery.
We've had some discussions along those lines recently in the jdev room.
It might be nice to query a server for services it knows about that meet
some criterion (e.g., based on disco#info identity).
> Justification :
> 1) The current stun bis differs from the RFC 3489. Considering this, In
> future more stun versions may exist or co-exists with stun relay or
> other p2p protocols.At a later point, if stun give way to some other
> protocol, we need to obsolete our extensions.
> 2) The IM is on its way to convergence, we require a generic service
> discovery mechanism which can fit the future needs of evolving services.
> 3) The below proposed changes allows publist / discovery of multiple
> services with single query ( ex: a jingle/voip session may need
> services of stun and relay discovery).
> 4) The below proposed changes on the stun discovery are simple and
> extend-able for the future needs.
> Changes :
> name : from stun-discovery to service-discovery
> The new payload format:
> <service xmlns='http://www.xmpp.org/extensions/xep-xxxx.html#ns'>
> <server servicename=stun host='stun1.shakespeare.lit'
> port='3478' proto=tcp/>
> <server servicename=stun host='stun2.shakespeare.lit'
> <server servicename=stun-relay host='turn.shakespeare.lit'
Presumably we'd need to have a registry of those servicenames, which may
or may not map to the existing registry of service discovery identities:
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070430/d327d619/smime.bin
More information about the Standards