Use cases for media streaming

Hi all,

I would like to start a discussion on the support of media streaming in 
Gossip.  My proposal for a Gossip API hit a road block because it wasn't 
clear what the use cases were for media streaming features.  I hope this 
email helps us better understand what our goals are.

Before the use cases are enumerated, I think we need to define some 
assumptions.  These assumptions will help us better understand the 
environment in which these use cases will reside.

1.  Gossip will detect audio sources, audio sinks, and video sources
that are available on the system for the user.  A video sink is assumed to 
always be available.
2.  Gossip will perform the above detection automatically.
3.  Gossip will dynamically update the UI with the results of the 
detection as they are made available.
4.  Gossip will determine the capability of the IM protocol to support 
media streaming.
5.  Gossip will only expose those capabilities that are available on the 
specific IM network.

In the following descriptions, the term 'user' will refer to the Gossip 
end-user (i.e. not the developer).

I.  Place a voice-only call (bi-directional).
 	a.  User selects a contact.
 	b.  Gossip presents a menu item to place a call.
 	c.  User selects menu item.
 	d.  Gossip presents a progress dialog with cancel/abort
 	    button.  An audible noise may be generated.
 	e1. The call is established and an indicator on the
 	    contact is shown.  The dialog is removed.
 	e2. User clicks cancel and Gossip shuts down the call.
 	    The dialog is removed.
 	f.  Gossip adds a menu item to terminate the call.
 	g.  User selects 'terminate call' menu item.
 	h.  Gossip terminates call.

II.  Receiving a voice-only call (bi-directional).
 	a.  Gossip notifies the user of an incoming voice call
 	    request.  This notification can use any mechanism.
 	    The mechanism should have options for the user to
 	    accept or reject the call.  The mechanism should
 	    also indicate which IM network and which contact is
 	    making the request.
 	b.  User accepts call request.  Notification mechanism
 	    is removed.
 	b1. Gossip shows an indicator on the contact.
 	b2. Gossip adds a menu item to terminate the call.
 	b3. User selects 'terminate call' menu item.
 	b4. Gossip terminates call.
 	c.  User rejects call request.  Notification mechanism
 	    is removed.

III.  Place a voice and video call (bi-directional).
 	Steps are same as 'Place a voice-only call'.

IV.  Place a receive-only video-only call.
 	Steps are same as 'Place a voice-only call'.

V.  Place a send-only video-only call.
 	a.  User activates this feature.  It is assumed that
 	    this feature allows any number of remote users to
 	    subscribe to this video stream.
 	b.  Gossip presents a selection of IM networks that
 	    support publication of video stream.
 	c.  User selects connected networks.
 	d.  Gossip establishes a video stream to each selected
 	    network.
 	e.  Gossip presents control to terminae video stream.
 	f.  Gossip notifies local user a remote user wants to
 	    subscribe to the video stream.  Options to accept
 	    or reject subscription is presented.
 	g.  User accepts request.
 	g1. Gossip indicates remote user is subscribed to
 	    video stream.
 	g2. User selects subscribed user and terminates its
 	    subscription.
 	h.  User selects 'terminate' control.
 	i.  Gossip ends publication of video stream.

VI.  Mute/Pause media stream.
 	a.  User selects mute/pause of media stream.
 	b.  Gossip mute/pause selected stream and direction.

Issues to consider:

1.  I'm not sure how to add directionality to an outgoing voice-only call. 
For incoming voice-only call, the accept response could include this 
option.

2.  I haven't checked whether V.g2 is possible.  I would assume any IM 
protocol that supports publishing a video stream would add such a feture.

3.  Can 'send-only video-only' calls be limited to specific contacts?  If 
no IM protocol has such a feature, I don't see the point in defining a use 
case for it.

Please comment...

--jc
-- 
Jimen Ching (WH6BRR)      [email protected]     [email protected]