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

[Suhas Nandakumar <[e-mail]>]

Hi Christer,Bo

   Just to close the loop on this topic, I don't see misalignment between
Bundle and Mux specs. However, adding  clarification on the fact that the
categories apply even during the initial offer(or before bundle gets
negotiated) and their semantics apply , might be needed in the Bundle spec,
if it is not already clear

Section 8.1 already talks about categories interpretation once bundle gets
negotiated. That section might be a right place to add above clarification.
I would leave the decision to Christer on that :)

Thanks
Suhas

On Thursday, October 6, 2016, Suhas Nandakumar <[e-mail]> wrote:

> Hi,
>
>
> On Thu, Oct 6, 2016 at 2:35 AM, Christer Holmberg <
> [e-mail]
> <javascript:_e(%7B%7D,'cvml','[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
>>
>>
>>
>