Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes: Do we need to mandate identical SDP attribute values?

[Suhas Nandakumar <[e-mail]>]

Hi,


On Thu, Oct 6, 2016 at 2:35 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> …
>
>> [Suhas]
>>
>>
>>
>> Meta Note:
>>
>> The mux draft has stayed away from offer/answer procedures to avoid
>> ambiguities with offers/re-offers and its focus has been defining generic
>> framework categorizing SDP attributes while performing Media multiplexing
>>
>>
>>
>> Thus, the case of initial offer applies as well. In that context, on
>> Initial Offer, the offerer will repeat the SDP attributes that fall under
>> IDENTICAL category on all the m=lines that it plans to multiplex.
>>
>>
>>
>> What is the reason for having different rules for IDENTICAL and TRANPORT?
>> With TRANSPORT you can use different attribute values, because the
>> “software will pick the correct value”. Why not use the software-must-pick
>> rule also for IDENTICAL?
>>
>>
>>
>
> [Suhas]
>
>  Let's try to explain this with example attributes. a=rtcp-mux which is
> categorized as IDENTICAL and ice-candidates which falls under TRANSPORT
> category.
>
> For ice-candidates ,the offerer in the initial offer will include
> different ice-pwd, candidates lines per m=line since it's not sure of the
> BUNDLE negotiation. Thus once BUNDLE gets successfully negotiated , the
> software picks the ones from the m=line that is selected for BUNDling.
> OTOH, if the BUNDLE get's rejected each m=line's individual ice info will
> be used.
>
> Correct.
>
> For a=rtcp-mux,  in the initial Offer, the offerer must include it in all
> the m=lines (repeated) since there is no way for the software to decide the
> intent of the Offerer in scenarios where the BUNDLE gets rejected ( If the
> offerer didn't repeat the attribute, the software cannot assume the
> offerer's intention of whether to imply a=rtcp-mux for  the m=lines or the
> Offerer itself didn't want to perform rtcp muxing )
>
> If there is no rtcp-mux attribute, and if the BUNDLE is rejected (or if an
> m- line is not accepted into the BUNDLE group), normal SDP O/A procedures
> apply and there would be no RTCP MUX.
>
> Anyway, even if we do mandate identical attribute values in case of
> IDENTICAL, is draft-mux-categories clear that it applies already before a
> BUNDLE group has been created? I believe there were some clarification
> questions about that also earlier.
>
>
[Suhas] .. I personally feel that clarification should be in the BUNDLE
spec. BUNDLE spec already has clarification on how IDENTICAL and TRANSPORT
categories are treated once shared address is selected as you pointed out
earlier (also in section 8.1).
Similarly, it needs to to address the case for before shared address
getting selected, if it is not already (I thought section 7.3 implied that
already).



> Regards,
>
> Christer
>
>
>