Re: [AVT] Sockets in multicast DTLS-SRTP

["Dan Wing" <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, March 24, 2010 1:20 AM
> To: Dan Wing
> Cc: [e-mail]
> 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 <[e-mail]>:
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Romain Biehlmann
> >> Sent: Tuesday, March 23, 2010 5:27 AM
> >> To: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/avt
> >
> >
>