[Standards] STUN discovery redux
ukv1977 at gmail.com
Thu May 10 23:11:30 UTC 2007
missed this in my previous mail : justification for addition of protocol
also in the forms/ fields
6. STUN Message Structure - 3rd para
STUN Requests are sent reliably. STUN can run over UDP, TCP or TCP/
TLS. When run over UDP, STUN requests are retransmitted in order to
achieve reliability. The transaction ID is used to correlate
requests and responses
if not protocol not present , legacy stun. so this support RFC 3489 and new
changes comming with the bis.
I don't believe in making some stuff as a standard and change it in a very
short span of time.
On 5/10/07, Unnikrishnan V <ukv1977 at gmail.com> wrote:
> http://www.xmpp.org/extensions/xep-0055.html also can be used. I beleive
> we are just one step to reach the goal.
> Reason :
> The proposed ways :
> 1) Simple IQ
> 2) pubsub
> 3) disco
> 4) browse
> 5) search
> Now we need to look on the over heads each method has ( on code + network
> ) and a usecases justification.
> The usecase of this stun discovery is I believe (please correct me, if i
> am wrong ) : Certain networks the DNS SRV fails and we were doing a
> fallback case for DNS SRV. The problem appeared while executing stun. But
> we are not sure in that cases stun can complete the call.Reason : Stun
> wont help to have call working behind symmetric firewall or a restricted
> enterprise network.
> I rather vote for disco / search approach because result is going to be
> mostly only 2 servers entries ( primary and secondary ) . If more that 2
> server entries present, the xmpp servers do load balancing ( by using the
> weight field on the server - as a feature and choose the best 2 entries for
> the requesting node).
> On 5/10/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
> > OK, we need to get this STUN discovery stuff figured out.
> > The original proposal was to use IQs, basically what Google does with
> > their jingleinfo namespace.
> > Then Chris Mullins suggested that we use pubsub. We pursued that for a
> > while but it turns out that the credentials you need at a STUN server
> > are individualized (cf. rfc3489bis), so the XMPP server can't provide
> > the same credentials to all users via a pubsub notification.
> > Then we looked at generalizing things to define a service request
> > protocol that can be used to query your XMPP server for any service it
> > might know about that matches a certain kind of disco identity. While
> > that's interesting, I think it's a bit early to look beyond the STUN
> > case to a generalized mechanism.
> > So I'm going to return to IQs in the next version of the proposal, but
> > add in the credential stuff.
> > Peter
> > --
> > Peter Saint-Andre
> > XMPP Standards Foundation
> > http://www.xmpp.org/xsf/people/stpeter.shtml
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards