- From: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>
- Date: Wed, 15 Jan 2014 12:29:30 +0000
- To: Justin Uberti <juberti@google.com>
- Cc: Alexandre GOUAILLARD <agouaillard@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, jib@mozilla.com
Thanks, that clears up my understanding. I think a bit of extra detail in section 4.2.2 could make this clearer, particularly the description of the "urls" property. Regards, Gavin -- Principal Design Engineer Crocodile RCS Ltd GPG key: 0xF8F6FFF2 On 15 January 2014 06:22, Justin Uberti <juberti@google.com> wrote: > Note that that isn't exactly right, since the AppRTC code was written to > deal with browsers that didn't support an array of URLs. > > The correct usage here (assuming an up-to-date browser) is > "iceServers": [ { > "urls":"stun:stun.l.google.com:19302" > }, { > "credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=", > "username":"75763028:1389749771", > "urls":[ > "turn:23.251.128.79:3478?transport=udp", > "turn:23.251.128.79:3478?transport=tcp", > "turn:23.251.128.79:3479?transport=udp", > "turn:23.251.128.79:3479?transport=tcp" > ] > } ] > > > On Tue, Jan 14, 2014 at 5:41 PM, Alexandre GOUAILLARD > <agouaillard@gmail.com> wrote: >> >> @gavin, >> >> Illustration using today's appRTC if this helps, you can see multiple >> entry in the IceServer list of the same TURN server with identical >> credential, but different transport protocols >> >> "iceServers": >> [ >> {"url":"stun:stun.l.google.com:19302"}, >> >> {"url":"turn:23.251.128.79:3478?transport=udp","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"}, >> >> {"url":"turn:23.251.128.79:3478?transport=tcp","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"},{"url":"turn:23.251.128.79:3479?transport=udp","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"},{"url":"turn:23.251.128.79:3479?transport=tcp","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"} >> ] >> >> >> >> On Wed, Jan 15, 2014 at 3:25 AM, Justin Uberti <juberti@google.com> wrote: >>> >>> The intent was that distinct servers would have distinct RTCIceServer >>> entries. >>> >>> The multiple URLs should be used when a single server has multiple ways >>> of being reached (e.g. multiple transport protocols), but the same >>> credentials should be used for each transport protocol. >>> >>> >>> On Fri, Jan 10, 2014 at 8:03 AM, Gavin Llewellyn >>> <gavin.llewellyn@crocodilertc.net> wrote: >>>> >>>> On a related note, I see the RTCIceServer dictionary has been updated >>>> to accept multiple URLs. Is this just for convenience when you have >>>> multiple TURN servers that accept the same credentials? I'm left >>>> slightly confused as to whether I should be providing multiple >>>> RTCIceServer dictionaries in my RTCConfiguration, or a single one with >>>> multiple URLs - this does not seem to be explained in the current >>>> text. I think the confusion stems from the name of the dictionary; it >>>> suggests that multiple URLs should refer to the same server. >>>> >>>> If it is just for convenience, what about if I am using a TURN server >>>> and a STUN server (in case the TURN server is unavailable)? The >>>> current example puts them in separate dictionaries, but then the >>>> current example does not demonstrate providing multiple URLs. Can >>>> they be specified in a single RTCIceServer dictionary for simplicity >>>> (assuming the credentials will be ignored when contacting the STUN >>>> server)? >>>> >>>> Regards, >>>> Gavin >>>> >>>> -- >>>> Principal Design Engineer >>>> Crocodile RCS Ltd >>>> GPG key: 0xF8F6FFF2 >>>> >>>> >>>> On 8 January 2014 19:38, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >>>> > On 1/6/14 4:55 PM, Harald Alvestrand wrote: >>>> > >>>> > On 01/06/2014 05:06 PM, Eric Rescorla wrote: >>>> > >>>> > >>>> > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcconfiguration-members >>>> > has: >>>> > >>>> > dictionary RTCIceServer { >>>> > (DOMString or sequence<DOMString>) urls; >>>> > DOMString? username = null; >>>> > DOMString? credential; >>>> > }; >>>> > >>>> > AFAICT, username isn't really optional for TURN servers (RFC 5766 >>>> > says): >>>> > >>>> > [RFC5389] specifies an authentication mechanism called the >>>> > long-term >>>> > credential mechanism. TURN servers and clients MUST implement >>>> > this >>>> > mechanism. The server MUST demand that all requests from the >>>> > client >>>> > be authenticated using this mechanism, or that a equally strong or >>>> > stronger mechanism for client authentication is used. >>>> > >>>> > (and username and credential should have the same status in any case). >>>> > >>>> > I suspect we either need two classes (one for TURN and one for STUN) >>>> > or explanatory text saying that you need to provide this for TURN. >>>> > >>>> > >>>> > Explanatory text seems like the right path to me. Since it contains >>>> > URLs, >>>> > the syntax doesn't constrain it to be TURN or STUN, and the quoted >>>> > text does >>>> > seem to make it possible that there will be other ways to do this >>>> > authentication. >>>> > >>>> > >>>> > +1. A separate class wouldn't do any good because dictionary members >>>> > are >>>> > inherently optional. >>>> > >>>> > I think the prose should say UAs MUST check and throw for TURN. >>>> > >>>> > While we're looking at this... >>>> > >>>> > Having username and credential be nullable (i.e. explicitly supporting >>>> > the >>>> > passing-in of the value null) seems unnecessary and a mistake. Is it >>>> > too >>>> > late to tighten this up as follows? >>>> > >>>> > dictionary RTCIceServer { >>>> > (DOMString or sequence<DOMString>) urls; >>>> > DOMString username; >>>> > DOMString credential; >>>> > }; >>>> > >>>> > If that looks wrong, consider it really being like this: >>>> > >>>> > dictionary RTCIceServer { >>>> > optional (DOMString or sequence<DOMString>) urls; >>>> > optional DOMString username; >>>> > optional DOMString credential; >>>> > }; >>>> > >>>> > >>>> > Which is what it essentially is (optional is inherent in dictionary >>>> > members). >>>> > >>>> > A common confusion in webidl is between: >>>> > >>>> > Optional (the keyword 'optional' or anything in a dictionary): The >>>> > ability >>>> > to omit. >>>> > Nullable (the '?' operator): Adds null to the values acceptable to >>>> > pass in >>>> > or hold. >>>> > Default (the '=' operator, valid only with optional): in practice >>>> > removes >>>> > implementer burden/ability to check whether something was passed in. >>>> > >>>> > .: Jan-Ivar :. >>>> > >>>> >>>> >>> >> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> >
Received on Wednesday, 15 January 2014 12:29:59 UTC