useless ICE trickle feature in SDK.

[xelven]

as the commit #45
did any one using this send each candidate to other peer right now?

this looks all fine, but when u really using this separate the candidate n media info, you will realize for the audio MAY works, but for the video will NOT working at all.
when there are 2 stream we send the candidate 1 by 1, we didnt know which is audio or video!
and take look into the code index = [remoteCandidate[@"sdpMLineIndex"] intValue];

when added wrong info will take slow pair for candidate and failed!

and one more question for #50
did any one tell me what is a=ice-options:trickle that mean, I didn't found it in rfc5245.

[mxgross]

Hey "sdpMLineIndex" seems to specify if it is a candidate for audio or video stream.
My candidates on the web client look like that:

`if (evt.candidate != undefined && evt.candidate.candidate != undefined) {

            var candidate = "";
            var s = SDP.parse("m=application 0 NONE\r\na=" + evt.candidate.candidate + "\r\n");
            var candidateDescription = s && s.mediaDescriptions[0].ice.candidates[0];
            if (!candidateDescription) {
                candidate = evt.candidate.candidate;
            }

            var metaData = JSON.stringify(
                {
                    "candidate": {
                        "candidate": candidate,
                        "candidateDescription": candidateDescription,
                        "sdpMLineIndex": evt.candidate.sdpMLineIndex
                    }
                }
            );

            // save for debug history
            MYAPP.candidatesHistorySelf.push(metaData);
            hasValidCandidate = true;
        }
    }`

and on the app I do:

candidate = [candidate[@"candidate"] mutableCopy]; index = [candidate[@"sdpMLineIndex"] intValue];

to get the right index.

[xelven]

of course "sdpMLineIndex" is index audio or video stream, otherwise I won't remind in this topic.
Because in current design the ICE trickle way is useless.
I has been fixed the index and doing cache stuff in my local, and removed the candidate in offer and answer.
But still slow because there designed when generated all candidates done then send offer or answer.
And also the libnice discovery STUN/TURN candidate are slow too.

[mxgross]

So you are caching your candidates? We once tried to cache the candidates too, but it did not work. Now we have it working with ICE Trickle on web client but no trickle on iOS. So in iOS all candidates are sent inside the offer/answer and on web we send each candidate as soon as it is created. Now we have stable connections from web2web web2app app2app and app2web. Even without trickle on the iOS client the connection is established really fast (beneath 2 seconds)

[xelven]

Yeah, when u cache the candidate from handle remote candidate receive if u process before offer or answer, that won't work because NO auth info in candidate.

And also the connection speed depends on your network STUN/TURN (the most time I won't set just 1 services) services and network NAT type.
I not sure which version of OWR you using. I also fast in same Wifi using host to host connection. But when using mobile network got more problems, for example though NAT etc..
Check it out the ref issue on this topic,
Until now after I modified a lot of in libnice and own TURN/STUN services, it goes fast from discovery candidate to pair then got stream.