W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Trickle ICE questions?

From: Emil Ivov <emcho@jitsi.org>
Date: Mon, 22 Jul 2013 13:48:39 +0200
Message-ID: <51ED1C17.8040607@jitsi.org>
To: Roman Shpount <roman@telurix.com>
CC: public-webrtc@w3.org

On 22.07.13, 12:59, Roman Shpount wrote:
> Hi Emil,
> Thank you for the response.
> On Mon, Jul 22, 2013 at 6:24 AM, Emil Ivov <emcho@jitsi.org
> <mailto:emcho@jitsi.org>> wrote:
>     On 22.07.13, 11:52, Roman Shpount wrote:
>         one intended for audio and another for video. When reflexive and
>         relayed
>         candidates are discovered, onicecandidate call back is called.
>         How do I
>         specify that reflexive candidate for one m-line should not be used?
>     I am a bit confused since you mention "enabling TURN" above but then
>     refer to "reflexive" candidates. Which of the following are you
>     trying to achieve?
> When you get a TURN allocation you typically get both back -- reflexive
> and relayed candidate.

Of course, but they still are different candidates.

>         In case of bundle, how do I specify that turn should be used for
>         one and
>         not the other?
>     With BUNDLE there is only "one". I am not sure what "the other"
>     would refer to here. It all goes down the same path. If you need to
>     avoid this then you'd have to drop BUNDLE.
> I can still have two media tracks being sent over single bundled
> connection. What I am trying to achieve is to enable video only if this
> connection does not go through a TURN server, ie force the connection to
> send and receive only audio if TURN server is required, send both audio
> and video when media flows direct. I guess this would require some
> non-trivial constraint or some sort of event which tells me which
> candidate is currently being used.

Sounds like the stats could be a way of obtaining this information. 
There seems to be a related ticket on webrtc.org about this:



Received on Monday, 22 July 2013 11:49:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC