[Robustess] D.225 from Chile

[Orit Levin]

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).