Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

[Barry Leiba <[e-mail]>]

Bernard, I will wait for your response before proceeding.

Thanks, all,
Barry

On Fri, Feb 14, 2020 at 8:26 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> So an update is now submitted. It should address Bernards comments. Please
> review it. Sorry for the delay in getting this finished up.
>
> Cheers
>
> Magnus Westerlund
>
> On Fri, 2020-02-14 at 14:57 +0000, Magnus Westerlund wrote:
> >       Error verifying signature: parse error
> > Hi,
> >
> > Sorry, this has been down prioritized again by me. Will do my best to
> get it
> > moving.
> >
> > Cheers
> >
> > Magnus
> >
> > On Fri, 2020-02-14 at 04:41 +0000, Barry Leiba wrote:
> > > Hi... any progress on this?
> > >
> > > Barry
> > >
> > > On Tue, Dec 3, 2019 at 7:03 AM Bo Burman <[e-mail]>
> wrote:
> > > > Hi,
> > > >
> > > > I've started a (so far author-internal) draft -10 that tries to
> address
> > > > most
> > > > of Bernard's comments; in progress.
> > > >
> > > > I however didn't yet do a total re-haul to consider if use of
> MID/RID/RRID
> > > > is
> > > > sufficiently covered and described throughout the document. Help on
> > > > identifying potentially impacted text would be greatly appreciated,
> from
> > > > my
> > > > co-authors as well as from the list.
> > > >
> > > > Regarding Bernard's comment to section 5.2:
> > > >
> > > > >  3.  For applications with dynamic usage of RTP streams, i.e.
> > > > >       frequently added and removed, having much of the state
> associated
> > > > >       with the RTP session rather than per individual SSRC can
> avoid
> > > > >       the need for in-session signalling of meta-information about
> each
> > > >
> > > >  >      SSRC.
> > > > >
> > > > > [BA] Not sure I grasp your point here.  If there are multiple
> SSRCs in
> > > >
> > > > the
> > > > > same RTP session, avoiding the need for in-session signaling
> typically
> > > > > requires:
> > > > >
> > > > > a. A mechanism for handling "unsignaled streams" (e.g. an
> Unhandled RTP
> > > > > event as in ORTC), OR
> > > > >
> > > > > b. Support for MID to allow routing to the correct RTP receiver
> without
> > > > > in-session signaling of the SSRC.
> > > >
> > > > Firstly, I think the original text in bullet 3 doesn't consider use
> of
> > > > bundle
> > > > or MID but rather assumes the pre-bundle type of RTP session. Adding
> use
> > > > of
> > > > MID would be part of an RTP session state (e.g. mapping SSRC to an
> media
> > > > source, which would also map to an m= line if SDP is used) that
> doesn't
> > > > require in-session signaling. That would correspond to your
> alternative b.
> > > >
> > > > Secondly, there could still be "unsignaled streams" handling, either
> > > > within
> > > > (using same) MID or when not using MID in the RTP session, where
> other
> > > > RTP
> > > > session information can be used to allow proper handling of
> dynamically
> > > > occuring RTP streams, such as e.g. RTCP SDES CNAME to identify RTP
> > > > streams
> > > > sent from the same endpoint (but not necessarily the same media
> source)
> >
> > --=-W6zG64IaZZKwKI/Kf88C--
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>