[Bug 24936] Channel.Type.Call (StreamedMedia 2.0)

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24936





--- Comment #26 from Andre Moreira Magalhaes <andrunko at gmail.com>  2010-01-12 07:23:09 PST ---
While implementing Call support in tp-qt4 I came up with some
questions/concerns as follows:

- Call.Stream.RequestReceiving should accept more than one contact, I want all
contacts to start/stop sending media to me for example
- IMHO Call.Stream.Senders should be called Call.Stream.Members, they are
members of the stream and may not be sending anything.
- Add Call.RemoveContent
- IMHO Call.Ringing should be called Call.SetRinging as it's a action not a
signal

Random ideas/doubts:
- Looking at the Content API I believe streams will be added/removed
automatically when someone joins/leaves the channel.
  Example:
  - A calls B and adds a content of type Audio and a content of type Video, a
stream will be created automatically for each content and StreamAdded will be
emitted accordingly
  - Now A or B invites C to join the channel, I believe a new stream will be
created for each content to let user C join the conversation. If that is not
the case, how can we add streams for C? And what happens if C does not support
Audio calls? only video? Will the Audio content be just ignored or will it fail
as C cannot join the conversation.

- Right now we are using the DTMF iface to support DTMF, but it does require a
stream ID. I believe the best thing to do here is to add a ID for Call.Stream
or even Call.Content in case we want to send DTMF signals to all streams in a
content. 
  Adding an unique ID per stream/content would make it even easier for
high-level API implementations, as SM already uses it and we can use it as a
key for maps/hash when a content/stream is added/removed/changes. Using Stream
object path is a solution but SM uses integer ids, so I just removed the usage
of SM.Stream.ID as key for now.

- There is no equivalent for Stream.State (none, disconnected, connected) in
the call API, so I just dropped this in tp-qt4 high-level API. Maybe we need to
have it and return Connected always for Call channels.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.