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

Bo said:

"Bernard, you indicate "a OR b" above; should they be seen as mutually
exclusive or could they both apply in the way I indicate? Would adding a
clarification along the lines above address your concern?"

[BA] A given application will typically use either a) or b), but for an
implementation as a whole, both could be implemented.  Note that the WebRTC
1.0 API only supports b) but not a), though other APIs (e.g. ORTC) support
both. Adding a clarification would address the concern.



On Tue, Dec 3, 2019 at 4:03 AM Bo Burman <[email protected]> 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).
> What
> type of RTP session information that is needed for proper RTP stream
> handling
> depends on, I must assume, application-dependent requirements. That would
> correspond to your alternative a.
>
> Bernard, you indicate "a OR b" above; should they be seen as mutually
> exclusive or could they both apply in the way I indicate? Would adding a
> clarification along the lines above address your concern?
>
> Cheers,
> /Bo
>
> > -----Original Message-----
> > From: Barry Leiba <[email protected]>
> > Sent: den 20 november 2019 07:22
> > To: Magnus Westerlund <[email protected]>
> > Cc: [email protected]; [email protected]
> > Subject: Re: Moving draft-ietf-avtcore-multiplex-guidelines along
> >
> > Thanks; I'd love to move it forward.
> >
> > b
> >
> > On Wed, Nov 20, 2019 at 2:20 PM Magnus Westerlund
> > <[email protected]> wrote:
> > >
> > > Hi Barry,
> > >
> > > Sorry, this has failed to get the necessary author time to take care
> > > of the comments. Will try to get it done soonish.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > >
>

_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt