- From: Justin Uberti <juberti@google.com>
- Date: Tue, 5 Jun 2012 17:33:23 -0400
- To: public-webrtc@w3.org
- Message-ID: <CAOJ7v-00a5q990i75fPhXNTG=iuC9W3DAiuG9yKOxUrVXViYtA@mail.gmail.com>
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