Re: [MMUSIC] The 3D drafts

[Paul Kyzivat <pkyzivat at alum.mit.edu>]

Pedro,

The issue you raise here is not unique to 3D.
It shows up in many forms:

- an offer of multiple codecs on an m-line
  theoretically means the offerer can use them concurrently.
  But some implementations can only support one at a time.

- offering seccure and insecure versions of a stream

- offering ipv4 and ipv6 versions of a stream

It is not desirable to come up with a 3D-specific solution to this 
problem. Rather you should look to what is available as a generic solution.

The most obvious approach that comes to mind for me is to use the 
capability framework, to offer one form and describe the others as 
capabilities.

	Thanks,
	Paul

On 2/10/12 11:37 AM, Pedro Capelastegui wrote:
> Hi Bert,
>
> Another open issue for the “3d format” draft was the negotiation of
> sessions with more than one 3D stream. I discuss it in this mail.
>
> In the current version of the draft, it is possible to set up a session
> with multiple 3D streams. An offerer can include several 3D streams in
> its SDP, and the answerer can select any number of them. There are rules
> that prevent the answerer from selecting more streams than it can
> process. However, nothing stops an answerer from selecting more streams
> than _the offerer_ can send or receive – in fact, the answerer has no
> way to know how many streams can be handled by the offerer.
>
> This can come up even in very simple scenarios. Consider the following
> offer:
>
> m=video 1111 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP SbS
>
> m=video 1112 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP TaB
>
> This SDP is intended as an offer of a single 3D stream with 2 possible
> configurations: frame-packed side-by-side, and top-bottom. The UA
> generating the offer expects the answerer to select only one 3D format.
> But the answerer doesn’t know that, and it’s perfectly legal for it to
> respond by selecting both 3D formats:
>
> m=video 2222 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP SbS
>
> m=video 2223 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP TaB
>
> At this point, the offerer is receiving media that it’s not prepared to
> handle (which goes against the offer/answer model), and should either
> re-invite, or close the session.
>
> How to avoid this scenario?
>
> The straightforward solution is to forbid answerers from selecting more
> than one 3D format altogether. This is certainly effective, but too
> limiting, as it rules out the possibility of multi-stream 3D sessions.
>
> A better solution would be to create a new  session level attribute
> (“a=max3dstreams”) for the offerer to indicate the maximum number of 3D
> streams it wants for this session. The default value for this attribute
> would be ‘1’, so that the attribute would only be needed for sessions
> with multiple streams.
>
> This should cover most scenarios, but there are a few corner cases that
> are left unsupported. Consider a user agent that wants to initiate a
> session with 2 3D streams, with the constraint that one of the streams
> needs to have 2 views, and the other needs to have a view and a depth
> map. This is a rare scenario, but it can happen if the UA has different
> 3D screens, one taking left and right views as input, and the other
> using video+depth map:
>
> a=max3dstreams:2
>
> m=video 1111 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP SbS
>
> m=video 1112 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:FP TaB
>
> m=video 1113 RTP/AVP 99
>
> a=rtpmap:99 H264/90000
>
> a=3dFormat:2DA CD
>
> For this UA, an answer selecting “FP SbS” and “2DA CD” as 3d formats, or
> “FP  TaB” and “2DA CD” would be acceptable, but one with “FP SbS” and
> “FP  TaB” would not.
>
> We could extend the signalling to cover this kind of scenario (e.g. by
> introducing a new type of grouping), but I think this would be too
> complex, and not worth the effort. In these cases, the offerer can start
> by configuring the session with a single 3D stream, and add any
> additional 3D streams in later offer/answer exchanges.
>
> Best regards,
>
> Pedro
>
> *From:*mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] *On
> Behalf Of *Bert Greevenbosch
> *Sent:* Monday, February 06, 2012 1:32 AM
> *To:* IETF - MMUSIC
> *Subject:* [MMUSIC] The 3D drafts
>
> Hi all,
>
> I was wondering, if everybody is happy with the current versions of the
> 3D drafts, or are there still open issues?
>
> I look forward to your comments.
>
> Best regards,
>
> Bert
>
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/
>
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/
>
> ------------------------------------------------------------------------
>
> No se encontraron virus en este mensaje.
> Comprobado por AVG - www.avg.com <http://www.avg.com>
> Versión: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de
> publicación: 02/05/12
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic