Subject: Seems this might play nicely with your stream control stuff

From: David Oran <[email-masked]>
Date: Wed, 11 Sep 1996 09:13:07 -0400

I can imagine a neat way that you could command the record/replay server to
send recorded audio as an Email message, or have a PSTN gateway work with
the stream control stuff to work as a voicemail server.

Any thoughts?

Dave.

>To: IETF-Announce:;
>Sender: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ema-vpim-01.txt
>Date: Tue, 10 Sep 1996 09:38:02 -0400
>X-Orig-Sender: [email-masked]
>
> A Revised Internet-Draft is available from the on-line Internet-Drafts 
> directories.                                                              
>
>       Title     : Voice Profile for Internet Mail - version 2             
>       Author(s) : G. Vaudreuil, G. Parsons
>       Filename  : draft-ema-vpim-01.txt
>       Pages     : 43
>       Date      : 09/09/1996
>
>A class of special-purpose computers has evolved to provide voice messaging
>services.  These machines generally interface to a telephone switch and 
>provide call answering and voice messaging services. Traditionally, 
>messages sent to a non-local machine are transported using analog 
>networking protocols based on DTMF signaling and analog voice playback.  As
>the demand for networking increases, there is a need for a standard 
>high-quality digital protocol to connect these machines.  The following 
>document is a profile of the Internet standard MIME and ESMTP protocols for
>use as a digital voice messaging networking protocol.        
>
>This profile is based on an earlier effort in the Audio Message Interchange 
>Specification (AMIS) group to define a voice messaging protocol based on 
>X.400 technology.  This protocol is intended to satisfy the user 
>requirements statement from that earlier work with the industry standard 
>ESMTP/MIME mail protocol infrastructures already used within corporate 
>intranets.  This Internet Draft will be referred to as VPIM (Voice Profile 
>for Internet Mail) in this document.  This second version of VPIM is based 
>on implementation experience and obsoletes RFC 1911 which describes 
>version 1 of the profile.                      
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>     "get draft-ema-vpim-01.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ema-vpim-01.txt
> 
>Internet-Drafts directories are located at:	
>	                                                
>     o  Africa                                   
>        Address:  ftp.is.co.za (196.4.160.8)	
>	                                                
>     o  Europe                                   
>        Address:  nic.nordu.net (192.36.148.17)	
>        Address:  ftp.nis.garr.it (193.205.245.10)
>	                                                
>     o  Pacific Rim                              
>        Address:  munnari.oz.au (128.250.1.21)	
>	                                                
>     o  US East Coast                            
>        Address:  ds.internic.net (198.49.45.10)	
>	                                                
>     o  US West Coast                            
>        Address:  ftp.isi.edu (128.9.0.32)  	
>	                                                
>Internet-Drafts are also available by mail.	
>	                                                
>Send a message to:  [email-masked]. In the body type: 
>     "FILE /internet-drafts/draft-ema-vpim-01.txt".
>							
>NOTE: The mail server at ds.internic.net can return the document in
>      MIME-encoded form by using the "mpack" utility.  To use this
>      feature, insert the command "ENCODING mime" before the "FILE"
>      command.  To decode the response(s), you will need "munpack" or
>      a MIME-compliant mail reader.  Different MIME-compliant mail readers
>      exhibit different behavior, especially when dealing with
>      "multipart" MIME messages (i.e., documents which have been split
>      up into multiple messages), so check your local documentation on
>      how to manipulate these messages.
>							
>For questions, please mail to [email-masked]
>							
>
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version
>of the Internet-Draft.
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ema-vpim-01.txt
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
-----------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Phone: 508-264-2048 or 508-263-2705
EMail: [email-masked]

---

From: "Scott Petrack" <[email-masked]>
Date: Wed, 11 Sep 96 16:49:35 IST

David Oran wrote:
> I can imagine a neat way that you could command the record/replay server
> to send recorded audio as an Email message, or have a PSTN gateway
> work with the stream control stuff to work as a voicemail server.

> Any thoughts?

I consider the sorts of scenarios that you mention as requirements, and
definitely had them in mind when I suggested using RTCP for controlling
IP-telephone streams. ( For example, RTCP has an email SDES item, and I
mentioned that this could be used to indicate where to send the stream
as an email message. My point then was that RTCP has lots of packets
already defined, and we "only" have to write out profiles to define
their semantics in certain situations. Unfortunately, I think that I
confused people by trying to use RTCP packets in a new way, and one of Jeff's
new suggestions, to use APP packets, will remove this confusion.)

Of course, the semantics of the commands still need to be defined, and
I hope that it will be done in such a way that the RTCP packet which
tells a video recorder
to "pause" and tells a remote telephone to "hold" will be the same.

I am these days trying to use Jeff's SIP/RTCP ideas to do precisely the
kinds of things you are talking about (as well as some other useful basic
telephone functions).

I think that there is one real difference between what Jeff is doing
and the scenarios you mention.
Jeff is creating commands to control a machine
whose input or output is always a set of RTP streams. These scenarios
are slightly more general. The input or output might be something other
than RTP streams, even though an RTP stream is definitely being "controlled"
in the process. I agree with your implication that it's appropriate to
use RTCP/SIP for these things, but not everyone may agree.

Scott