[itu-sg16] SVC Adhoc Group

[stephen botzko]

As the chair of the Q1 SVC Adhoc Group, I have meet informally with several
folks, including Vidyo and Tandberg.

Since the IETF SVC draft is now moving into the RFC editor's queue, it is an
appropriate time to start working on ITU-T signaling.

There is general consensus that H.32x systems should support the SST mode of
SVC that is specified in the current IETF draft.  Although Radvision
suggested last year that the MST mode also would be required, there seems to
be little support for that requirement.  The MST mode is intended for
multicast, and is considerably more complex than SST.

There is language in H.323 (Annex B) on the use of layered codecs.  This
text seems more applicable to MST than SST, since SST is sent as a single
RTP session.  Some normative statements (for instance the way timestamps of
the various layers are coordinated) appears to be incompatible with the IETF
SVC draft.  We also note that there is an analogous RFC in the IETF which
also defines the use of layered codecs.  This signaling was not employed in
the SVC draft.

Athough the Annex B text should be reviewed more carefully, there is general
consensus that simple interworking through H.32x<->SIP gateways and in
multi-protocol conference bridges is more important than continuing the use
of the existing Annex B procedures.

There is also general consensus that attempting to precisely define the
various combinations of layers that a receiver is capable of receiving is
very complex, and should not be attempted in the signaling.Polycom at least
sees the value in being able to actively negotiate which layers are being
sent, in a way that is compatible with the current IETF draft.  As chair, I
believe that most others also support this view.  Certainly no one has
objected to including this capability.  One way this could be accomplished
in H.241, is to combine a simple SVC profile capability with a layer
negotiation procedure that would be analogous to the set submode procedures.


Please do respond (either to this list or to me personally) on this topic,
especially if you have a different view on the topics above, or if you see
additional requirements that are not included.  I am not planning to hold an
audio conference call at this time, but if people see a need for this I will
schedule one.

Stephen Botzko
Polycom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20100628/f91a5cd5/attachment-0002.html>