[Standards-JIG] capabilities and media negotiations in Jingle

Weidong Shao weidongshao at gmail.com
Mon Apr 10 23:29:45 UTC 2006


Hi,

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.

 - 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) ?

 - In JEP 0166, is there anyway to negotiate media-dependent transport?

 - 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?


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.


TIA,
Weidong




Weidong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060410/bdc324c1/attachment.html>


More information about the Standards mailing list