Bug 28717 - Make sure we document nicely what the RequestableChannelClass for Call should be
Summary: Make sure we document nicely what the RequestableChannelClass for Call should be
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard: Call
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-24 05:01 UTC by Sjoerd Simons
Modified: 2010-10-10 09:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Sjoerd Simons 2010-06-24 05:01:57 UTC
From #24936:

Some comments while working on the Call example CM:

* InitialTransport should be specified to be "" where not applicable, and in
particular, on CMs with hardware streaming

* The immutable properties on Channel, Stream and Content should all be
annotated as such

More thoughts:

Sjoerd and I agreed that the RequestableChannelClasses should be:

* fixed = { Call, CONTACT, InitialAudio=TRUE }, allowed = { InitialVideo=TRUE }
* fixed = { Call, CONTACT, InitialVideo=TRUE }, allowed = { InitialAudio=TRUE }

i.e. clients aren't allowed to make outgoing calls that have neither initial
audio nor initial video. This doesn't match StreamedMedia, and doesn't match
telepathy-qt4's current handling of StreamedMedia capabilities - it'll be
important to check at review that it gets this right.

The initial streams should have the Initial disposition, even though that's not
interesting on locally-initiated streams.
Comment 1 Jonny Lamb 2010-10-10 09:03:00 UTC
Fixed in git.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.