Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01

["Parthasarathi R" <[e-mail]>]

Hi Harald/Magnus,

I agree with you that we need to reference the correct transport in
draft-ietf-rtcweb-transports. I noticed that RTP over TCP
(http://www.ietf.org/mail-archive/web/pntaw/current/msg00041.html)
discussion is going on in ptnaw mailing alias. As there is a possibility of
two different stack for RTCWeb and it is an open item, let us discuss and
conclude in ptnaw mailing alias before updating in RTCWeb transport.
 
Also I agree with Magnus that it is better to discuss in MMUSIC for SDP
field proto cleanup for TCP/RTP/SAVPF, TCP/RTP/SAVP, TCP/RTP/AVPF. I'll
start the mail thread in Mmusic after seeing the interest in ptnaw mailing
alias.

Thanks
Partha

> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Monday, October 07, 2013 2:16 PM
> To: Magnus Westerlund; Parthasarathi R
> Cc: [e-mail]
> Subject: Re: SV: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-
> transports-01
> 
> On 10/07/2013 10:21 AM, Magnus Westerlund wrote:
> > On 2013-10-03 19:09, Parthasarathi R wrote:
> >> Hi Harald/Magnus,
> >>
> >>
> >>
> >> Thanks for the clarification.  Please clarify whether TCP/RTP/SAVPF
> will
> >> be registered in IANA as separate MMUSIC specification or any
> another
> >> simple mechanism exists to add IANA registry.
> > I think we might need a MMUSIC or AVTCORE SDP field proto cleanup
> > document. It is not only TCP/RTP/SAVPF that is missing, also AVPF and
> > SAVP is missing.
> >
> > But, before diving into this. Are there really consensus that we will
> > use IP/TCP/RFC4571 framing/RTP(SAVPF) rather than using TURN over TCP
> to
> > get a stack saying IP/TCP/TURN/RTP(SAVPF)?
> 
> I have seen this thread suggesting two stacks:
> 
> - TURN over TCP to a TURN server, UDP to final destination
> - RFC 4571 framing (I think) over TCP, all the way to the final
> destination
> 
> The latter would be done using ICE TCP candidates according to RFC
> 63something. I haven't yet seen one suggesting using the TURN framing
> all the way to the final destination; I'm not sure I've seen a way of
> signalling that either.
> 
> I think I've seen rough consensus that we should (SHOULD) support the
> former. Ihaven't seen anything stronger than a MAY support the latter,
> so for Transport, the only concern is that if we reference it, we
> reference it correctly.
> 
> 
> >
> > Their SDP identification are quite different. The later uses m= lines
> > indicating RTP/SAVPF with the TURN part in the ICE candidates.
> >
> >>
> >>
> >> I’m interested in seeing the usage of DTLS key exchange for SRTP
> within
> >> TCP/RTP/SAVPF profile. Even though DTLS is designed for
> connectionless
> >> protocol, I assume that it works with TCP (connection oriented)
> protocol
> >> as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a
> SRTP
> >> key exchange mechanism. Please correct me in case I’m missing
> something.
> > In that case you definitely need an MMUSIC document. This as we need
> to
> > figure out if using TLS to represent DTLS was a misstake as I think
> you
> > need to separate DTLS and TLS when sent over TCP for the different
> > purposes in that case.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ---------------------------------------------------------------------
> -
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ---------------------------------------------------------------------
> -
> > Ericsson AB                | Phone  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > ---------------------------------------------------------------------
> -
> >
> 
> 
> --
> Surveillance is pervasive. Go Dark.