Real Time Device Control

Thu Mar 26 06:13:01 EST 1998


please find below just a few comments on Gary's outline...
>Please remember that Q14 is supposed to be working on the low level Real Time Device Control (RDC)
>protocol/procedure for H.245 based systems.
>I encourage all interested parties to give this serious consideration, and submit proposals to the
>Yokosuka meeting.
>This is particularly important for those who object to using T.120 for RDC. At the Geneva meeting,
>much of this work was moved back into Q3, because there was no objection during the Joint Q3/Q14
>meeting. If we do not develop a proposal which takes into account the Q11-14 needs, they will move
>forward developing a T.120 based solution.
>To start the discussion:
>There are probably may approaches, some are:
>1) Run H.281 FECC over a UDP logical channel. With H.224, without H.224, or with some other low level
>protocol to assure delivery.

Hmm, "assuring" delivery sounds too strong to me.  This would contradict
the somewhat real-time nature of a FECC channel.  Also, H.224 looks quite
specific to ISDN but it does not really fit on top of packet sequences.

>2) Develope a more robust RDC protocol to run over a TCP/UDP logical channel.

What I would like to see here is a conceptual approach similar to what we
have done for chat applications: define an application protocol that can
be put on top of UDP (optionally plus some FEC-style+timestamp protocol)
as well as put into a T.120 MCS channel (an unreliable one, probably, which
still needs to be defined).

Also, please keep in mind that we are not supposed to address addressing
and routing individual endpoints at type of additional multiplex layer.
>3) Provide FECC like functions within H.245. (not a good idea).
Agreed.  Don't do that.
>4) Provide FECC like functions within T.120. (This was the approach before the RDC work was moved to
>Q14 last year.)
As stated above: this is probably a mandate for us -- but we only define
the semantics, the Q.3 people have to look into the transport via T.120
issues then.

>This work should be coordinated for use in H.323, H.324, H.310 systems which all use H.245 and
>logical channels.
Coordination SHOULD include the T.120 group as well.  We may have to define
a transport profile for each of these underlying networks if we do not
assume IP as a base everywhere.

Any comments?

More information about the sg16-avd mailing list