[Telepathy] Brainstorming new Call API

[Sjoerd Simons]

On Wed, Sep 23, 2009 at 01:27:38PM -0400, Olivier Cr?te wrote:
> Hi,
> 
> This looks like a good start, comments embedded below:

Thanks :) Also thanks for the feedback :)

> On Wed, 2009-09-23 at 14:30 +0100, Will Thompson wrote:
> > Sjoerd will be uploading a snapshot of his current draft shortly. It
> > adds Channel.Type.Call as the top of a tree of objects representing
> > the call. Sjoerd, Dafydd Harries and myself spent some time yesterday
> > discussing the draft; here's a summary of what we discussed.
> 
> See:
> http://git.collabora.co.uk/?p=user/sjoerd/telepathy-spec.git;a=commitdiff;h=3b6c5e271660017cc751bdf4cd3fc46003b613f0
> 
> > HardwareStreaming property on Call:
> > 
> > ??? This replaces the presence or absence of the MediaSignalling
> >   interface, telling you whether or not you need to use something like
> >   Farsight to actually stream media.
> 
> If you want to have mixed SIP and non-SIP channels.. I guess the
> property should be something all "AllStreamingInternal" and you'd still
> have to check for the presence of some interface on the streams.

Yeah, clarifying it that this is true only if ALL streams are done by
the CM instead of the client.

> > ??? This is a rubbish name. The streaming might not be done in
> >   hardware. Other suggestions: HandlerStreaming? Any others? Help!
> 
> The name is indeed terrible. You also want to set it for protocols like
> IAX2 where the media and signalling are mixed.

Nice example, didn't think of that one. Suggestions for better names still
welcome ;)

> > In Jingle, if Alice and Bob call each other at the same time, the call
> > with the lower session ID is meant to win. How do we represent this in
> > Telepathy? On the "losing" side, does the call that lost vanish, and
> > the new call pop up, or does the existing call silently morph into the
> > incoming one? Will thinks the desired user experience is that Alice
> > and Bob both click call, and then they're on a call with no further
> > interaction.
> 
> The UI should deal with this. Merging concurrent calls in the CM seems
> like asking for problems. In particular, for Jabber, the controlling
> mode is set according to who started the call. So Farsight needs to be
> restarted anyway.

Good point. We should add a mapping to the error (well redirection) jingle
gives us and then the UI can decide.

> > Content names: sometimes they're useful (your Jingle client might
> > helpfully call the projector stream "projector") and sometimes they're
> > not (your Jingle client might call it "video2"). No real way to
> > tell. Maybe Jingle should support extra information: <projector/>,
> > <webcam/>, etc. But we should expose the name we do have, so if the
> > client wants to apply some heuristic it can.
> 
> Do we supply a way for clients to name their Contents ?

Yeah, when you add a content you can suggest a name for it (or use "" to let
the CM pick).

> > Contents will need members (and change notification) separate from the
> > call as a whole. In Muji, for instance, one person might only be
> > sending and receiving audio, while all the others are doing audio and
> > video. Should you be able to add other parties to contents? Probably
> > not.
> 
> Yes, you may want to start sending to someone. But it depends on the
> transport. For Multicast, you can only send to everyone at the same
> time.

Starting to send someone is done on the stream level, not on the content level.
In the multicast case, each Content has exactly one Stream, while in the Muji
case you have one Stream for each contact you're sending to. This is done
this way exactly to map these differences nicely.

> > Stream
> > 
> > ??? RequestReceive() needs an extra u: Contact argument.
> > ??? Does it make any sense to ask the other person to send you video
> >   with Jingle? It does make sense on MSN, though.
> 
> Yahoo also has that I think.
> 
> > ??? Daf wonders what will happen if:
> > 
> >   1. Daf has no webcam;
> >   2. Will video-calls Daf;
> >   3. Daf turns off the video;
> >   4. Daf wants to see Will's face again.
> > 
> >   Does it make sense to want to do this? He might want to use the
> >   bandwidth for something other than receiving video for a
> >   while. You can't have streams with senders="none" in Jingle, and
> >   hold is per-stream. Hrm.
> 
> For Jingle, the only solution is to ask the other person to enable
> his/her webcam over the voice channel.

> > ??? DirectionChanged needs a u: Contact argument.
> > ??? CurrentDirection and PendingDirection should become Directions:
> >   a{u(bb)}
>
> You also want a "MaximumDirection" to let the UI know about
> unidirectional streams à la MSN/Yahoo.

It will probably become ImmuntableDirection or somesuch, but yes, similar
goals.

> > Content dispositions:
> > 
> > We want to better define exactly what you're accepting when you call
> > Accept() to avoid this race:
> > 
> > 1. I audio call you;
> > 2. You click accept just as I turn on video;
> > 3. You accidentally accepted the video stream.
> > 
> > We can give contents a Disposition property like Jingle (but not
> > necessarily the same as at the Jingle level), and define that Accept()
> > on the call only accepts those with Disposition: session. Do we need
> > Accept() on the contents, then? Do we really need to support the UI
> > sending content-reject?
> 
> I think that except for unidirectional content, you should never start
> sending without an explicit user request (not just approval, but
> request).. Except for unidirectional streams where well, you can also
> have an approval. And I think receiving extra content should be a
> non-issue.

A content being added doesn't mean you'll start sending, sending is being done
on the Stream level not on the Content level. Also a CM will never start sending
by itself and the conditions under which it starts will sending are
meant well-defined, which is one of the main reasons why we're adding
disposition :)

  Sjoerd
-- 
It is through symbols that man consciously or unconsciously lives, works
and has his being.
		-- Thomas Carlyle