Re: [MMUSIC] Media level ice-options attribute

[Marc Petit-Huguenin <[e-mail]>]

On 03/30/2011 11:22 AM, Flemming Andreasen wrote:
>   Hi Marc
>
> Is there any particular reason why you want to redefine the existing ice-options
> attribute rather than defining a new media-level attribute, e.g. "ice-m-options"
> that has the semantics you are looking for here ? My main concern is backwards
> compatibility and possible semantic confusion, especially once we start
> considering interaction with other SDP extensions.

That's a possibility, but you still want to require all future new session-level 
a=ice-options attribute definitions to provide an algorithm to aggregate the 
media-level a=ice-m-options attributes.  Using the same name could help future 
reviewers.

>
> Thanks
>
> -- Flemming
>
> On 3/24/11 3:11 PM, Marc Petit-Huguenin wrote:
>>
>> At the suggestions of the chairs, I'll explain here the problem that I will be
>> presenting in Prague, so we can discuss it beforehand and make the best of the
>> 10 minutes allocated to the presentation.
>>
>> This problem was discovered when implementing an endpoint supporting
>> disaggregated media. draft-loreto-dispatch-disaggregated-media gives a good
>> presentation of what disaggregated media is, but to simplify it is when the SIP
>> stack is physically separated from the RTP stack, or stacks in this case, each
>> with its own ICE implementation. In my case I had audio on one device, with my
>> own ICE/RTP stack, and video on a separate device with a proprietary stack. I
>> wanted to add ECN support in my RTP stack but I could not signal it in the SDP
>> resulting of the merge of the SDP coming from the two RTP stacks because the
>> ice-options attribute is supposed to carry this piece of information in a
>> session-level only attribute, where in my case only one media was supporting
>> ECN. If I added an ice-options at the media level it will be ignored by the
>> stack on the other side, if I added it at the session level the other side will
>> think that both medias supports ECN.
>>
>> So this proposal is to change the level from session-only to session *and*
>> media. But doing only this creates problems when a stack implementing this
>> proposal is used with a legacy stack on the other side. This is why the
>> proposal also mandates to define how different ice-options at the media level
>> are combined into the session level ice-options. For rtp+ecn, the rules would
>> be that the session level attribute is set only if all the medias use the
>> rtp+ecn option.
>>
>> A similar problem exist for the ice-lite option, which is also defined only at
>> the session level, when different implementations want to use different values.
>>
>> Here my proposal is to not change anything, mostly because I do not see how
>> media level values can be combined to a media level value that makes sense. On
>> the other hand I do not care much about ICE-lite, so there is probably perhaps
>> something that I missed.
>>
>> The slides for the presentation are available here:
>>
>> http://www.ietf.org/proceedings/80/slides/mmusic-1.pdf
>>
>> The I-D is available here:
>>
>> https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/
>>

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org