[Telepathy] Telepathy spec. meeting: caps when offline, contact caps, In_Progress call state

[Will Thompson]

Hi,

We've just had a meeting in the Collabora Cambridge office about
undrafting ContactCapabilities and related properties in the Telepathy
specification, discovering what a connection/contact might be able to do
before we sign in, and adding a new In_Progress call state.

== Cast of Characters, clockwise from projectionist ==

* Simon “smcv” McVittie
* Sumana “sumanah” Harihareswara
* Robert “Robot101” McQueen
* Sjoerd “sjoerd” Simons
* Alban “albanc” Crequy
* Guillaume “cassidy” Desmottes
* Will “wjt” Thompson

== RequestableChannelClasses and ContactCaps while offline ==

Can FT clients assume they can make requests that include the suggested
filename, etc., via the ChannelDispatcher? Or is the AccountManager
expected to cache the last known RequestableChannelClasses so it can
suggest which requests are likely to succeed?

Two cases:
* What might this connection be able to do once I sign in? (does it
support avatars?)
* What might this contact be able to do once I sign in?

First can be solved by putting things on the CM object:
* possible presences
* requestable channel classes
* interfaces
* possibly more.
* for each, things you might get, and things you will get.
* this is per-protocol
* should be possible to put these in the .manager file.

Per contact case is harder. It would need to be cached, and Alban points
out that it's likely to change: a contact might sometimes use Pidgin,
and other times use Empathy, and other times an XMPP client on their
phone. So this isn't very useful. Will thinks you can't get this right,
and it's better to be consistent in the UI: either always show a "send
file" option, or never show one, while offline. Everyone seems to agree.

== ContactCapabilities ==

Map from contact to channel classes. GetContactCapabilities and
ContactCapabilitiesChanged have become plural.

Are we all happy with the representation of other people's capabilities?
Yes.

Changes:
* Updating capabilities now takes a pseudo-map: client name ⇒ ( a list
of filters, and a list of tokens )
* If you're mission control, the client name is the bus name of the handler
* if you're not, it's some name for you, so in theory we can use this
without a CD
* The point of keying it by the handler name:
** Very easy for CD to implement. When a client appears, it stuffs it
in; when one changes, it stuffs it in; when one disappears, it passes in
name ⇒ ([], []). When a Connection starts up, it stuffs them all in.
** Slightly harder for CM: it converts the tuples into a language it
understands, maintains one for each client (plus one for old
Capabilities); what it advertises is the union. When a client
disappears, it deletes that client, takes a new union, and updates what
it advertises.
** But: it means it can (eg) not advertise support for google video if
you don't have a client that does audio, video, and H264.

Why is the argument to UpdateCapabilities not a hash?
* Unnecessary level of nesting
* In practice, you iterate it, not look things up in it.

Rob doesn't really like this method. You could have Set and Update; the
former would have this signature, and the latter would just be s,
aa{sv}, as.
* But Set would be no simpler
* In practise you only have a couple of things which need to call this
* It's harder for a client to get it wrong and accidentally blow away
other clients' capabilities.

Any reservations, asks Rob?
* Will: it's a bit of a big type, and it seems a shame. But I didn't
like conflating what the tokens are now used for with the filters, and
this makes the parts easier to explain.
* No other reservations

Do we have this implemented?
* Gabble and MC

How about a client?
* Empathy does the right stuff for the tokens and filters, etc.
* The Rhythmbox plugin uses this, it works
* The Banshee plugin used the old one directly; the only complaint was
that it had to replace caps because it was using it directly (rather
than via MC5 which was not a reality at the time) and the old draft had
Set, not Update. No complaints about the "what can this contact do?"
side of things.

== ImmutableStreams, InitialAudio, InitialVideo ==

Will is a bit upset about the weird semantics of ImmutableStreams WRT
calls that don't have any streams yet. Imagine Rob is signed in with an
audio-only client that has mutable streams, and an audio+video client
that has immutable streams. You don't know whether the streams on the
channel are mutable until you've requested at least one stream.

But, this is actually a pointless edge case: in practice, no-one ever
wants more than one stream of a particular content type, so in the
example given, either you have an audio call, or you have an audio+video
call, and you can't upgrade the former to do video. So... we could
subtly redefine this property to mean "you can't add another stream of a
different content type once it's started" and then in this example Rob
would always have it set, and then we're grand.
* ''AP wjt: reword it.''

If Rob's real Jingle client could do video... then Gabble would pick
that one in preference to the Google-capable client, and so you'd end up
with ImmutableStreams: False, which is what you want. Yay!

== MediaSignalling transport types ==

There's no handler token for raw-udp because any media capable client is
assumed to have that.

The problem here is that Gabble chooses the transport based on a
hard-coded list. If you're a relay, you have to turn on all the caps,
and then when you negotiate a call, the client can't say "i want ice for
this call", even if it means that it has to translate gtalk-p2p into
ice-udp. This is a job for Streamed Media 2.

Conclusion: let's ship it all! Hooray!

Release plan:
* Drop the DRAFT2 suffix in MC5 and Gabble, release
* make a spec release
* drop it into tp-glib, make a release
* patch MC5 and Gabble to use tp-glib in a later release.

== In Progress call state. ==

There's two ways to do ringing in SIP:
* Send "I'm ringing"
* Send early media with a ringing sound

Adding a state for "trying to do something, but the other guy isn't
ringing yet" could solve this. We could use it in Jingle for "we've send
session-initiate but haven't got <ringing/> yet"?

There was a bug report about the early media not arriving because we
haven't tried to send anything yet, so we haven't done any nat punching.
but how could they have been sending us anything if we haven't sent any
candidates? Sjoerd will look into it. But there's nothing wrong with
adding this flag; ship it.

Regards,
-- 
Will

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