[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLSsubmitted.Ready for WGLC?
Jonathan Lennox wrote:
I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF.
TCP/TLS/RTP/AVP, yes. I'm not sure what the use-case is for
TCP/TLS/RTP/AVPF -- I thought most of the motivation for AVPF was for
bandwidth adaptation and improved delivery reliablity, both of which seem to
be redundant for something transmitted over TCP.
There are definitely motivation why also AVPF should be included. First
of all AVPF provides a generic mechanism that can be used for sending
feedback messages. In certain cases these feedback messages have nothing
to do with either delivery reliability or bandwidth adaptation. This
will definitely become evident when the new draft
(draft-wenger-avt-avpf-ccm-00.txt) on codec commands becomes available.
This draft contains feedback that are related to usage of video mixers
(MCUs) as an example.
The other motivation are these use cases that contains mixers or media
focus performing replication to form a multiparty conference. There
several independent unicast connection are connected. In these scenario
it is not unlikely that some could use TCP/TLS while others uses UDP.
Thus the need to have the same profile but with different transports.
I would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would
consider TCP/TLS/RTP/SAVP a possibility in cases that requires a secure
TCP/TLS connection, for example due to end point authentication, which
however is a gateway to an SRTP session. If that is relevant or not is
another matter.
I'm dubious about sending Secure RTP over TLS -- I think it would need to be
pretty strongly motivated with real use-cases.
Again I think the motivation are gateways or other type of bridging
between different transport formats while still there is a need to use
the same profile in both transport domains.
However it might be that for this use case TCP/RTP/SAVP is more useful.
Including TLS would only provide end-point authentication.
For both these cases, their motivations are significantly stronger if you're
envisioning implementing a UDP<->TCP<->UDP tunnel scenario. Is that what
you're thinking of?
Yes, but primarily the case of mixer translators between a UDP domain
and some users connected using TCP.
As I see it TCP/RTP/SAVP and TCP/TLS/RTP/AVP have somewhat different
security properties. TLS provides a secured transport channel with
possibility to end-point authentication. The SRTP based solution
provides instead group security and can be done without a trusted
gateway. So they definitely are applicable in different use cases.
I'm not sure what you mean by a "trusted gateway", and I'm not sure how
useful group security is for a point-to-point connection-oriented protocol,
again unless you're envisioning tunneling.
IF you are having a UDP multicast session and you like to connect but
can only use TCP then you need a translator. That translator will be
required to be trusted if it is going to perform the following operation:
IP/UDP/RTP/SAVP -> IP/TCP/TLS/AVP
In addition to be trusted to receive, decrypt and handle the media it
must also be trusted to correctly authenticate the end-point connecting
over TLS.
If you instead performed a TCP encapsulation operation the translator
could be untrusted.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt