Re: ICE candidate search freezing and reuse of usernameFrag/password for components

That's what I've been talking about throughout that the local candidates 
are not changeable. However, there's a side effect. The RTP/RTCP often 
are required to share the same ufrag:password locally. The only way to 
get that to happen is to copy the credentials from an existing 
RtcIceListener object into a new RtcIceListener object since the web 
developer isn't allowed to set them directly. Now maybe you understand 
the context of where I was coming from...

-Robin


> Emil Ivov <mailto:emcho@jitsi.org>
> April 13, 2014 at 3:56 PM
>
> Hey Robin,
>
> On 13 Apr 2014 9:48 PM, "Robin Raymond" <robin@hookflash.com 
> <mailto:robin@hookflash.com>> wrote:
> >
> >
> > Hi Emil,
> >
> > I think I understand the fundamental confusion point.
>
> I think I do too. We might have been referring to different sets of 
> credentials.
>
> > ICE is used for consent and consent freshness. [BA] confirmed that it
> > was not changed to Dtls. I think we both agree on this point.
>
> Yes.
>
> > However, it's my understanding that the browser generates the local
> > ufrag:password and it's NOT changeable once created by the browser
>
> Yes, of course. The local aren't. In order for ICE to work however and 
> for ICE restarts to be possible, an application has to be able to set 
> new *remote* credentials.
>
> There is absolutely no need for an application (be it web or rich) to 
> exert control on the local credentials, other than requesting new ones.
>
> Emil
>
> --sent from my mobile
>