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.