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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------