[Telepathy] Brainstorming new Call API

[Will Thompson]

Hi,

As you may know, Sjoerd Simons has been working on a new API for calls
in Telepathy, to replace the StreamedMedia, MediaSignalling,
SessionHandler and StreamHandler interfaces. This is partly needed
because the current interfaces are confusing and ad-hoc, and partly to
support multi-party calls (which will be supported at the XMPP level
by Muji <http://telepathy.freedesktop.org/wiki/Muji>).

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.

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.
• This is a rubbish name. The streaming might not be done in
  hardware. Other suggestions: HandlerStreaming? Any others? Help!
• Apparently 3G audio-video calls send the audio as a normal call, and
  the video over a SIP session. Is it possible to upgrade normal calls
  to add video, or do you have to decide at the start of the session
  whether you might want to do video?
• Can't you just find out whether you need to start Farsight based on
  whether or not any of the Content objects have the Session
  interface, like we do now?
  • Well yes, but this way you don't have to do anything more than
    look at the immutable properties to see whether you need Farsight,
    and in principle you could use a different handler (even though
    in practice you won't.
• Note that in the 3GPP case, the audio content will be
  hardware-streamed, but the video content needs Farsight.

InitialTransport property:

• You care about this if you're writing a gateway; if both legs of the
  call use the same transport, the gateway can just send the
  candidates along, and then the media can flow like this:

  XMPP client ←[jingle]→ gateway ←[sip]→SIP client
       ↑                                        ↑
       +------------------[media]---------------+

  But if you use (say) gtalk-p2p for the XMPP leg, and raw-udp for the
  SIP leg, it has to look like this:

  XMPP client ←[jingle]→ gateway ←[sip]→SIP client
       ↑                    ↑   ↑               ↑
       +--------[media]-----+   +---[media]-----+

• It's initial because it might change during the call (such as
  transport-replace in Jingle).
• Can you tell ahead of time which transports a SIP client supports?
  Or do you have to try to call them with ICE, and if it fails try
  again with raw?

Hangup() method:

• Does it need arguments to supply the reason? We took a look at the
  reasons you can end a call in Jingle-land: if at least two of them
  are useful for a UI to be able to specify, then we do need to be
  able to give a reason. Gabble can infer <cancel/> vs. <success/>,
  but <timeout/> and <busy/> are both something you'd want the UI to
  choose to send, so yes we do need args.

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.

Call state map:

• Maybe we want to know to whom someone forwarded us. How
  state-recoverable does this have to be? If Simon forwards me to
  Alban who forwards me to Vivek, does all that information need to be
  in a property?
• Add states for Rejected, etc.
• Some of these flags aren't actually flags, they're
  mutually-exclusive. So what we actually want is probably a{u(uu)}:
  contact handle ⇒ (one of [pending, accepted, declined], flags from
  [ringing, hold, ...]).
• Needs to support all the reasons we can pass to Hangup(), plus
  pending and accepted.

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.

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.

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.

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

• DirectionChanged needs a u: Contact argument.
• CurrentDirection and PendingDirection should become Directions:
  a{u(bb)}

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's all we talked about! Comments very welcome, on this
discussion or on the draft spec (when it's uploaded).

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090923/fc76f95c/attachment.pgp