[MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format

["Pedro Capelastegui" <[e-mail]>]

Hi,

Here are some further comments on
draft-greevenbosch-mmusic-signal-3d-format. These are focused on the 3d
format negotiation process, and specifically how the extension behaves when
multiple 3d configuration options are offered.

My main concern is that, in order to offer alternate 3d format
configurations, the offerer has to include additional 'm=' lines in the SDP.
Currently, each media descriptor can have a single 3d format, and each 3d
format is associated to 1 or 2 media descriptors. This is not an issue in
offers with a single 3d format (see examples 9.1, 9.2 and 9.3), but when
several 3d formats are offered, the number of media descriptors multiplies.
This can be observed in example 9.4, where 4 media descriptors are used in
the offer, though the answerer is expected to reject all but two. In
general, in order to provide N 3D format options for a 3D video
stream,between N and 2N media descriptors will be required in the offered
SDP, of which only one or two will be used.

I think this proliferation of media descriptions has several drawbacks. For
one, it goes against the general philosophy of SDP negotiation. Normally,
when different possible configurations exist for a media stream, they are
shown as different media formats within a single media descriptor. Using
multiple media descriptors that actually refer to the same media stream (the
3D video stream, or a subset of it), and having the answerer reject all but
the ones with the desired configuration breaks this model. In addition, this
excess of 'm=' lines may have a negative effect when combined with
techniques such as ICE, and could be confusing for 3d-unaware nodes.

On the other hand, this is only a problem if user agents are expected to
select between many 3d formats on an average session. Unfortunately, I think
this will be the case. At the very least, a UA starting a 3D session should
provide a single 3D format and the option not to use 3D. Apart from that, a
3D user agent intended to be interoperable with other UAs should support
several 3D formats, including video+depth and transmission of 2 views. 

The solution, in my opinion, would be to shift away from the current model
and instead associate each 3D format with a payload type within a media
description. I will discuss how this can be done in a separate mail.

Regards,

Pedro