Subject: [AVT] Sockets in multicast DTLS-SRTP

From: Romain Biehlmann <[email-masked]>
Date: Tue, 23 Mar 2010 13:27:21 +0100

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.
I am not sure, though, to get how it should work in the case of a (one
to many) multicast session.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Mar 2010 14:34:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Romain Biehlmann
> Sent: Tuesday, March 23, 2010 5:27 AM
> To: [email-masked]
> Subject: [AVT] Sockets in multicast DTLS-SRTP
> 
> Hi all,
> 

Right, and demultiplexed as shown in
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07#section-5.1.2

> 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

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Romain Biehlmann <[email-masked]>
Date: Wed, 24 Mar 2010 09:20:28 +0100

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Mar 2010 11:30:52 -0700

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

> From: Romain Biehlmann [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2010 1:20 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> 
> Hi,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 26 Mar 2010 15:02:44 -0700

On 3/26/10 11:30 AM, Dan Wing (dwing) wrote:
> next week
s/over/after (on PTO).

Thanks

-- Flemming

> (he is editor of SDP Capability Negotiation and