Here are the details and the agenda for this Wednesday's conference call on H.323 Annex L. I've provided some initial thoughts on the agenda items.

----------------------------------------------------------

Call Details ------------

date - 15 December 1999 (Wednesday) time - 11:00 EST phone - 1 800 267 6244 (North America only, sorry) 1 613 592 2122 (international)

You'll reach the Mitel switchboard - ask them for Dave Walker's conference call!

----------------------------------------------------------

Agenda ------

1. introduction of participants

2. positioning Annex L in relation to other flavours of H.323 2.1. H.450 H.450 describes peer-to-peer functional signalling for a well-defined set of supplementary services. Interoperability of non-standard services is limited. Definition of new services is a lengthy process. 2.2. H.323 H.323 supports both peer-peer and limited client-server models with limited support for supplementary services. 2.3. H.248 H.248 is purely client-server typically without any knowledge of call signalling. There is no explicit linkage to H.323 although H.323 may be used transparently to the MG. Given support for appropriate pre-defined packages, it should be possible to attain interoperability of non-standard features. Entities supporting H.248 do not necessarily interwork with H.323 entities. 2.4. H.323 Annex K Annex K offers flexibility of services for EPs which support HTML/WML. Limited control over media streams is available except via nonstandard APIs. Annex L offers extended control opportunities to Annex K based systems. 2.5. H.323 Annex L Annex L enables the interoperability of non-standard features that is offered by H.248, while ensuring compatibility with existing H.323 networks. Annex L is designed to enable full flexibility of non-standard supplementary services to H.323 version 1 and version 2 EPs.

3. requirements 3.1. level of backwards compatibility Explicit support for Annex L is via the presence of suitably encoded nonStandardControl in H323-UU-PDU (note that I still want to rename this field to alternateControl). I insist that v1 and v2 EPs be able to participate in the control aspect of the protocol if they support Keypad and Display and provide some means to inject desired escape sequences. 3.2. IA5/Unicode Display and Keypad require IA5. The requirement for Unicode is undeniable. IA5 is the same as U+0000 to U+00FF. Display and Keypad coding shall be IA5 unless the recieving entity has previously indicated support for Unicode. Use of Unicode could be negociated (or configured), or each usage could be tagged. 3.3. graphics support Sophisticated support can come from HTML. Do we need anything else? I think simple support for a bit-mapped display could be easily added, do we need it? and what protocol should be used? 3.4. HTML/WML based My belief is that Annex K addresses this entirely. While it would be easy to to add "HTML" or something as a type of capability, I don't think it reasonable to attempt to transport these pages/decks via H.323 signalling. So the option seems to be to add a mechanism for sending URLs in Annex L. The only advantage this would seem to present is the use of fields that exist in v1 and forward. 3.5. FA and FI Adding Feature Activation and Feature Indication. These are defined in Q.932 as Feature Key protocol. As defined there, two new information elements would be required. Alternatively, the information otherwise provided by these IEs could be text-encoded in the Keypad and Display IEs.

4. architectural models This is kind of addressed by item 2 in the agenda. We need some diagrams illustrating this and also some presenting locations of Feature Server with respect to controlled EPs and other H.323 entities.

5. document restructure - All of the ASN.1 encoding should be moved to its own section. - Description of all of the fields is required (taking H.225.0 as an example).

6. enhancements/changes to existing protocol (APC-1660) 6.1. text based One issue is the limiting size of Keypad and Display. The ability to handle larger sizes is a capability that could be negoctiated. Another issue is whether management aspects should be text based or ASN.1 based (as presented in APC-1660). 6.2. graphics? 6.3. HTML/WML beyond Annex K?

7. work plan Needs a section describing the procedures, as well as a few examples including full signalling MSCs. Volunteers? We need a section that describes minimal functionality (one or two flavours of).