Here are some suggestions for discussion.
Should this work be done in Q14, with input from Q3?
Is there general acceptance of the PictureTel proposal given below? Comments on the 6 goals listed below? Comments on the 8 points of the proposal listed below?
If there is time and interest, here are some more technical issues we could discuss:
We know some H.RDC commands (from H.281) need timestamps, and some need a retransmission mechanism for reliability. Should these mechanisms apply at the H.224 level, so all H.224 clients are affected, or should it be done at the H.RDC level?
Should we use RTP? Should the stack look like this: IP / UDP / RTP / H.224 / H.RDC ?
Should we use one UDP port for all H.224 clients, or a separate port for each client?
Should we use the H.224 packet format, using Q.922, as specified in H.224? Or should we simplify it for H.323 and require gateways to translate? Should we try to combine RTP and H.224 into one layer?
What are the anti-spoofing issues? Can H.224 packets be validated in the same manner as audio or video packets?
============================================================
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@pictel.com