[Telepathy] Brainstorming new Call API

[Olivier Crête]

Hi,

This looks like a good start, comments embedded below:

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.

> • 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.

> 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.


> 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 ?

> 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.

> 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.

> 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.

-- 
Olivier Crête
olivier.crete at collabora.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090923/9433d171/attachment.pgp