Dear SG16 Colleagues,
I read Dave Lindbergh's comments and found them important in order to
go on with a solution for FECC. Following are my remarks to the points
below.
1. I agree with this point.
2. I want to mention that if we are going to use one TCP connection
for multiple calls ( See Lucent's APC) than there may be a problem
with real time in the H.245 channel. Like my APC mentioned I think
that both ways will work.
3. If a UDP channel is the solution than we can use the open logical
channel ack message to send the FECC capabilities (see APC-1366).
4. In a multipoint environment using a UDP solution we can open this
channel directly between the end points that want to have an FECC
session. The exception will be in centralised conferences or
centralised video conferences. We can add a "chair control" service
requiring the end point who wants to start an FECC session to ask
permission from the active MC.
5. OK
6. There was an APC from IBM for h.281 in the past addressing this
issue.
7. I agree that ACKs is not needed.
If a UDP solution is what we are going to do, does it mean that we
need a new h.xxx.
Roni Even
Accord Video Telecommunication.
______________________________ Reply Separator _________________________________
Subject: Far-end camera control for H.323
Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet
Date: 4/15/98 2:58 AM
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(a)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
-------------------------------------------------------------------
