Re: [MMUSIC] SDP attribute level for disaggregated media [was Re: 4566bis outstanding issues]

["Ali C. Begen (abegen)" <[e-mail]>]

I have not seen any objections to this change request? So, I will include Marc's text in the next revision.

-acbegen

On Jun 16, 2014, at 12:11 AM, Marc Petit-Huguenin <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 06/06/2014 03:19 PM, Ali C. Begen (abegen) wrote:
>> Hi everyone
>> 
> 
> [...]
> 
>> 
>> 
>> These are the issues I was able to identify. There is one more thing
>> related to ICE and I sent an email about this to Marc Petit-Huguenin. As
>> soon as he responds and depending on his answer, I might add one more
>> issue.
>> 
> 
> Let me first explain the problem as I perceive it:
> 
> The SDP was designed so that different endpoints can be part of an RTP
> session, i.e. each m= section can used a different IP address.  For example
> one can imagine that during an IETF meeting each microphone has its own IP
> address and stream audio directly to some destination (in that example the IP
> address in the SDP is only use for RTCP).  If this use case was not possible,
> then it would be only possible to use c= at the session level.
> draft-loreto-splices-disaggregated-media was, I think, the first document to
> call this "media disaggregation".
> 
> Now if we expand this to ICE, it means that each ICE agent declared in a SDP
> has to be independent of each other, i.e. each microphone in our example has
> it's own ICE agent, and they do not even to be from the same vendor.  That
> means that all SDP attributes needs to be at least media-level attributes, and
> eventually both media- and session- level attributes.  IANA fixed the problem
> for ice-mismatch, but the problem still exists for ice-options, and fixing it
> is part of rfc5245bis.
> 
> Now my suggestion was that for future SDP attributes, people should really
> think about the disaggregated case when they choose between a session-level
> only attribute or an attribute that works at both session- and media-level,
> because using a session-level only attribute prevents media disaggregation.  I
> could not find this problem in any existing attribute at the time I did the
> analysis but in ICE attributes, but note that this is not a problem specific
> to ICE.
> 
> So I would suggest adding some text after this paragraph in section 8.2.4:
> 
> 'Submitters of registrations should ensure that the specification is
> in the spirit of SDP attributes, most notably that the attribute is
> platform independent in the sense that it makes no implicit
> assumptions about operating systems and does not name specific pieces
> of software in a manner that might inhibit interoperability.'
> 
> Something like this:
> 
> 'Submitters of registrations should also carefully choose the type of
> attribute. They should not choose a session-level only type when the attribute
> can have different values when media is disaggregated, i.e. when each m=
> section has its own IP address on a different endpoint.  In that case the
> attribute type chosen should be "both".'
> 
> Thanks.
> 
> - -- 
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJTngvsAAoJECnERZXWan7EkoEP+QH/FamXyYcisXxR8vtRBUAV
> D0MrwvRzzjQfAEW2aRSYPC12de0UeC7uYCOx9l7Cv1NKcFccdD/3NsDUNYy5C++Q
> siL0YAcTIhuCiBYkYPUEq3Ix3CrXGnspBV2kbJdcBPgGuIw7jXNHQh5l5bvoAtJs
> isHGev6rn6wGR2WheiYtlQ1AInFmjD5MqOyu9xtAAbdIJBWrqFzDsSq4vAevSyzL
> EYPgW6Op6UoP6zGIB45PRXiGP//5Gj8jri9wXjp3M8cyvgpK6CoHoNe6m1rGuWqS
> pMOh6vZRjRbkRpcufJ29tuV8SJ513m5x0pDSiCZAyNi47q3zgN+W++i4eX1ujnbN
> D/UjmQmacSFO3N/QWvuAlZH9VRSVHdUbyw/NXUFFhCjexSokn/nBh7eFFvwMJyp6
> ZuxpKjcg+wrOxjkocSq8bNXcQLR1yohADKN1ePyHHvZ84+gkinlIpKMuegEBBFi5
> OVe0O4QiRjKd3h1ewO98tzPUKVhaD9nSkLT7eOjHU3Xfz5Ol5tlA50+5P7tcN43h
> OO10nUijN4lxBsTi0WNC2sFpE3WXQ8gAkWHKyedfeMx9Uvl2SF18QFujAeD1oYIN
> jS+SuZOlO7S6t2naMzyJj10yOxzgSnNYBGBQQ2yP1oE1qtiZjCDhTTaJIMjTgCYu
> V/fj5tQ5v43FLPpKlD+8
> =qu35
> -----END PGP SIGNATURE-----