Re: [AVT] Sockets in multicast DTLS-SRTP


On 3/26/10 11:30 AM, Dan Wing (dwing) wrote:
>
> Thanks for explaining the issue.  I believe we don't yet know
> how to have SDP associate a unicast session (for DTLS-SRTP)
> with a multicast session (for receiving the SRTP-encrypted
> stream).  I expect there is an answer in MMUSIC's SDP
> Capability Negotiation and/or what is being done to mix
> unicast and multicast in draft-ietf-avt-rapid-acquisition-for-rtp,
> or somewhere.
>
> Flemming Andreasen (CC'd) will take a look at this over the
> next week
>
s/over/after (on PTO).

Thanks

-- Flemming

> (he is editor of SDP Capability Negotiation and
> co-author of EKT).  But at this point I believe it will
> require additional standards work to mix unicast/multicast.
>
> -d
>
>
> > -----Original Message-----
> > From: Romain Biehlmann [mailto:romain.biehlmann@gmail.com]
> > Sent: Wednesday, March 24, 2010 1:20 AM
> > To: Dan Wing
> > Cc: avt@ietf.org
> > Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> >
> > Hi,
> >
> > And thank you for your fast answer!
> >
> > I actually already planned on using KTR, which uses EKT, but got stuck
> > by this socket problem.
> >
> > I don't get how the data should be multiplexed in the case of a
> > multicast session since two sockets will be opened on the clients'
> > side (as shown on the drawing below)... Or am I completely wrong?
> >
> > ----------
> > | server |---- SRTP multicast session -------------------
> > ----------                                              |
> >   | | |                                  ------------   |
> >   | | |--- DTLS KTR unicast session 1 ---| client 1 |---|
> >   | |                                    ------------   |
> >   | |                                    ------------   |
> >   | |----- DTLS KTR unicast session 2 ---| client 2 |---|
> >   |                                      ------------   |
> >   |                                      ------------   |
> >   |------- DTLS KTR unicast session 3 ---| client 3 |---|
> >                                          ------------
> >
> > Thank you very much for the time you take to read me.
> >
> > Romain
> >
> >
> >
> > 2010/3/23 Dan Wing <dwing@cisco.com>:
> > >> -----Original Message-----
> > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
> > >> Behalf Of Romain Biehlmann
> > >> Sent: Tuesday, March 23, 2010 5:27 AM
> > >> To: avt@ietf.org
> > >> Subject: [AVT] Sockets in multicast DTLS-SRTP
> > >>
> > >> Hi all,
> > >>
> > >> I hope my question is not too dumb, and not too
> > >> implementation-oriented; if so, please accept my apologies
> > and ignore
> > >> it.
> > >>
> > >> In http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07 chapter
> > >> 5.1.1, we can read the following:
> > >> "When a user of DTLS wishes to send an RTP packet in SRTP mode it
> > >> delivers it to the DTLS implementation as an ordinary
> > application data
> > >> write (e.g., SSL_write())."
> > >>
> > >> From that, I understand that in the case of a unicast session, only
> > >> one socket is needed for the transmission of STUN, SRTP and DTLS
> > >> datagrams.
> > >
> > > Right, and demultiplexed as shown in
> > > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07#section-5.1.2
> > >
> > >> I am not sure, though, to get how it should work in the
> > case of a (one
> > >> to many) multicast session.
> > >
> > > Use DTLS-SRTP with EKT.  EKT allows telling each of the receivers
> > > the same key.  The sender then sends the same multicast packet
> > > (or if using unicast, the sender sends the same packet, unicast,
> > > to each NNN receivers).
> > >
> > > EKT is http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-00
> > >
> > > -d
> > >
> > >> Isn't the server supposed to send SRTP datagrams to a broadcast
> > >> address, whereas DTLS data must be sent directly to (unicast)
> > >> designated clients? Is the sentence in the draft only applicable to
> > >> unicast?
> > >>
> > >> I thank you in advance for your valuable insight.
> > >>
> > >> Romain
> > >> _______________________________________________
> > >> Audio/Video Transport Working Group
> > >> avt@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
>