Am 11.04.20 um 20:35 schrieb Holger Weiß:
* Philipp Hancke <fi...@goodadvice.pages.de> [2020-04-11 20:24]:
Am 11.04.20 um 20:01 schrieb Holger Weiß:
1. The "type" attribute specifies the "service type as registered with
the XMPP Registrar". As far as I can see, no types are registered so
far; and at least to me, it's not completely obvious how (STUN and)
TURN over TLS services should be specified. I see two ways:
<service type='turns' protocol='tcp' [...]/>
<service type='turn' protocol='tls' [...]/>
Personally I'd opt for the first one (to be consistent with e.g.
<https://tools.ietf.org/html/rfc5389#section-9>), but I don't care
much. Either way, I guess this should be clearly defined.
TURN/TLS uris are of the form
turns:host:port?transport=tcp
and this is mapping to
https://tools.ietf.org/html/rfc7064
https://tools.ietf.org/html/rfc7065
so type => scheme, protocol to transport
Makes sense, thanks.
2. The XEP allows clients to either request the list of <services/>
(optionally limited by the desired service "type"), or to request
<credentials/> (limited by the desired "host", "type", and optionally
"port"; but not e.g. by the "protocol"). As credentials can be
included with the <services/> response, I don't quite see the point
of having a seperate <credentials/> request. Wouldn't it make more
sense to allow the client to specify arbitrary <service/> attributes
(except maybe "username" and "password") with the <services/> request
for filtering the response, e.g.
<services type='turn' protocol='udp'/>
and then drop the <credentials/> thing?
I think that was intended for the XMPP variant of
https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00
but I don't think that variant was ever implemented.
I might be misunderstanding, but isn't Prosody's mod_turncredentials
(which you wrote initially, I think) doing just that?
Yes. However it usually doesn't cover the case where new credentials
need to be pushed (which is why we have example 5).
From what I recall this kind of querying was added to support a case
where you needed the same server but new credentials to handle refreshes
of an allocation. This never turned out to be relevant and wasn't
possible to implement in webrtc until quite recently.
Either way I'm not sure how that relates to my point? Which was mainly
about the request syntax being redunant (plus semantics being limited in
that the client can't filter by arbitrary attributes).
I agree with that one :-)
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
