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

[Magnus Westerlund <[e-mail]>]

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