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

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