[Standards-JIG] Jingle and ICE
scottlu at google.com
Thu Feb 9 21:23:06 UTC 2006
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.
> 2. There dosen't seem to be any exchange of currently "active
> candidates" for a connection. Libjingle determines the best possible
> candidate and simply uses it without alerting the other side about it.
> ICE on the other hand requires that you send the active/prefered
> candidates in the m/c line.
There is no technical need for exchanging active candidates, because
the connection is actively pinged with STUN binding requests /
responses during media transmission. This active ping lets both sides
know which connections are active.
It has been mentioned that signaling "active candidates" would be
useful for logging purposes. It hasn't been added to the JEP yet.
> 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.
> Philippe Kalaf
> Collabora Ltd.
More information about the Standards