[Standards-JIG] capabilities and media negotiations in Jingle
jbeda at google.com
Tue Apr 11 00:10:36 UTC 2006
Some answers inline:
On 4/10/06, Weidong Shao <weidongshao at gmail.com> wrote:
> I read through JEP 0166, 0167 and have a few questions. I am new to XMPP
> and Jingle. Excuse me if the answers to my questions are obvious.
> - If two users want to have a session with audio as well as video, will
> Jingle treat these as two sessions and negotiate them independently? In some
> cases, p2p needs all-or-nothing session setup.
We've made some decisions but the spec hasn't been updated yet. We've
decided to allow more than one <description> element to be active at once.
This means that both audio and video can be negotiated in the same session.
- It seems that separate JEP proposals define audio and video (potentiallay
> data) media description. Is it ever considered to define a common one (
> loose on strong type) ?
We've discussed it but I don't think that any decisions have been made. In
light of the multiple <description> decision, I would think that we would
keep these seperate so we can version/update them independently.
- In JEP 0166, is there anyway to negotiate media-dependent transport?
No -- not right now. All channels/streams are implemented by one
transport. Do you have a scenario that requires this?
- In 0166, it is mentioned that an initiating entity may determine the
> target entity's resources through entity caps from presence etc. How is
> this generally handled for external client that is connected through a
> protocol gateway?
Because of the gateway issue I'm a fan of having all caps (wrt media
description types supported, etc.) be discovered as part of session
negotiation. Using disco to discover Jingle/166 support in general should
be okay but everything else shouldn't be locked down.
Some comments on JEP 176, 177. For security considerations, "In order to
> secure the end-to-end data stream, implementations SHOULD use native RTP
> encryption methods, such as ZRTP, or RTP Over DTLS, ". It may be a good
> idea to standardize the method, or at least say "MUST" support one common
> option. SRTP is very popular but key management is not specified. Personally
> I think that is the major flaw of SRTP (in the sense of promoting
> interoperable SRTP implementations).
> ZRTP introduces a new in-band key mangement for SRTP but key exchange is
> authenticated through SAS, which is not always possible. The other option
> with RTP over DTLS is that DTLS is good for client-server type of
> applications where server certificates are well-known. peer-to-peer DTLS
> requires a trust model for end-to-end authentication. Anyway, I suggest
> JEP mandates a common approach for end-to-end encryption to facilitate
> interoperable implementations.
I think the biggest hesitation here is that we don't have any
implementations for this stuff yet. If there was a deployed implementation
that worked it would be easier to make something a MUST.
I do agree that key management is the Achilles heal of all of this stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards