ITU-T Telecommunication Standardization Sector	Working Document No. APC-1325
STUDY GROUP 16 Contribution	Original: English

__________________________

Sunriver, 08-11 September 1997

Question(s):	12, 13, 14/16
Source:	TELES AG / TU Berlin
Contact:	Jörg Ott, jo@teles.de				Voice:	+49 421 218-2085
								Fax:	+49 421 218-7000
Stephan Wenger, stewe@cs.tu-berlin.de	Voice:	+49 30 314-73160
Fax:	+49 30 314-25156
Title:		Extensions to H.245 to Support H.263 Video Redundancy Encoding
Purpose:	Proposal

1	Introduction
At the Boulder meeting in February 1997, the concept for video redundancy encoding has been introduced and at the Hertzliya meeting two further documents described the necessary extensions to the H.263+ RTP payload format (APC-1237) to accommodate the redundancy encoding and the necessary enhancements to H.245 (APC-1238).  The present is largely based up APC-1238 and addresses the required extensions to H.245 to enable signaling the appropriate capabilities as well as to allow opening logical channels with redundancy encoding as a payload.
This contribution is largely identical with APC-1238 presented in Hertzliya, with the exception that
•	it provides context information on other groups related to the video redundancy coding proposal,
•	the ASN.1 has been slightly revised to allow indicating different support modes for video redundancy coding, and
•	the necessary semantics descriptions for inclusion in H.245 Version 3 are provided.

2	Context and Status of Video Redundancy Coding (VRC) in Q15 and the IETF
Since the presentation of our last proposal (APC-1138) at the Hertzliya meeting in June, the development of the environment necessary to support VRC in H.323 systems has made significant progress.  The main issue, which was more or less unclear at that time, was the RTP payload specification for the support of H.263+ and/or VRC: two proposals for an RTP payload format for H.263+ data streams are currently discussed.  The intention of both groups working on those proposals is to merge both proposals together and eventually create a uniform RFC, which supports all identified transport related mode combinations. 
As far as we know today, VRC (or, more exact, the mode combinations of H.263+ necessary for VRC and the payload format specification) will be supported as an optional mechanism by the forthcoming RFC.  It should be noted, however, that there is no merged Internet Draft available to the IETF yet, so that it is unlikely that an RFC that can be referred to will be available by January 1998.
This work does not only take place in the IETF but also in two ad hoc groups of ITU-T Q15/16; the relevant ad hoc group reports will be submitted to the Q.15 meeting at Sunriver (unfortunately, they have not yet been posted on the reflector and hence cannot attached here.)  We do believe that the Sunriver meeting might be the right place to discuss any open issues on the timeframe of VRC and H.263+ payload specifications.
It is very unlikely, that any additional changes to the ASN.1 syntax regarding VRC will become necessary as a result of the yet unfinished payload discussions – at least in the section on VRC as proposed in this document.  It might become necessary to forbid certain usage forms because of limitations of the payload specification (which came in because of the necessity of keeping the payload headers small and simple); however, the appropriate place for this information is not the standard itself but rather an implementor's guide.
3	General Outline
An H.323 node announces its support of video redundancy encoding along with a set of parameters during the capability exchange; this primarily includes the number of video threads and the thread length.
If a video stream using video redundancy encoding is opened, each individual thread may but need not be carried in a separate logical channel:
•	All threads may be carried within a single RTP session using a single destination transport address.  In this case, only a single logical channel is opened that is used to carry all threads.  This approach should be followed, if no distinct QoS can be achieved for different threads.
•	Single threads or groups of threads may be associated with different RTP sessions which implies the use of different logical channels.  This approach shall be followed if service ”guarantees” are supported by the network infrastructure.
If multiple logical channels are used, they are distinguished into a primary and a set of one or more secondary logical channels.  The primary channel is the one opened first; all secondary logical channels reference the first one to enable bundling them.
All logical channels belonging to a redundancy encoded video stream shall be opened and closed atomically.  The sender shall not transmit any video information before the setup of all bundled logical channels is complete, and it shall stop transmitting immediately as soon as the first logical channel of a bundle is closed.

4	ASN.1 Extensions
The following extensions are required to allow use of the video redundancy encoding scheme in H.245: additional capabilities specific to the video redundancy encoding method need to be advertised by the involved systems and logical channels need to be opened with the appropriate parameters in place.

-- H.225.0 capabilities

H2250Capability	::=SEQUENCE{	maximumAudioDelayJitter	INTEGER(0..1023),	-- units in milliseconds	receiveMultipointCapability	MultipointCapability,	transmitMultipointCapability	MultipointCapability,	receiveAndTransmitMultipointCapability	MultipointCapability,
	mcCapability	SEQUENCE
	{
		centralizedConferenceMC	BOOLEAN,
		decentralizedConferenceMC	BOOLEAN,
		...
	},
	rtcpVideoControlCapability	BOOLEAN,	-- FIR and NACK
	mediaPacketizationCapability	MediaPacketizationCapability,
	...,
	transportCapability	TransportCapability OPTIONAL,
	redundancyEncodingCapability	SEQUENCE OF RedundancyEncodingCapability OPTIONAL,
	logicalChannelSwitchingCapability	BOOLEAN

}

RedundancyEncodingCapability	::=SEQUENCE
{
	redundancyEncodingMethod	RedundancyEncodingMethod,
	primaryEncoding	CapabilityTableEntryNumber,
	secondaryEncoding	SEQUENCE OF CapabilityTableEntryNumber  OPTIONAL,
	…
}

RedundancyEncodingMethod	::=CHOICE
{
	nonStandard	NonStandardParameter,
	rtpAudioRedundancyEncoding	NULL,
	…,
	rtp-H263-VideoRedundancyEncoding	RTP-H263-VideoRedundancyEncoding
}

RTP-H263-VideoRedundancyEncoding	::= SEQUENCE
{
	numberOfThreads	INTEGER (1..16),
	framesBetweenSyncPoints	INTEGER (1.256),
	frameToThreadMapping	CHOICE
	{
			round-robin	NULL,
			custom	SEQUENCE OF
				RTP-H263-VideoRedundancyFrameMapping,
-- empty SEQUENCE for capability negotiation
-- meaningful contents only OpenLogicalChannel
			...
	}
	containedThreads	SEQUENCE OF INTEGER (0..15) OPTIONAL,
				-- only used for opening of logical channels
	...
}

RTP-H263-VideoRedundancyFrameMapping	::= SEQUENCE
{
	threadNumber	INTEGER (0..15),
	frameSequence	SEQUENCE OF INTEGER (0..255),
}
-- for OpenLogicalChannel

OpenLogicalChannel	::=SEQUENCE{	forwardLogicalChannelNumber	LogicalChannelNumber,	forwardLogicalChannelParameters	SEQUENCE	{		portNumber	INTEGER (0..65535) OPTIONAL,		dataType	DataType,
		multiplexParameters	CHOICE
		{
			h222LogicalChannelParameters	H222LogicalChannelParameters,
			h223LogicalChannelParameters	H223LogicalChannelParameters,
			v76LogicalChannelParameters	V76LogicalChannelParameters,
			...,
			h2250LogicalChannelParameters	H2250LogicalChannelParameters,
			h223AnnexALogicalChannelParameters H223AnnexALogicalChannelParameters,
			none	NULL  -- for use with Separate Stack when
				  -- multiplexParameters are not required
				  -- or appropriate

		},
		...,
		forwardLogicalChannelDependency	LogicalChannelNumber OPTIONAL
			-- also used to refer to the primary logical channel when using video redundancy coding	},	-- Used to specify the reverse channel for bi-directional open request

	reverseLogicalChannelParameters	SEQUENCE
	{
		dataType	DataType,
		multiplexParameters	CHOICE
		{
			-- H.222 parameters are never present in reverse direction
			h223LogicalChannelParameters	H223LogicalChannelParameters,
			v76LogicalChannelParameters	V76LogicalChannelParameters,
			...,
			h2250LogicalChannelParameters H2250LogicalChannelParameters,
			h223AnnexALogicalChannelParameters H223AnnexALogicalChannelParameters

		} OPTIONAL,	-- Not present for H.222
		...,
		reverseLogicalChannelDependency	LogicalChannelNumber OPTIONAL
			-- also used to refer to the primary logical channel when using video redundancy coding

	} OPTIONAL,	-- Not present for uni-directional channel request
	...,
	separateStack	NetworkAccessParameters OPTIONAL,
				-- for Open responder to establish the stack
	mediaKeys      	SEQUENCE SIZE (1..16) OF EncryptionKey OPTIONAL
					-- used only by Master
}

H2250LogicalChannelParameters	::=SEQUENCE
{
	nonStandard	SEQUENCE OF NonStandardParameter OPTIONAL,
	sessionID	INTEGER(0..255),
	associatedSessionID	INTEGER(1..255) OPTIONAL,
	mediaChannel	TransportAddress OPTIONAL,
	mediaGuaranteedDelivery	BOOLEAN OPTIONAL,
	mediaControlChannel	TransportAddress OPTIONAL,  -- reverse RTCP channel
	mediaControlGuaranteedDelivery	BOOLEAN OPTIONAL,
	silenceSuppression	BOOLEAN OPTIONAL,
	destination	TerminalLabel OPTIONAL,
	
	dynamicRTPPayloadType	INTEGER(96..127) OPTIONAL,
	mediaPacketization	CHOICE
	{
		h261aVideoPacketization	NULL,
		...
	} OPTIONAL,
	...,
	transportCapability	TransportCapability OPTIONAL,
	redundancyEncoding	RedundancyEncoding OPTIONAL

}

RedundancyEncoding	::=SEQUENCE
{
	redundancyEncodingMethod	RedundancyEncodingMethod,
	secondaryEncoding	DataType OPTIONAL,	-- depends on method
	…
}

-- communication mode description

H2250ModeParameters	::=SEQUENCE{	redundancyEncodingMode	RedundancyEncodingMode OPTIONAL,	…}RedundancyEncodingMode	::=SEQUENCE{	redundancyEncodingMethod	RedundancyEncodingMethod,	secondaryEncoding	CHOICE
	{
		nonStandard	NonStandardParameter,
		audioData	AudioMode,
		…
	} OPTIONAL,
	…
}

-- Comminication Mode
CommunicationModeTableEntry	::=SEQUENCE{	nonStandard	SEQUENCE OF NonStandardParameter OPTIONAL,	sessionID	INTEGER(1..255),
	associatedSessionID	INTEGER(1..255) OPTIONAL,

	terminalLabel	TerminalLabel OPTIONAL, -- if not present, it refers
					-- to all participants 
					-- in the conference
	sessionDescription	BMPString (SIZE(1..128)) ,
				  -- Basic ISO/IEC 10646-1 (Unicode) 
	dataType	CHOICE
	{
		videoData	VideoCapability,
		audioData	AudioCapability,
		data	DataApplicationCapability,
		...
	},
	mediaChannel	TransportAddress OPTIONAL,
	mediaGuaranteedDelivery	BOOLEAN OPTIONAL,
	mediaControlChannel	TransportAddress OPTIONAL,  -- reverse RTCP chan
	mediaControlGuaranteedDelivery	BOOLEAN OPTIONAL,
	...,
	redundancyEncoding	RedundancyEncoding OPTIONAL,
	sessionDependency	SessionID OPTIONAL

}

5	Semantics for Video Redundancy Encoding to be added to H.245 
The following paragraphs propose replacement text for H.245:

redundancyEncodingCapability indicates which redundancy encoding modes are supported (if any).  For each capability entry, the redundancyEncodingMethod specifies the type of encoding to be used; the primary encoding; and which secondary encodings are supported for this primary encoding.  The choice of encoding schemes depends on the mode selected. rtpAudioRedundancyEncoding refers to the audio redundancy encoding; if this mode is the selected redundancyEncodingMethod, only CapabilityEntryNumbers referring to audio encodings are valid.  rtpH263VideoRedundancyEncoding indicates that video redundancy coding (VRC) according to H.263+ Annex N is possible or that a logical channel shall be opened using VRC.  Additional parameters are provided as follows: 
•	numberOfThreads indicates the maximum number of the threads the sender/receiver is able to support when used during capability exchange; contains the actual number of threads for a specific stream when opening a logical channel
•	framesBetweenSyncPoints defines the maximum number of video frames that may be transmitted (summed across all threads) between two synchronization points of all threads during capability exchange; defines the actual number of frames for a specific stream for OpenLogicalChannel
•	frameToThreadMapping defines which modes are supported by a sender / receiver during capability exchange and which mode is to be used when opening a logical channel: ”round-robin” indicates that frames are assigned in a round robin fashion to the threads, with the first frame after a synchronization point being assigned to thread 0, the second to thread 1, an so forth.  The ”custom” format allows to specify arbitrary mappings of frames to threads; during caps exchange, support for custom format is indicated by choosing this component and encoding an arbitrary (possibly empty) SEQUENCE.  Support for custom formats implies support for round-robin mappings.
•	containedThreads applies only to commands that open logical channels: this parameter then indicates which of the threads are transmitted in logical channel to be opened.  A logical channel may contain any number of 1 through 15 threads, however, two logical channels shall not specify to contain the same thread.
In case of rtpH263VideoRedundancyEncoding, the secondaryEncoding parameter shall not be present; this also applies to the H2250ModeParameters and the RedundancyEncoding ASN.1 structures of H.245.
When a logical channel for VRC is opened, the logical channel containing thread 0 shall be opened first, and this logical channel shall be referenced by all other logical channels by means of the forwardLogicalChannelDependency parameter in the OpenLogicalChannel command.