Peter Saint-Andre wrote:
Ian Paterson wrote:
Note that this separation of layers enables the protocols to be used
independently, however, the fact that the two negotiations are carried
out simultaneously creates latency in the establishment of a call
(something that AFAICT is an issue in the "Real World").
Wouldn't they be carried out serially, not in parallel?
Yes, sorry I meant "are *not* carried out simultaneously".
Perhaps a couple of round trips could be saved by *optionally* including
the first <jingle/> negotiation elements in the <message/> stanzas used
for the Encrypted Session negotiation (instead of in subsequent <iq/>
stanzas)?
Hmm. This gets back to the old thread about message vs. IQ for Jingle
negotiation, forking to multiple resources, etc.
Well, we could stipulate that Jingle could only be included with e2e
negotiation if the <message/> is addressed to a specific resource.
But in general it doesn't seem like a good idea to mix the protocols in
that way. How does the recipient know to look for the Jingle invite in
the middle of an encrypted sessions negotiation?
I agree that this is not a good idea. However, keeping Jingle and e2e in
series only increases latency. We're probably going to have to solve the
latency issue at some stage. Does anyone have a good (or at least
better) idea how we can do that?
AFAICT, nothing currently stops a client conducting both negotiations at
the same time in order to minimise latency. So you might even want to
discourage that in the Jingle XEP.
Also I don't think we want to tie Jingle and ESessions together. What if
we design some other way to do e2e encryption (e.g., "XTLS")? Do we then
need to define how that works with Jingle too?
I agree we need to allow for different methods of e2e, especially at
this early stage.
Proper layering seems important here.
Yes.
- Ian
