Subject: [MMUSIC] Media level ice-options attribute

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 24 Mar 2011 07:11:07 -0700

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: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 30 Mar 2011 11:22:40 +0200

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.

Thanks

-- Flemming

On 3/24/11 3:11 PM, Marc Petit-Huguenin wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 31 Mar 2011 15:33:47 +0200

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.