Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt

[Roni Even <[e-mail]>]

Hi Magnus,
I will draft the proposed text and send it to the list

As for allowed mix, I understand your comment now.

The question is what is a stream, it is clear in the non bundled case but for the bundle case my assumption was that still each m-line provide a separate stream so the each m-line can have different allowed mix, one use case is for a media switching MCU that may redirect the incoming streams to different receivers, some support bundle and some not in which case the ones that do not support bundle may negotiate allowed mixed only for part of the m-lines.
I think that at least we should allow this but maybe mention that the best way is to have allowed mixed on the session level or in all bundled m-lines

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: יום ד 17 מאי 2017 18:43
> To: Roni Even; [e-mail]
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
> 
> Hi Roni,
> 
> Den 2017-05-11 kl. 09:40, skrev Roni Even:
> > Hi Magnus, Since I do not have strong opinion about the IDs issues I
> > can live with your text, and add it to section 7 "SDP offer/answer".
> 
> First of all, do not add my text raw, that will not make sense I believe. You will
> need to add context and framing to the rules.
> 
> >
> > 1. The ID space is common across all m= lines (using RTP) in a BUNDLE
> > group.
> >
> > 2. Each m= block can define a subset of the total defined ID numbers
> > indicating limits in use for a particular media source. This allows
> > for example audio and video media sources to use different set of
> > header extensions.
> >
> > 3. An ID number that is defined in multiple m= blocks MUST have
> > identical extmap configuration, i.e. the same URL and any extension
> > attributes that effect the usage or form of the RTP header extension.
> >
> > 4. The extmap direction setting for a particular ID number MAY be
> > independently set per media source (m= block). This as some media
> > source may be unidirectional and other bi-directional.
> >
> > Just some clarifications
> >
> > From 3 and 4 I am not sure about the following bundled m-lines, is
> > this allowed based on 4 or not because of 3?
> >
> > M=video A=extmap:1/recvonly uri-gps-string
> >
> > M=video A=extmap:1/sendrecv uri-gps-string
> >
> 
> I am of the opinion that the above example shall be allowed. The RTP session
> configuration do not care about direction. The usage configuration of the
> media streams sent in the RTP session may care about direcitonality.
> 
> It might be that folding the exception 4) provides into 3) is the better text
> solution here.
> 
> > There is no problem if the directionality is not specified and is
> > based on the RTP stream directionality.
> 
> Agreed
> 
> >
> > As for the allowed mixed as normal I do not understand your concern
> > about having one m-line support it and the other not.
> 
> My main issue is the uncertainty over the functionality and what will happen
> when there is one m= line with mixed and one without in a bundle group. As
> I see it creates a number of potential outcomes, depending on how the
> answerer behaves.
> 
> Alt 1) The answer splits the bundle group to avoid having different
> capabilities in the same RTP session.
> 
> alt 2) The answer refuses to support mixed. And I would argue that would be
> the default case unless the m= lines are split into differnt RTP sessions due to
> this sentence in Seciton 4.1.2:
> 
>     A stream MUST contain only one-byte or two-byte
>     headers unless it is known that all recipients support mixing, either
>     by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
>     of-band knowledge.
> 
> As it is explicitly stated that not all receivers, i.e. all m= streams supports the
> functionality it is turned off.
> 
> alt 3) The answer accepts mixed for one and non mixed for the other m=
> stream. Making another interpretation or missing the above sentence.
> Thus resulting in that some SSRCs sends mixed and other not.
> 
> I can accept that it can be allowed, but then please clarify what the
> interpretation of that state is. Because I have as you see multiple ones.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------