| Summary: |
Make sure we document nicely what the RequestableChannelClass for Call should be |
| Product: |
Telepathy
|
Reporter: |
Sjoerd Simons <sjoerd> |
| Component: |
tp-spec | Assignee: |
Telepathy bugs list <telepathy-bugs> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
normal
|
|
|
| Priority: |
medium
|
|
|
| Version: |
unspecified | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
Call |
|
i915 platform:
|
|
i915 features:
|
|
|---|
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.
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.