[Standards-JIG] Jingle: tracking stanzas

Joe Beda jbeda at google.com
Tue Feb 14 20:29:34 UTC 2006


One of the advantages of the technique that I described is that the
server/proxy isn't required to keep a table of every outstanding IQ.  I
think that was one of the concerns that motivated this discussion in the
first place.

Joe

On 2/14/06, Simon Guindon <simon.guindon at tomahawk.ca> wrote:
>
> Yup I agree.
>
> XMPP already has tracking via IQ ID's so really the gateway just has to
> store and keep track etc. I like the way you suggest they store, but really
> they can store it various ways internally in the gateway however they please
> as long as they give the original ID back in the IQ responses.
>
> Take care,
> Simon
>
> -------------------------------------------------------
> *Simon Guindon*
> *Tomahawk Technologies Inc.*
> simon.guindon at tomahawk.ca
> www.tomahawk.ca<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.tomahawk.ca>
>  -------------------------------------------------------
>
>
>  ------------------------------
> *From:* standards-jig-bounces at jabber.org [mailto:
> standards-jig-bounces at jabber.org] *On Behalf Of *Joe Beda
> *Sent:* Tuesday, February 14, 2006 2:23 PM
> *To:* Jabber protocol discussion list
> *Subject:* Re: [Standards-JIG] Jingle: tracking stanzas
>
> My suggestion is that any server JID/endpoint that is proxying stanzas can
> rewirte the id to encode enough information to forward to the correct
> connect/session.
>
> So -- if we have A->S->B:
> * S has a map of 'connection id'->connection/session.  Each incoming
> connection gets assigned an id as it connects
> * A sends a stanza with id='AAA'
> * S rewrites that id as '123:AAA' where 123 is the connection ID and
> forwards the stanza to B
> * B responds with an error or result to S
> * S decodes the id and gets both the connection index and the original
> stanza id
> * S rewrites the id on the response back to 'AAA' and forwards it on to A.
>
> Depending on how and where you are using this there may be security
> concerns.  S may want to verify that the response is coming from an expected
> JID by perhaps keeping a map of communication pairs (so 123->(A,B)).  S may
> also want to use a cryptographically secure random number generator to
> assign the IDs to further prevent spoofing (so that X can't send a message
> to A through S).
>
> Because this technique is easy enough to implement, I really don't think
> that we need to require the jingle stanza in responses/errors.
>
> Joe
>
> On 2/14/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > In XMPP, you track packets based on the 'id' attribute. However, those
> > are generated by a client. If an intermediary (such as Asterisk) wants
> > to keep track of all the Jingle traffic flowing around, it may want
> > something more advanced. Many Jingle-related stanzas include a <jingle/>
> > child element with a session ID ('sid') attribute. However, that does
> > not normally apply to IQ-results and IQ-errors because RFC 3920 says
> > it's optional to include the original child element(s) when sending IQ
> > stanzas of type "result" and "error". While it might be nice for
> > intermediaries to have that 'sid' on each and every stanza, it would get
> >
> > quite verbose. I think we probably have the 'sid' on the packets that
> > matter, but discussion is welcome from implementors on the topic.
> >
> > Peter
> >
> > - --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.shtml<http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.jabber.org%2Fpeople%2Fstpeter.shtml>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org<http://www.google.com/url?sa=D&q=http%3A%2F%2Fenigmail.mozdev.org>
> >
> > iD8DBQFD8iuRNF1RSzyt3NURAhE1AJwJVzA4ZDjM/AgIbw6wyhjBVxbO3ACg2lHR
> > CTmum6X1NMqXcdXTlNtaW2U=
> > =z0dL
> > -----END PGP SIGNATURE-----
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060214/e5263ce3/attachment.html>


More information about the Standards mailing list