H.323 gatekeeper problems

Chia-Ming Tu bluejays at III.ORG.TW
Tue Nov 25 20:57:26 EST 1997


At 09:11 AM 11/25/97 -0800, Toby Nixon wrote:
>I think I've stated my position on the reflector regarding V.chat/T.chat --
>that it is clearly a "data" application, and it ought to be a T.120 app and
>not ride directly on a logical channel or be in H.245 (at least in the
>context of H.323).

I tend to agree, except that so many people felt that T.120 is
such a "burden" that it seemed that few would implment V.CHAT
if it required T.120.  That was the motiviation to allow it to
be used without T.120, in a point-to-point mode.

>I don't think I feel that way about camera control; it
>just seems so closely tied to the video media stream, and not really "data".
>It strikes me as more like chair/floor control than like chat.
>
>When would you ever have multipoint camera control -- I mean, wanting to
>send camera commands to multiple endpoints simultaneously? I know you'd want
>to be able to separately control multiple cameras.

You'd use multipoint camera control anytime you are in a multipoint
call and want to control the camera on a _particular_ far-end machine.
This requires addressing of camera commands, and probably arbitration
and locking if more than one person tries to control the same camera.

This could be done in H.245, but that would require the MC/MCU to
both support the new H.245 messages (an upgrade) and do some message
routing and arbitration to make it work.  This is adding new functionality
to the MC/MCU H.245 stack, when these functions are already in the
T.120 infrastructure.  So it seems simpler to just use T.120 when
mutlipoint function is need.  Since T.120 is considererd "a burden"
by some, and isn't needed for point-to-point, we can just run the
same protocol by itself in a H.245 LC (ala V.CHAT).  Keeping the
core protocol separate from H.245 allows the SAME protocol to be
used both point-to-point (in a H.245 LC) and multipoint (in T.120).
If we put it in H.245 directly, we'd end up with two sets of syntax
to keep sychnronized in ITU-T, one in H.245 and another in T.120.

>Anyway, I think we can break the camera control out of T.130 and make it a
>separate recommendation, and carry the PDU stream on a separate TCP
>connection negotiated using H.245. Basically, parallel what was done for
>H.224. Should it go through the MC, or directly to the controlled endpoint?

For point-to-point I'm not sure.  For multipoint, it would go in
T.120 to the T.120 peer (probably the MC).

>In Sunriver, didn't we officially move T.130 from Q3 to Q14? That would seem
>to argue for presenting this to Q14 instead.
>
>Would we want all of the remote device control stuff, including speaker
>volume, microphone gain and mute, etc.?

I would think so.

>
>Do you want to move this discussion back out into public view and get input
>from others?

I'm cc:ing this to the H.323 list.

--Dave L.


>
>       -- Toby
>
>> -----Original Message-----
>> From:        Dave Lindbergh [SMTP:lindbergh at itu.ch]
>> Sent:        Monday, November 24, 1997 4:26 PM
>> To:  Toby Nixon
>> Cc:  duckworthm at pictel.com
>> Subject:     RE: Inconsistent references to H.281
>>
>> Toby,
>>
>> At 02:37 PM 11/24/97 -0800, you wrote:
>> >I'd be interested in working with you on this. Do we need some sort of
>> >proposal for a work item at the next SG 16 meeting? Or just bring in a
>> first
>> >draft? I think this would go into Q14; do you agree?
>>
>> You could bring in a draft, but it would probably be better to
>> start with a general discussion in the group to see if there's
>> consensus on this direction, before a lot of work goes into it.
>> Maybe that will happen on the reflector.
>>
>> I think we'd be interested in working with you on it.
>>
>> We were thinking about putting in a contribution into the Q3 meeting
>> in Geneva, since we thought it belonged in the Q3 group more than
>> in Q14.  You could argue either way, I've no strong preference.
>>
>> >What's the compelling reason for opening a separate logical channel for
>> >camera control instead of just issuing the commands directly in H.245?
>>
>> The main reasons are (a) keep down the clutter in H.245 (already bad),
>> and (b) make it easier to have a T.120 "wrapper" around the RDC
>> stuff for multipoint use.  We'd like to see a solution that doesn't
>> require upgrading all the MCUs and gateways every time we add a new
>> terminal feature; T.120 does this nicely for multipoint (there is no issue
>> for point-to-point).  This is the same path ITU took for V.CHAT/T.CHAT,
>> it seems like a good model for this, too.
>>
>> What do you think?  Mark Duckworth here at PCTL has been looking
>> at this from the Q3 viewpoint, I'm cc:ing him on this.
>>
>> --Dave L.
>>
>>
>>
>> >
>> >> -----Original Message-----
>> >> From:     Dave Lindbergh [SMTP:lindbergh at ITU.CH]
>> >> Sent:     Sunday, November 23, 1997 3:22 PM
>> >> To:       ITU-SG16 at MAILBAG.INTEL.COM
>> >> Subject:  Re: Inconsistent references to H.281
>> >>
>> >> Toby/all,
>> >>
>> >> The H.224 codepoint in DataApplicationCapability.application.h224 of
>> >> H.245 was put there for use with H.324; you can use H.224/H.281
>> >> to do far-end camera control in H.324.  (H.224 itself negotiates
>> >> the use of H.281; that's why you don't see H.281 in H.245.)
>> >>
>> >> My feeling (and I think this has been the view of the group
>> >> as a whole) is that H.224/H.281 won't work for H.323.  The H.281
>> >> control model is timing based: You send a message to start moving
>> >> the camera (presumably at some slow, fixed rate), then another
>> >> to stop it.  Even with H.320 or H.324, this requires the user to
>> >> "lead" the camera to compensate for end-to-end round trip delay.
>> >>
>> >> With H.323, any inconsistency in packet delivery times will make
>> >> it impossible for the user to predictably control the camera.  This
>> >> could be partially fixed by adding timestamps to the messages, but
>> >> only at the expense of buffering for the worst-case packet delivery
>> >> time.
>> >>
>> >> I think the RDC portion of T.130 is a much better approach: It is
>> >> not timing based, but based on absolute positioning of the camera
>> >> ("turn left 24 degrees").
>> >>
>> >> Since T.130 is stalled, I suggest we think about extracting the
>> >> RDC portion of T.130 (clearly needed for H.323) and approving it
>> >> as a separate Recommendation (not necessarily using T.120).  We
>> >> could follow much the same approach as with V.CHAT/T.CHAT: A simple
>> >> stand-alone protocol (the RDC ASN.1 structures from T.130) which
>> >> can be used point-to-point in a H.245 LC, and a multipoint version
>> >> that makes use of a T.120 "wrapper" (ala T.CHAT) around the same
>> >> simple protocol.
>> >>
>> >> --Dave Lindbergh
>> >>
>> >>
>> >>
>> >> At 03:01 PM 11/21/97 -0800, you wrote:
>> >> >We were poking around a bit for information on far-end camera control,
>> >> and
>> >> >ended up searching for references to H.281 in most of the documents
>> being
>> >> >decided in January. As a result, we uncovered some inconsistencies
>> that
>> >> may
>> >> >require editorial correction of the decided texts of H.245, H.246, and
>> >> >H.323.
>> >> >
>> >> >(1) H.245 section 2 refers to 1996 versions of H.281 and H.224. We can
>> >> find
>> >> >only versions published in 1994. However, I note that although H.224
>> and
>> >> >H.281 are listed as references, they are not actually referenced in
>> the
>> >> text
>> >> >of H.245 anywhere, either by name or by the reference number.  Either
>> >> these
>> >> >references should be deleted from section 2, or the dates changed to
>> >> >"(1994)".
>> >> >
>> >> >(2) H.246 refers to H.281 and H.224 in section A.9, but they are not
>> >> >included in the references in section 2. The solution here could be to
>> >> >simply remove section A.9, since it is "for further study"; if this is
>> >> not
>> >> >done, H.281 and H.224 should be added to section 2.
>> >> >
>> >> >(3) H.323 version 2 refers to H.281 and H.224 in section 6.2.7, but
>> >> neither
>> >> >of these are included in the references in section 2. H.281 and H.224
>> >> should
>> >> >be added to section 2. Note that H.323 version 1 had the same problem.
>> >> >
>> >> >The reference in H.323 and the presence of
>> >> >DataApplicationCapability.application.h224 in H.245 seem to imply that
>> >> >H.281/H.224 can be used in H.323 terminals. It would seem fairly
>> >> >straight-forward to open a camera control data logical channel
>> associated
>> >> >with a video channel and send H.281 commands. Does anybody actually do
>> >> that
>> >> >today? Has it even been prototyped? Have details been worked out, such
>> as
>> >> >whether it would be a TCP or UDP connection? Or was this intentionally
>> >> >postponed while T.130 work proceeded? If that's the case, should it be
>> >> >resurrected considering the state of T.130? Is H.281 simply considered
>> >> not
>> >> >suitable for use on IP/Internet (due to latencies)? If so, is there
>> >> desire
>> >> >to work out H.245 extensions to do the same things?  I'm sure you've
>> all
>> >> >discussed this before I was around; sorry.
>> >> >
>> >> >        -- Toby
>> >> >___________________________________________________________
>> >> >Toby Nixon, Program Manager - NetMeeting
>> >> >http://www.microsoft.com/netmeeting
>> >> >Microsoft Corporation, Applications and Internet Client Group, Redmond
>> >> WA
>> >> >USA
>> >> >+1 (425) 936-2792     Fax: +1 (425) 936-7329
>> >> mailto:tnixon at microsoft.com
>> >> >
>> >> -------------------------------------------------------------------
>> >> Dave Lindbergh                       Email: lindbergh at pictel.com
>> >> Manager, Technical Standards Group   Voice: +1 978 623 4351
>> >> PictureTel Corporation               Fax:   +1 978 749 2804
>> >> 100 Minuteman Road - M/S 635         H.320: +1 978 437 0265 (twice)
>> >> Andover MA 01810  USA                http://standards.pictel.com
>> >> PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
>> >> -------------------------------------------------------------------
>> >
>> -------------------------------------------------------------------
>> Dave Lindbergh                       Email: lindbergh at pictel.com
>> Manager, Technical Standards Group   Voice: +1 978 623 4351
>> PictureTel Corporation               Fax:   +1 978 749 2804
>> 100 Minuteman Road - M/S 635         H.320: +1 978 437 0265 (twice)
>> Andover MA 01810  USA                http://standards.pictel.com
>> PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
>> -------------------------------------------------------------------
>
-------------------------------------------------------------------
Dave Lindbergh                       Email: lindbergh at pictel.com
Manager, Technical Standards Group   Voice: +1 978 623 4351
PictureTel Corporation               Fax:   +1 978 749 2804
100 Minuteman Road - M/S 635         H.320: +1 978 437 0265 (twice)
Andover MA 01810  USA                http://standards.pictel.com
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