[Standards-JIG] capabilities and media negotiations in Jingle

Joe Beda jbeda at google.com
Tue Apr 11 00:10:36 UTC 2006


Hi Weidong,

Some answers inline:

On 4/10/06, Weidong Shao <weidongshao at gmail.com> wrote:
>
> 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.
>

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.

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


More information about the Standards mailing list