SUD white paper

[Chris Purvis]

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 at madge.com