Hi Dan,

Thank you for your answer: the first solution could solve the problem.
I now wonder about KTR: do you consider (a) as a replacement for (b)?

(a)
a=dtls-srtp-ktr
a=dtls-srtp IP4 192.168.0.1 12345

(b)
a=dtls-srtp-ktr
a=dtls-srtp-ktr-server:12345 IN IP4 192.168.0.1

Romain



On Thu, May 6, 2010 at 11:52 PM, Dan Wing <dwing@cisco.com> wrote:
> Romain,
>
> (added MMUSIC, as this is mostly about SDP in this post.)
>
> I talked with Flemming about this and there isn't an existing SDP mechanism we
> could easily extend to allow unicast keying of a multicast session.  The
> problem isn't just with multicast; there are some unicast scenarios, such as
> really large unicast groups, where having the 'speaker' or 'mixer' do the
> keying doesn't scale very well (and doing DTLS in a separate device can
> improve things).
>
> So, we would need to define a new SDP attribute that indicates the DTLS-SRTP
> peer for keying, something like this (which shows a DTLS-SRTP-encrypted
> multicast audio session),
>
>        v=0
>        o=- 25678 753849 IN IP4 192.0.2.1
>        s=
>        t=0 0
>        m=audio 41000 UDP/TLS/RTP/SAVP 98
>        c=IN IP4 233.252.0.2/255
>        a=dtls-srtp IP4 192.0.2.2 556677             <<<<<<<
>        a=dtls-srtp IP6 2001:db8:abcd::1234 556677   <<<<<<<
>
> The Answerer would choose IPv6 or IPv4, and initiate a DTLS-SRTP handshake
> with that address.  However, this won't work well if the DTLS-SRTP 'server' is
> behind a NAT, and almost begs for ICE to support that situation.  There seem
> to be two approaches:  (1) avoid the problem or (2) include support for ICE.
>
> (1) In this approach, we dictate that the DTLS-SRTP server's IP address(es)
> must be accessible to the Answerer.  This means the DTLS-SRTP server has to
> use a publicly-routed IP address.
>
> (2) In this approach, we use ICE, inside a=dtls-srtp attribute lines, which
> would look something like this:
>
>        v=0
>        o=- 25678 753849 IN IP4 192.0.2.1
>        s=
>        t=0 0
>        m=audio 41000 UDP/TLS/RTP/SAVP 98
>        c=IN IP4 233.252.0.2/255
>        a=dtls-srtp ice-pwd asd88fgpdd777uzjYhagZg
>        a=dtls-srtp ice-ufrag:8hhY
>        a=dtls-srtp candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
>        a=dtls-srtp candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
> raddr
>   10.0.1.1 rport 8998
>
>
> Would approach (1) meet your needs?
>
> -d
>
>
>
>> -----Original Message-----
>> From: Dan Wing [mailto:dwing@cisco.com]
>> Sent: Friday, March 26, 2010 11:31 AM
>> To: 'Romain Biehlmann'
>> Cc: 'avt@ietf.org'; 'Flemming Andreasen'
>> 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
>> > >
>> > >
>> >
>>
>
>