Re: [MMUSIC] The 3D drafts

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

Hi Bert,

My main concern is that the offerer may end up receiving more video streams
than it wants and, more importantly, more than it can process. Although the
draft does allow for re-negotiating the session to reduce the number of
streams, this still leaves a window where an excess of streams is
transmitted, leading to wasted bandwidth, and potentially overloading the
offerer’s network or terminal.

As a side effect, when QoS systems are used, this may result in excessive
bandwidth reservations,  or in rejected sessions due to insufficient network
resources.

Note that, while I also discussed re-negotiating sessions in my message, my
proposal in that case was to start out with a single stream and add more
later, ruling out the possibility of transmitting unwanted streams.

That said, there is one point that I hadn’t really taken into consideration
until Paul brought it up: the potential for an offerer to receive lots of
unwanted streams already exists in other SDP offer/answer scenarios.
Notably, this includes offers with multiple media formats for a m= line,
(which describes almost every SDP offer in existence). So it’s possible that
the problem is less severe than I originally thought, but also more general
than this specific 3D video scenario. I’ll need to give this issue some
thought.

Best regards,
Pedro

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Bert Greevenbosch
> Sent: Monday, February 13, 2012 4:12 AM
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [MMUSIC] The 3D drafts
> 
> Hi Pedro,
> 
> Thank you for your feedback. I will soon reply to your other e-mail, about
the
> simulcast case, too.
> 
> As to the issue with multiple offered streams, this has been considered in
> the draft. Especially, section 7 contains the following text:
> 
> "
> The following statements apply for the answerer:
> ...
>    o  If the answerer selects multiple 3D formats, it MUST be prepared
>       to send/receive (depending on whether it is a streaming server or
>       client or both) associated streams simultaneously.
> 
> The following statements apply for the offerer:
> ...
>    o  When multiple 3D formats are selected, the offerer MAY initiate
>       all associated streams.  Alternatively, it MAY update its offer
>       with a reduced number of 3D formats.
> "
> 
> As you wrote below, indeed the draft proposes re-negotiation if the
offerer
> doesn't like the choice of the answerer.
> 
> Why do you think this should be avoided?
> 
> Best regards,
> Bert
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: 11 February 2012 02:25
> To: [e-mail]
> Subject: Re: [MMUSIC] The 3D drafts
> 
> 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:*[e-mail] [mailto:[e-mail]]
> *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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> -----
> No se encontraron virus en este mensaje.
> Comprobado por AVG - www.avg.com
> Versión: 10.0.1424 / Base de datos de virus: 2112/4800 - Fecha de
publicación:
> 02/09/12