Subject: Re: reqs-07: updated 11.2.9 Audio Resource Function

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 3 Nov 1999 08:13:48 -0500

Depending on context, this is a specific example of a general requirement
either to tunnel other protocols through Megaco or to support a scripting
capability.  I would humbly suggest that tunneling can be ruled out because
there are more efficient transport protocols than Megaco.  The scripting
variant of the requirement arises when you argue that the tunneling is
needed to correlate the carried information with Megaco command execution.
This one can't be disposed of quite so readily, but I would consider the
general topic of scripting to be an H.248v2 item.

> -----Original Message-----
> From: John A. Voelker [SMTP:[email-masked]]
> Sent: Monday, November 01, 1999 3:50 PM
> To:   [email-masked]
> Subject:      Re: reqs-07: updated 11.2.9 Audio Resource Function
>
> Nancy,
>
> As a supplement to what is now in section 11.2.9 "Audio Resource
> Function",  we
> need a means of referencing command sets that use external protocols
> specialized
> to this kind of audio resource functionality.  For example, reference
> VoiceXML
> (see http://www.voicexml.org/) commands. (I believe the W3C is or may do
> some
> work in this area.)  Specialized protocols like VoiceXML will
> likely provide finer grained control and evolve faster than Megaco can
> evolve
> its own audio resource package. Especially since audio resource management
> lives
> near the edges of the scope of a gateway control protocol.  Also, it would
> be
> desirable for voice control on gateways to be able to use the same voice
> control
> commands as will be used on non-gateway devices which we cannot presume
> will all
> adapt Megaco control.
>
> Obviously, we would not require MGs to support any or all of these
> auxilliary
> protocols.
>
> We need a way for the MGC to reference the name of a specialized voice
> protocol
> (e.g. VoiceXML or others) followed by a delimited set of in-line commands
> writtern  according to that specified protocol.  That is, permit an escape
> to a
> foreign protocol.
>
> Another possiblity - I am less comfortable with this - is to permit a
> pointer to
> an  external block of commands written according to the referenced
> specialized
> protocol. For Voice XML, a URI could serve as the pointer.
>
> VoiceXML is mentioned here as an example.  Others possibilities could be
> added.
> (I can not speak to the intellecual property issues regarding VoiceXML
> itself.
> In fact, several  companies may have VoiceXML IP.)  What I think is
> valuable is
> enabling H.248 to leverage other protocols in areas that fall near the
> edges of
> H.248 gateway control charter.
>
>
> John Voelker

---

From: "John A. Voelker" <[email-masked]>
Date: Thu, 4 Nov 1999 17:25:13 -0600

We need to recognize that the boundaries of Megaco tend to overlap non-gateway
device control.  Audio processing (IVR, announcements, speaker recognition,
etc.) can be carried out on gateways and on (the more numerous) devices that are
not gateways.  Incidentally, control of IP phone displays may represent an
analogous situation.  We also need to recognize, that in its breadth, Megaco may
not be able to achieve and maintain best in class control mechanisms for all
areas that are not within its core focus.  This is not to argue that Megaco
should retreat from these areas, rather only that it should interwork easily
with other protocols specialized to specific tasks like audio processing.

I have no interest in simple "tunneling".  Commands from specialized protocols
would need to reference particular contexts and terminations, and be properly
sequenced among the execution of Megaco commands.  The commands may somehow be
provided inline as part of a transaction (not that it is obvious how to do
this), or may be referenced by some kind of handle (a file name or URI).  Also,
we need define the conventions to return status and collected data.

Why care?  Network service providers will provide audio processing on both
gateways and non-gateways.  They may well want both:
1) to use specialized protocols for audio processing on non-gateways in
preference to native Megaco audio processing, and
2) to use the same audio processing protocol in their gateways as in their
non-gateways. To provide a common "listen and feel" and to simplify
administration of services.

Megaco should accommodate service providers in this position.

I am not insisting that this need be a version 1 issue.  But I think we need to
start thinking about it.

John Voelker

p.s. Can anyone point me to some previous threads regarding scripts?  I'd like
to review them.