Annex L Conference Call Minutes

[Dave Walker]

Here are the minutes to the conference call that was held on
Wednesday to discuss the H.323 Annex L stimulus protocol.
My sincere thanks to all who participated!


Attendees:

Francois Audet, Orit Levin, Bob Gilman, Markku Korpi, Bob Callaghan,
Vineet Kumar, Dave Walker

1. Positioning Annex L

- H.450 should be described by what it can do, rather than what it
  can't do (as I did in the annotated agenda I sent out on Monday).
  It's main goal is networking interoperability, not providing all
  features required for PBX replacement.

- H.323 provides some support for what are considered as supplementary
  services, such as identification services, call transfers, etc.
  It should be noted that use of Annex L may require that some
  "native" features, such as call id, may have undesirable
  interactions with the stimulus control and might have to be disabled.
  H.323 provides the basic call mechanism that is used by Annex L.

- An extensive discussion of positioning with H.248 took place.

  It was suggested that the choice of H.248 or Annex L for features
  would be influenced by the implementation's point of departure.
  Gateway based implementations may have a preference for H.248,
  whereas Gatekeeper based implementations have a natural preference
  for Annex L.  A prime goal is to keep H.248 line side packages and
  Annex L functionally similar.

  H.248 based endpoints tend to be unaware of call state.  There was
  dissent among participants as to whether Annex L endpoints would be
  call state aware.  H.323 currently allows a call to be established
  and used, as and when required, for multiple media connections.
  This permits an endpoint to initiate a call, signalling only, and
  to maintain it essentially forever; Annex L could be used to provide
  all other control.  Analogies to existing systems can be made, however
  it was suggested that although H.323 may allow this, it is not
  necessarily desirable, especially from the point of interoperability.
  It was pointed out that endpoints which depend almost entirely on
  Annex L would need to be able to at least re-direct incoming Setup
  messages to their Gatekeeper in order to approach H.323 compliance.

  It was suggested that this issue be entirely removed from Annex L.
  While there was some concern that this would lead to implementation
  difficulty, the consensus seemed to support removal.

- It was emphasized that we should strive for as much commonality
  with H.248 line side as possible.  A highly desirable solution
  would be to simply reference the appropriate packages and specify
  the encoding mechanism to be used for H.323 stimulus.  This would
  ensure future alignment.

- It was agreed that H.323 Annex K is not intended to provide device
  control, its role is orthogonal to Annex L.  WML transport can be
  provided by the generic tunnelling mechanism being developed for
  QSIG (H.323 Annex M).

2. Requirements

- Everyone agreed that Unicode is needed.  The issue is that both ends
  must realize that Unicode is being used.  I suggested that support
  could be declared/configured using the management part of Annex L.
  An alternative is to use an escape code (0xff was suggested), which
  would indicate that the IE contains Unicode.  This might require that
  we choose a flavour of Unicode - UTF-8 seems to be wildly popular.

  This discussion evolved into a discussion of the extensive use of
  "antique" ANSI escape sequences in the draft.

- It was agreed that the level of complexity in the screen control
  section (3.1.1) of the draft was excessive.  Endpoints which are
  capable of such sophistication should be capable of supporting some
  other protocol for display management.  I suggested that only
  cursor positioning and erase capabilities were really required.
  This had some support until it was suggested that bandwidth is not
  at so much of a premium as in days of yore, so that a Gatekeeper
  requiring full control over a screen could simply re-write the
  entire display whenever it needed.  This would require that Annex
  L point out that a Display IE always rewrites the entire screen.
  As Display IE is limited to 80 octets, which could be far fewer
  than 80 display characters depending on the flavour of Unicode,
  there may have to be some sort of continuation indicator.

- The understandable preference for not being required to parse the
  entire Display IE was expressed.  This led to a discussion of how
  other usages of Display in the current draft could be addressed.
  Specifically, how to control indicators.

- Since the issue of adding support for (Q.932) Feature Activation
  and Feature Indication Information Elements was on the table, it
  was agreed that using FI to control indicators would be a cleaner
  solution that Display.  However, a possible problem with this
  approach is that FA and FI are not supported in any version of
  H.225.0, so backwards compatibility would be compromised.  There
  is a paragraph in H.225.0 which may allow earlier version EPs to
  use these IEs, but it is unclear.  The paragraph, found in section
  7.1, "Use of Q.931", states that "EPs may interpret and generate
  optional IEs defined below", but "also may interpret other IEs
  of ... other Q-series ... protocols".  So interestingly, the word
  "generate" is missing from the second statement, so that EPs may
  not be permitted to generate FA and FI IEs, even if they are allowed
  to interpret them.  On the other hand, the recommendation doesn't
  explicitly state that they may not be generated.  Furthermore, it
  is unknown whether popular H.323 stacks support this.

- The point was made that if we decide to pick up FA and FI, that
  it will not be sufficient to simply reference Q.932, rather Annex
  L will have to explicitly describe how and what these IEs are used
  for.

  In addition, the extent to which Annex L should explicitly list
  FA Feature Ids was uncertain, as was any view on re-using Ids already
  defined by other ITU recommendations.  It was suggested that
  predefining a few could help ensure some degree of interoperability.
  This is the approach that has been followed for other encodings in
  Annex L, where a set of predefined elements is provided along with a
  mechanism for configuring nonstandard extensions.

- FA/FI could be useful for replacing most, if not all, of the escape
  sequence mechanisms introduced into the Display and Keypad IEs.
  However, whether FI could be used to replace the currently suggested
  use of the Signal IE was not discussed.  A Feature Id could be assigned
  to particular tone patterns, with the status value in the FI indicating
  whether the tone should be started or stopped.

3. Plans

- We have to verify whether FA/FI are usable.  This is certainly a
  way forward.  I propose that minimal usage of Display and Keypad
  be maintained as an option, but significantly stripped down as
  described above.  Allowing FA/FI has implications to the management
  part of the protocol.
- The draft needs one or two usage examples illustrating how the
  procedures may be used.
- Minimal requirements need to be defined.  Optional functionality
  needs to be clearly described.  There may be different levels of
  conformance:  e.g. FA/FI, keypad/display, etc.  Unless very carefully
  done, this will make it very difficult to ensure interoperability.