Re: Existing missmatch between SDP mux and BUNDLE

Hi,

SDP Mux says:

The attributes and their associated values (if any) in the IDENTICAL
    category MUST be repeated across all the media descriptions under
    multiplexing.

This I interpret as you really MUST include it each and every m= section that are bundled.
While BUNDLE with its updated text says, that you only should include the SDP attribute in the m= sections
that are first on any a=group:BUNDLE line, and not in another unless they have unique
transport information for the case of legacy fallback into individual lines.

Thus, I see SDP-mux require inclusion of the SDP attribute on each m= section in all cases and BUNDLE to
forbid such includion with the m= section in some cases. Thus, in those cases there is a conflict between
two different MUST statements.

Cheers

Magnus



Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
> Hi Magnus
>
> Can you elaborate on the mismatch ? I understand they do not say the 
> same thing, but it's not clear to me they are actually in conflict 
> with each other.
>
> How do you interpret the line ("associate" in particular)
> <quote>
> Otherwise the offerer/answerer MUST NOT associate such SDP attributes 
> with the "m=" line.
> <quote>
>
> Is the issue that bundle is relaxing the MUST requirement in bundle ?
>
> Thanks
>
> -- Flemming
>
> On 9/20/17 7:20 AM, Magnus Westerlund wrote:
>>
>> Hi,
>>
>> We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which 
>> references Bundle and SDP-Mux as it defines the mux category for its 
>> SDP attributes. As we made some last minute changes to MUX catergory 
>> for the extmap-allowed-mixed attribute we found some text needing 
>> changes. This anyway resulted in us noticing a missmatch between 
>> BUNDLE and sdp-mux.
>>
>> So Bundle (-39) states:
>>
>> 8.1. Mux Category Considerations
>>
>>     When an offerer or answerer associates SDP attributes with a bundled
>>     "m=" line (including any bundle-only "m=" line) associated with a
>>     shared address, IDENTICAL and TRANSPORT mux category SDP attributes
>>     [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
>>     line only if the "m=" line is also associated with the offerer/
>>     answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
>>     associate such SDP attributes with the "m=" line.  The rule above
>>     does not apply to a bundled "m=" line associated with a unique
>>     address.
>>
>>
>> However, SDP-mux states:
>>
>> 4.3. Category: IDENTICAL
>>
>>     The attributes and their associated values (if any) in the IDENTICAL
>>     category MUST be repeated across all the media descriptions under
>>     multiplexing.
>>
>> To my understanding the first is correct, but the change in BUNDLE has not been
>> reflected into SDP-mux doc. I assume that is in part due to its approved status.
>> Has the authors tracked the set of changes that are needed due to changes in BUNDLE?
>>
>> Do there exist a text change for this missmatch?
>>
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Media Technologies, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Torshamnsgatan 23           | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto:[email protected]
>> ----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic