[Standards-JIG] Jingle and ICE

Rob Taylor rob.taylor at collabora.co.uk
Fri Feb 10 22:54:14 UTC 2006

Scott Ludwig wrote:
> On 2/9/06, Philippe Kalaf <philippe.kalaf at collabora.co.uk> wrote:
>>   I have been working with libjingle and the jingle JEP recently and am
>>using it mostly for P2P connection establishement. I aim to provide ICE
>>compatibility while using libjingle. There are a couple of issues I
>>would like to discuss about the Jingle JEP that seem to be missing
>>compared to ICE, and would like to know if they are planned for future
>>1. There dosen't seem to be any concept of multiple components per
>>candidate in Jingle. This is usefull when wanting to have an RTCP
>>connection established along side the media streaming channel. Is this
>>planned or has it been omitted on purpose for some reason?
> Any number of p2p streams can be created per jingle session. It is up
> to the session type to create and use the streams as it sees fit.
> Typically a session type will describe its needs and requirements in
> its session description.

But how to you then tell that a single media stream is actually made up
of a number of p2p streams? e.g. if you have a video stream with RTCP
and an audio stream with RTCP.
In SDP, this is given to you as a candidate is made out of a number of
components, and then you can have multiple streams with their own

>>3. What about peer-derived candidates?
> These are accumulated automatically and added to the permutation
> table. If a valid stun binding response is received with the correct
> username but the address has not been seen before, it is added to the
> connection permutation table.

Hmm, how do you do a peer-candidate transaction equivalent to that on
P66 of draft-ietf-mmusic-ice-06, where you need to give the remote
candidate id that that peer-derived-candidate matches to in order to
avoid a race condition?

Rob Taylor

More information about the Standards mailing list