Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

From: "David Benham (dbenham)" <[email-masked]>
Date: Mon, 10 Nov 2014 10:21:50 +0000

For purposes of requirements-00, we purposefully avoided trying to select a particular topology and thus no repeat of one of its terms.     

If we come up with a solution variant that doesn't require changes to SRTP but does require addition(s)/mod(s) to the topology draft, for example, then I assert we would want to do that.    Plus, to quote Stephan from an earlier email,  "... a document like the topologies will *always* be incomplete."

> I read the document and was wondering which of the topologies in
> draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it
> the selective forward middlebox. It will be good to either use the same
> terminology or if it is a different topology define it in the topology
> draft.
> 
> 
> As for the sequence number, when using example in figure 3 , each RTP stream
> received (from the same SSRC) may have a gap in the sequence number or the
> receiver may report a loss for a stream switched out by the midlebox? Any
> requirement here?
> 
> 
> Thanks
> 
> 
> Roni Even
>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Nov 2014 17:59:24 +0200

Hi,
This is OK but if this is not one of the currently specified topologies I am
missing the expected RTCP handling and RTP behavior for the case where this
untrusted middle entity switch part of the received streams.

The second part of my question about sequence number gaps was an example of
an issue that is not clear.
Other questions may be whether the middle box establish one or multiple RTP
sessions for distributing the media.

As for the keys distribution, is the requirement to use the same key with
all receivers (EKT?)

Roni

> -----Original Message-----
> From: David Benham (dbenham) [mailto:[email-masked]]
> Sent: 10 November, 2014 12:22 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-
> 00
> 
> For purposes of requirements-00, we purposefully avoided trying to select
a
> particular topology and thus no repeat of one of its terms.
> 
> If we come up with a solution variant that doesn't require changes to SRTP
but
> does require addition(s)/mod(s) to the topology draft, for example, then I
assert
> we would want to do that.    Plus, to quote Stephan from an earlier email,
"... a
> document like the topologies will *always* be incomplete."
> 
> 
> > draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3).
> > Is it the selective forward middlebox. It will be good to either use
> > the same terminology or if it is a different topology define it in the
> > topology draft.
> >
> >
> > As for the sequence number, when using example in figure 3 , each RTP
> > stream received (from the same SSRC) may have a gap in the sequence
> > number or the receiver may report a loss for a stream switched out by
> > the midlebox? Any requirement here?
> >
> >
> > Thanks
> >
> >
> > Roni Even
> >