[Standards-JIG] Jingle: tracking stanzas
jbeda at google.com
Tue Feb 14 19:22:33 UTC 2006
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
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
* 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.
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 Saint-Andre
> Jabber Software Foundation
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards