Joerg,

Many apologies for the delay in sending these comments. I've studied your contribution on Single Use Devices, and have a number of points and questions, both editorial and substantive:

Substantive: 1. How does a third party know whether a SUD with which it is communicating is conference-aware? Section 7.3.4.9 states that certain capabilities shall be assumed to be "TRUE/FALSE as appropriate, default FALSE", and I am not clear as to how someone communicating with it knows what to assume.

2. (Also in conferencing.) It is possible for an MCU to detect a need for the common mode of a conference to change (someone may join it without capability for the current common mode of the conference, while there is still an alternative common mode). Section 7.3.5 states that "Open Logical Channel messages outside the FastConnect procedure shall only be used to alter media transport parameters", which I take to exclude a change of audio mode, and in 7.7.2.3 CommunicationModeCommand is specifically given as optional (I understand it to be mandatory in "real" H.323, although I appreciate that not everybody understands it). How can I achieve a change of mode of a conference-aware SUD which is already in a conference? This will affect interoperability with real MCUs.

3. If the procedure described in section 7.6.1 (on third-party initiated pause and rerouting) is considered useful, maybe it should be added as an option for calls which have been fastConnected in full version 2 endpoints? I see it as yet another option that would need to be supported, but if it needs to be supported for SUDs we may as well support it in the standard for everybody. Using H.450.Hold is probably a better solution, but is harder work for the SUD.

4. A number of points in the paper give details of what to assume in cases where no capability exchange has happened. These can apply equally well to calls involving only "full" H.323 endpoints using fast connect procedures, and should be added to the main standard (probably initially through the implementer's guide). I refer in particular to sections 7.3.4.4-7.3.4.9.

5. Sections 7.1 and 7.2 both refer to the "sud" component of the H.225.0 EndpointType. I can not find this in H.225.0 version 2, which I understand to be the relevant version. I assume the purposes of this are a) to mandate a gatekeeper to route call signalling b) to inform the gatekeeper not to try to do real capset exchange.

6. Incidentally, you are mandating gatekeepers to route H.225.0 AND H.245 messaging (not many do the latter yet!), and to cope with routing a call from an endpoint which does not support faststart with one that does not support "traditional" H.245 procedures. This gives me an uncomfortable feeling, because the caller may, for example, not be able to give its capabilities until after Connect (yes, there ARE endpoints around that act like this), but the callee requires the information in Setup. Is the gatekeeper required to setup a whole call on one side (including starting billing, which is what "Connect" implies) before even ringing the phone on the other side? Or should it fall back on an assumption of G.711? Given the significant amount of work this requires from what are described as "SUD-aware gatekeepers", it may be useful to document the responsibilities of such an entity.

7. In section 7.3.2.7, I am not convinced about the interpretation of H.245 EndSession as call termination. As I understand it, it does not have that meaning to a "full" H.323 endpoint as long as the H.225 session is still up.

8. If I understand correctly what you're trying to say in the statement immediately before section 7.3.2.1, it is actually making two separate points that need to be stated explicitly, namely: a) If a SUD Audio terminal receives a tunnelled H.245 message it doesn't understand, it should ignore it and continue as if it had not received it (certainly not crash). b) Other devices attempting to interoperate with SUDs need to be aware that tunnelled H.245 messages not specifically mentioned in Annex F may be ignored, and need to be able to cope with this possibility without bad failure conditions occurring.

What is the reasoning behind ignoring these messages rather than returning "functionNotSupported" or "functionNotUnderstood"?

Editorial: 9. I find figure 1 less than helpful. It appears to me to be ambiguous and even misleading.

10. A few times "audion" appears in place of "audio".

Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com