Subject: Re: draft-cromwell-navdec-mgcp-audio-pkg-00.txt

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 28 Nov 1998 10:20:31 -0600

The draft has a valuable summary of telephony announcements, but the core
capabilities in <draft-cromwell-navdec-mgcp-audio-pkg-00.txt> are also
available from an RTSP controlled media server.

Is there a duplication of core functionality here, or am I missing
something?

For example:
>The Announcement Server Package is comprised of events, parameters,
> variable qualifiers, and key qualifiers.

Would it make sense to map these specific telephony messages into RTSP? If
yes, how?

For local devices, would the Mbus make sense?
Message Bus for Conferencing Systems,
<draft-ietf-mmusic-mbus-transport-00.txt>

The bottom line is: How many protocols should we have? One per device?

What are the different telephony requirements between
1.  Media server - RTSP,
2.  Telephony announcement server - audio-pkg,
3.  Conference system and a telephony announcement device - Mbus?

Thanks, Henry

---

From: "David Cromwell" <[email-masked]>
Date: Mon, 30 Nov 1998 12:34:01 -0500

Henry,

I appreciate you bringing this up.  There is a general misunderstanding about
the nature of the proposed MGCP Announcement Server Package, and I welcome
this opportunity to set the record straight.  RTSP and the MGCP Audio Server
Package (ASP) are wildly different.   We're not talking apples and oranges
here either;  it's more like apples and orangutans.

> Is there a duplication of core functionality here, or am I missing

RTSP supports client control of media stream(s) from a server.   Typically
RTSP would sit on top of a transport mechanism such as RTP.  Both RTSP and
RTP are fairly low level protocols which form part of an ubiquitous VOIP
network infrastructure.  RTSP provides minimal play and record operations.

The ASP lives at a much higher level in the system.  It sits right below the
application and provides  an IVR toolkit for application programmers.   Its
contents are highly IVR specific.  It provides a standard sets of
announcements, multilanguage voice variables, special key definitions,
reprompting, etc., etc., all of which are useful for doing IVR.  There are
lots of places in a VOIP network where the Announcement Package would not be
appropriate.  In fact the only place where it would be appropriate is in the
control of an *Announcement* Server (I am carefully not saying *Media* Server
here).

Additionally, RTSP is a symmetrical protocol where both client and server can
issue requests/commands.  In the protocol into which the the ASP is embedded,
flow of control goes only one way.  The call agent issues commands to a
server.  That's it.

> Would it make sense to map these specific telephony messages into RTSP? If

I don't think so.  The mismatch in levels is too great.  It would be like
adding a graphics package to TCP/IP.  Just to take a single for instance, I
can't see that support for a specific set of multilanguage voice variables
(date, time, money, duration, etc.) has any relevance to RTSP.  RTSP and ASP
are not mutually exclusive however.  I can envision ASP operations being
invoked by an application which filter down at some point to RTSP and RTP.

> <draft-ietf-mmusic-mbus-transport-00.txt>

Mbus is specifically aimed at co-ordinating conferences.  I won't go into a
detailed analysis, but, for example, I don't think the concept of a
whiteboard has any relevance to IVR.

> 3.  Conference system and a telephony announcement device - Mbus?

The proliferation of protocols and the overlap of functionality between
protocols is a legitimate concern, and it would be unfortunate to see the
VOIP world evolve into a Tower of Babel.  But in regard to the specific
question that you raised, I think that RTSP and ASP are very different and
that each has a legitimate place in the VOIP world.

Regards,
David
--
[email-masked]
Nortel Networks  RTP, NC

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Nov 1998 13:38:30 -0500

> RTSP would sit on top of a transport mechanism such as RTP.  

RTSP does not sit "on top" of RTP in any geometry sense that I can think
of. RTSP can control RTP streams, but it can also control any other
media stream delivered via ATM, POTS or anything else. Indeed, many of
the PINT principles apply here. RTSP does have some RTP-specific things
in it (Transport-Info).

> contents are highly IVR specific. 

I thought we were standardizing protocols, not APIs? Clearly, an IVR API
would not have a 'RTSP_Play' API. But that doesn't preclude it from
using RTSP underneath, if it can perform the necessary mappings.

> flow of control goes only one way.  The call agent issues commands to a

This is a bogus argument. RTSP can be used symmetrically, but for many
applications, it is a client-server protocol, with one client and one
server. Clearly, as an announcement application, the flow of control
would be one way, with the controller sending RTSP requests to the
announcement server to play announcements.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Nov 1998 13:56:57 -0500

> network infrastructure.  RTSP provides minimal play and record operations.

RTSP does not sit ontop of RTP. RTSP can control a media server which
makes use of RTP to deliver content, but thats not the same thing.

> control of an *Announcement* Server (I am carefully not saying *Media* Server

I'm not so sure that ASP is "higher" than RTSP; both protocols are
application layer protocols in the sense that they run ontop of an IP
transport protocol (TCP or UDP). Both provide services for applications
(one IVR, one media control). Both, in fact, provide control services.
What about them makes one "higher" and the other "lower"?

Support for announcements, voice variables, and the like are not
explicitly part of RTSP, true. However, these seem to be issues related
to namespaces at the RTSP server, not fundamental protocol features. One
could simply define a namespace (i.e., a standard set of filenames) for
all of the variables, announcements, tones, and the such, that you'd
like to play. RTSP is not specific to "movies" or "radio"; its a more
generic tool for playing and recording audio or video. Announcements fit
into this category so long as you can put a name on what you want to
play.

So, for example the URL:

rtsp://announcementserver.com/asp/variables/money/dollar/1

Could have the server speak the words "one dollar", while

rtsp://announcementserver.com/asp/tones/pound

Could cause the server to play the tone corresponding to the pound. RTSP
can also be used to control the volume and duration of the tone.
Supporting this requires no changes to RTSP, just an agreement on the
namespace.

> flow of control goes only one way.  The call agent issues commands to a

This is true, but doesn't seem to be an argument about why RTSP is not
appropriate here; if anything, just the opposite, since it supports the
client/server command/response architecture you need, and then some.

> invoked by an application which filter down at some point to RTSP and RTP.

Its not so clear to me that there is such a great mismatch. I agree RTSP
does not currently do everything ASP is trying to do, but its perhaps
not as far away as you indicate. My only point is that it perhaps
deserves closer study.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: "David Cromwell" <[email-masked]>
Date: Mon, 30 Nov 1998 15:50:31 -0500

Jonathan,

> makes use of RTP to deliver content, but thats not the same thing.

I was thinking in terms of the hierarchical ISO 7 layer model, but maybe that's
not applicable here.  I can see how you could view RTP and RTSP as peer protocols.

> Supporting this requires no changes to RTSP, just an agreement on the

Defining this name space provides RTSP a way to reference audio, but nothing
else.  Are you seriously suggesting adding something like the ASP PlayCollect
operation to RTSP with support for definition of specific categories of
announcements such as Reprompt, NoDigitsRepromt, or Failure Announcement to be
used as necessary by the server as it attempts to collect a valid digit pattern
over a number of user attempts?   To get the full functionality of the ASP
PlayCollect operation you'd also have to add first, inter, and extra-digit timers,
the ability to define seven different types of control keys (Stop, Restart,
Reinput, StartInput, etc.) most of which would cause some local action to be
performed on the server, regular expression DTMF pattern specification, digit
buffer control, and the number of attempts.

Obviously you could do this, but would you really want to?

Like a lot of things things, IVR seems pretty simple at first glance (all you've
got to do is play some audio, collect come digits, and maybe record, right?), but
on closer examination it turns out to be a lot trickier than it first appeared. By
belief is that IVR is a highly specialized area, and it does not make sense to
incorporate this functionality into a protocol as generic as RTSP appears to be.

> client/server command/response architecture you need, and then some.

OK.  I admit that was a somewhat bogus point.

> not as far away as you indicate. My only point is that it perhaps

You're right, adding ASP functions to RTSP isn't really as outlandish as adding a
graphics package to TCP/IP, but I think is involves more than just defining an
additional name space for RTSP, and  I still feel there is a mismatch.  In any
event maybe we should kick this idea around some more and see where it goes

Regards,
David

---

From: "David Cromwell" <[email-masked]>
Date: Mon, 30 Nov 1998 15:50:38 -0500

Henning,

> the PINT principles apply here. RTSP does have some RTP-specific things

Thanks for clearing that up.

> using RTSP underneath, if it can perform the necessary mappings.

To date, no one has gotten much beyond the "output this stream on this endpoint"
stage in defining how IVR should work.  I feel there is a lot to be gained from
defining a generic IVR functionality for Announcement Servers and  embedding it in
MGCP and perhaps other VOIP protocols.  I am not convinced it fits well with RTSP
although it may possibly map it to RTSP running as a lower layer.

> announcement server to play announcements.

You're right, that is a bogus argument.

Regards,
David

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Nov 1998 16:07:08 -0500

> not applicable here.  I can see how you could view RTP and RTSP as peer protocols.

RTSP and ASP as peer, not RTP and RTSP.

> buffer control, and the number of attempts.

I agree with you that RTSP doesn't do it all, as I indicated in my
previous mail. I just don't think RTSP should be dismissed out of hand.
It clearly handles at least the tone and announcement playing aspects of
IVR; collecting DTMF is also possible with record. Whats missing are
some of the "compound" actions - such as play and then collect, as you
point out, and some others you mention. My point is that its not so
unreasonable for RTSP to be a starting point, and it merits
investigation to determine how many of the requirements it does meet,
and how many extensions are required to meet the rest. 

-Jonathan R.