Far-end camera control for H.323

Kumar, Vineet vineet.kumar at INTEL.COM
Wed Apr 15 12:37:00 EDT 1998


I agree that Acks are not needed and we should not try to over-engineer.
But there needs to be a mechanism so that the user can stop the camera
motion within a reasonable time after issuing STOP. This can be
accomplished by having the receiver (one with the camera) look-ahead for
STOP messages in its receive buffer. When it sees the STOP message it
should ignore any CONTINUE messsages in its buffer which are ahead of the
STOP.

What I have described above is not something to be standarized but we could
include it as a guidance to the implementors.

vineet
______________________________ Reply Separator
_________________________________
Subject: Far-end camera control for H.323
Author:  Dave Lindbergh [SMTP:lindbergh at itu.ch]  at MSXGATE
Date:    4/14/98 11:58 PM


Dear SG16 colleagues,

Just to repeat and amplify our Yokosuka comments on APC-1356
(Intel) and APC-1366 (Accord) regarding Far End Camera Control
(FECC) for H.323:

In general, PictureTel supports the idea of basing H.323 FECC
on H.281.  We think the following points are important:

1) A general goal should be that H.323 FECC should be interoperable
   via a gateway with H.281-based FECC on H.320 systems (note that
   H.324 also uses H.281 FECC)

2) H.281 should be sent over UDP as a separate media stream, and
   not over TCP (such as H.245).  We believe that H.281 must be
   transported using techniques suitable for a media stream, thus
   preserving the real-time relationships between control activation,
   hold, and deactivation which are represented by the H.281 Start,
   Continue, and Stop messages.

3) Any solution must address capability exchange including which
   endpoints have controllable cameras, how many cameras, what
   controls are available (pan, tilt, zoom, focus, etc.), preset
   positions available, etc.  The existing H.281 system uses H.224
   for capability exchanges of this sort.  One solution would be
   to perform a similar function using H.245 cap exchange.  Another
   would be to simply encapsulate the entire H.224/H.281 stack within
   a UDP media stream (this would simplify gateways).

4) Any solution must address multipoint use.  One possibility is
   to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281
   UDP encapsulation for point-to-point use, and a very simple
   T.120 "wrapper" around H.281 for multipoint use.  Note that
   the T.120 could reside either in endpoints or be proxied from
   the point-to-point mode at the MC.

5) To improve reliability on congested networks, rather than using
   TCP, redundant transmission of H.281 messages via UDP might be
   used.

6) To support future applications such as machine-driven pointing
   and operation on highly congested networks, the H.281 message
   set should be extended to add new absolute and/or relative
   positioning commands (probably in units of field of view rather
   than angular units).  Long-term, a migration to these new commands
   could occur, while retaining compatibility with the existing H.281
   start/stop motion model.

7) We are unsure how adding ACKs to Start/Continue/Stop messages
   (as suggested by Intel) is helpful.

--Dave Lindbergh, PictureTel


-------------------------------------------------------------------
Dave Lindbergh                       Email: lindbergh at pictel.com
PictureTel Corporation               Voice: +1 978 623 4351
100 Minuteman Road - M/S 635         Fax:   +1 978 749 2804
Andover MA 01810  USA                H.320 video by arrangement
PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
-------------------------------------------------------------------



More information about the sg16-avd mailing list