- From: Emil Ivov <emcho@jitsi.org>
- Date: Mon, 22 Jul 2013 12:24:22 +0200
- To: Roman Shpount <roman@telurix.com>
- CC: public-webrtc@w3.org
Hey Roman, On 22.07.13, 11:52, Roman Shpount wrote: > I apologize if these were already covered in one of the drafts, but I > could not find the answer to those questions. > > Imagine the following situation, that I want to enable TURN use for > audio but not for video. Let's first assume the case without bundle. ICE > agent creates two m-lines with initial (I assume local) candidate sets Could also be :: in case you don't want to reveal host candidates (more below). > 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? a) enable TURN only for one "m=" line but disable it for every other "m=" line. That is: only the audio "m=" line would be able to ever use TURN but will only do so if necessary b) force use of TURN for one "m=" line and let ICE choose any candidate, including relayed ones, for the other "m=" lines. > Keep > in mind that simply not sending it to the remote party is no enough > since if the connectivity check will be delivered to remote party > through this reflexive candidate it will be added to the candidate set. Achieving "a" reliably would only be possible if the API allows it, for the reason you mention. Achieving "b" is possible if you control both endpoints and they both only advertise relayed candidates for the "m=" line where you want to force use of TURN. > Should we have something similar to setLocalDescription for each trickle > ICE candidate set? > > 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. > While we are at it, how can I find out if media flows > through the relayed candidate and how would I know when this changes? > > Another question, in case of trickle ICE and constraint being set to use > only relayed candidates, should offer or answer generation be delayed > until at least one relayed candidate is discovered for each m-line No, this is not necessary. > or > should SDP with no candidates for an m-line be generated? If it is the > later, what would this look like? Currently the idea is that you would use the "::" address and port 9 as a default candidate http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-01#section-5.1 (Previously this was 0.0.0.0 so some implementations may do this). Cheers, Emil -- https://jitsi.org
Received on Monday, 22 July 2013 10:24:53 UTC