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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #50 from Sjoerd Simons <sjoerd at luon.net> 2010-06-23 09:50:57 PDT ---
(In reply to comment #26)
> 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
#28699

> - IMHO Call.Stream.Senders should be called Call.Stream.Members, they are
> members of the stream and may not be sending anything.

#28700

> - Add Call.RemoveContent

#28701

> - IMHO Call.Ringing should be called Call.SetRinging as it's a action not a
> signal

#28702

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

See #28703

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

#28696 (which i think is already solved by the DTMF interface)

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

Yeah, not going to do integer id for streams

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

That's on the endpoints (as there can be multiple ones in ICE forking)

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