PictureTel Proposal for H.323 Remote Device Control

Mark Duckworth Mark_Duckworth at pictel.com
Fri May 15 09:09:31 EDT 1998


Michele,

Correct, T.RDC is a draft that has not been determined.  The editor is
Andrew Woollett from ImageCom Limited.  I couldn't find the draft at the
Q3/16 T120 ftp site.  I think it belongs at
ftp://ftp.imtc-files.org/imtc-site/T120-top/t120_ky98/TRDCreva.zip.

Andrew, can you please upload the document to the ftp site?

Michele, I will send you my copy in a separate email.

Mark





mbozier at dev.madge.com on 05/15/98 04:28:04 AM

To:   Mark Duckworth/PicTel
cc:
Subject:  RE: PictureTel Proposal for H.323 Remote Device Control




Mark,
Sorry to trouble you, but in the discussions on H.323 RDC there has been a
lot of reference to T.RDC.  Not having been involved with T.120 up until
now, could you tell me where I could find a copy of T.RDC.  I presume that
the status of this document is that it is a draft that is not yet
determined
text.
Thanks,
Michele Bozier
----------------------------------------
Michele Bozier
Principal Development Engineer
Madge Networks, Wexham Springs, Framewood Rd, Wexham,
Slough SL3 6PJ, England
Tel: +44(0)1753 661331  Fax: +44(0)1753 661011
email:mbozier at madge.com

-----Original Message-----
From: Mark Duckworth [mailto:Mark_Duckworth at pictel.com]
Sent: Friday, May 08, 1998 7:51 PM
To: ITU-SG16 at mailbag.jf.intel.com
Subject: PictureTel Proposal for H.323 Remote Device Control

This is a summary of the PictureTel proposal for Remote Device Control for
H.323, which we discussed in the Q3/Q14 audio conference held on May 7.
The Goals:
1) Provide FECC for H.323 conferences.
2) Interoperate with H.320 and H.324 systems with H.281 through gateways.
3) Simple to implement for basic FECC model using H.281 compatible
messages.  Additional features should be optional.
4) Use a common protocol for point-to-point and multipoint conferences.
5) Add optional support for new camera control mechanisms and for control
of other types of devices, such as in T.RDC.
6) Make it extensible for new standard and non-standard features.
The Proposal:
1) Start by encapsulating the whole H.224/H.281 stack within UDP, in an
H.245 logical channel.
2) Add timestamps to real-time (start/continue/stop) messages, somehow (RTP
or other).  Receivers can use this to compensate for jitter in the network.
Receivers free to ignore these.
3) Add functions from T.RDC into H.281 as optional extensions.  Probably we
will want to modify these a little, for instance to support positioning
units based on field of view.  One possibility is to define a new H.281
command code which indicates the rest of the PDU is an ASN.1 coded message,
and use the ASN.1 taken from T.RDC.
4) For non-real-time commands (all except start/continue/stop), add a
simple retransmission mechanism (just numbered messages and numbered ACKs)
to supply reliable (if inefficient) transport on top of UDP.  We can crib
this from existing standards, such as NSRP from Annex A/H.324.
5) Define the functions of an H.224 router to reside in an MC or MCU.  This
would mostly be to manage flow control (or not) as does the H.320 LSD
channel, rebroadcast info, route info, etc.  This might also include
caching capsets.
6) Make sure addressing and scope issues are synchronized with H.245 (use
M/T addressing probably).
7) Break out the capability exchange function of H.224 into a new H.245
(and therefore TCP) generic cap exchange function that doesn't require the
H.245 engine to recognize the contents of the caps, but merely to pass them
along (as does H.224 capex).  These "non collapsing capabilities" will map
1:1 at the gateway to the existing H.224 cap exchange.
8) In future, add T.124-like capability collapsing (AND, OR, etc.) to
H.245.  Details need work, but we'd like to support multicast and large
conferences.  This is not immediately useful for RDC, but would supply a
generic extended H.224 stack that would provide for future simple control
protocols without requiring upgrades to deployed infrastructure equipment
such as MCs, MCUs, and gateways.

Mark Duckworth
PictureTel
duckworthm at pictel.com

Original Recipient: MBOZIER.DVSEMAIL @ MADGE








More information about the sg16-avd mailing list