Subject: [Megaco] Open Issues In the Advanced Audio Server Specification

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 19 Oct 2001 19:13:59 -0400

This is the content of my contribution on the subject to the forthcoming SG
16 Rapporteur's meeting.

Title	: Open Issues In H.248 Annex M.1, Advanced Audio Server Packages
Source*	: Editor
___________________

AVD-2119 contains the latest draft of H.248 Annex M.1, "Advanced Audio
Server Packages".   This draft contains numerous changes which bring it
close to completion.  However, two new issues have emerged since it was
submitted.  These are:
·	local variants in the enunciation of some variable types.  This is
also the subject of AVD-2171, which was submitted independently of the
present contribution.
·	use of selectors with standalone variables.
This contribution describes the issues and proposes some alternatives for
their solution.
 
1	Local Variants In Variable Enunciation
      ======================================

This topic arose in connection with the Digits variable type.  This type
enunciates a series of digits specified as input.  It already has local
characteristics, in that a "cadence" subtype is defined, and this currently
distinguishes between an undifferentiated stream of digits and a set of ten
digits spoken with the pauses appropriate to a directory number in the "1"
world numbering plan area.  The problem raised was that France has its own
distinct way of pronouncing directory numbers: as a sequence of five
two-digit numbers rather than a sequence of individual digits.  It is quite
possible other countries or regions have similar requirements for local
variants.

The Editor can see several possible ways to resolve this requirement:

1.	The simplest is to extend the current range of subtypes, adding
"ndfr" to meet French requirements.
 
2.	If explicit per-call control over enunciation is unnecessary, it is
possible to leave any implementation of local variants to provisioning (i.e.
the local variant used would be the same for all calls served by the same
Audio Server).  There is still a requirement in this case that a directory
number be distinguished from any other stream of digits, implying either an
additional variable type or a variable subtype.  The current "nadn" subtype
would be removed.

3.	One variant on the first solution would be to replace the "nadn"
subtype with a more general "telno" subtype and invoke a local variant
through a "locality" selector.  This has the virtue that it is a general
solution to the requirement of providing local variants for all variable
types, not just the Digits type.  See the next section on use of selectors
with standalone variables.

2	Use Of Selectors With Standalone Variables
      ==========================================

When the Advanced Audio Server packages were originally conceived, selectors
applied to an announcement specification as a whole.  For example, a single
language selector parameter would specify the language to be used for every
segment of a multi-segment announcement.
Moving selectors to the search part of the HTTP URL designating a
provisioned segment provided an elegant way to transmit this information to
a remote entity on which the segment might reside.  However, it means that
selectors now have to be specified segment by segment.  Moreover, no syntax
has been defined in AVD-2119 to apply selectors to standalone variables.
This last point is a clear requirement, without which the specification is
incomplete.

Again, the Editor sees several alternatives:

1.	Revert to specifying selectors for the announcement as a whole
rather than its individual parts.  Leave the syntax by which selector values
are conveyed to remote entities as an implementation detail, not to be
specified in the standard.

2.	Specify selectors for the announcement as a whole, but leave the
existing syntax as an optional alternative (and thus a standardized part of
the implementor's toolkit).

3.	Specify a syntax for including selectors with standalone variables.

2.1	Syntax For Announcement-Level Selector Specification
      ----------------------------------------------------

The following syntax is suggested if we choose to allow specification at the
level of the entire announcement:

Recall that the general form of an announcement specification is a
comma-separated list of segment specifications of the form

   segSpec = keyword "=" "<" spec ">" 

Add "sel" to the list of keywords, and selList as a possible value for spec.
We should probably require that there be at most one instance of selList
within the announcement specification, and it should come before anything
else.

Define selList to be of the form:

    selList = selSpec *( "&" selSpec ) 

Complete the definition of selSpec as follows (taking it from the present
draft):

    selSpec = seltype "=" selval

    seltype = "lang" / otherSel
    otherSel = NAME

    selval = langCode / otherSelVal
    langCode = 3ALPHA
		; ISO 639-2 code for language selector.  Case-insensitive.
    otherSelVal = *( ALPHA / DIGIT )

Example: 
    an="sel=<lang=fre&locale=france>,sid=<..."

2.2	Syntax For Selector Specification With Standalone Variables
      -----------------------------------------------------------

If adding selector specification to the specification of a standalone
variable segment, the challenge is to delimit the boundary between the
selector and the variable.  The simplest approach is probably to use the
same syntax as in the query part of a URL.  That is, the variable
specification comes first, followed by the selector specification, with the
two parts separated by an ampersand.  Because of its separator role, the
ampersand must be escaped if it occurs inside a variable value.  The
complete syntax specification for a standalone variable with selectors
requires a preliminary change in section 2.2.1.2, where we substitute varSeg
in place of varSpec as one of the alternatives for spec.  In section
2.2.3.1, we define

    varSeg = varSpec

and leave everything else unchanged.  Now in section 2.3.1 we have to add a
whole new subsection talking about selector specification for standalone
variables.  Within it, we extend the defintion of varSeg as follows:

    varSeg =/ varSpec "&sel=" selList
 
where the rest of the definition runs as above.  Note that this is slightly
different from the structure of the selector specification in the current
draft, and perhaps the latter could fruitfully be amended to take out the
redundant "sel=" instances.

3	Conclusion
      ==========

The choice to be made in each of the above cases depends mainly on the
collective view of the requirements to be satisfied.  The Editor prefers to
get the sense of meeting before making a choice.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)