[Standards] STUN discovery redux

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


>From :

http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-06

6.  STUN Message Structure - 3rd para
<snip>

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.
</snip>
I don't believe in making some stuff as a standard and change it in a very
short span of time.


thanx
unni


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).
>
> thanx
> unni
>
>
> 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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070510/f04cea21/attachment.html>


More information about the Standards mailing list