W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

New spec: IceCandidate and IceCandidateCallback

From: Justin Uberti <juberti@google.com>
Date: Tue, 5 Jun 2012 17:33:23 -0400
Message-ID: <CAOJ7v-00a5q990i75fPhXNTG=iuC9W3DAiuG9yKOxUrVXViYtA@mail.gmail.com>
To: public-webrtc@w3.org
IceCandidate, as mentioned in the spec, doesn't include the necessary
information to allow it to be correlated with a m-line:
*"Open Issue: How to correlate. Need to wait for the mapping from media
tracks to SDP to be resolved in IETF before tackling this problem."*
But I'm not sure why we need a mapping from media tracks to SDP to figure
out which m-line a candidate needs to be associated with. Each m-line will
generate its own candidates (unless BUNDLEd, in which case all BUNDLEd
m-lines will share candidates), so specifying the needed info to make this
association in IceCandidate (m-line index and/or mid:) should be
straightforward. Am I missing something?

For ICE candidate gathering, how will the ICE Agent notify the application
that gathering is complete, and an offer or answer can now be sent (if not
using trickle candidates)? On the caller side, it looks like the app can
use the gathering->waiting iceState transition, but it's not clear when
this can be done on the callee side, since gathering and checking can occur
simultaneously. One option could be to to fire onicecandidate with a null
IceCandidate when gathering is complete.

Also, IceCandidateCallback is defined but not used.
Received on Tuesday, 5 June 2012 21:34:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC