Re: [AVT] Sockets in multicast DTLS-SRTP

Dan,
I am not sure I understand the issue. Are you saying that for multicast
stream you suggest to send the keys as unicast streams to each participants.
I am not sure this is even possible since if the session is announced using
declarative SDP for example in the SSM (single source multicast) the sender
will not know the receivers and there is no offer answer. I assumed that the
keys will be sent in the multicast session and will probably will need to be
repeated. 
One other way if the keys are not in the declarative SDP is to allow the
receivers to ask for keys when joining the multicast group by using RTCP
ffedback.

Roni Even

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Dan Wing
> Sent: Friday, March 26, 2010 9:31 PM
> To: 'Romain Biehlmann'
> Cc: 'Flemming Andreasen'; avt@ietf.org
> Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> 
> 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 (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
> > >
> > >
> >
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt