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

[bugzilla-daemon at freedesktop.org]

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





--- Comment #3 from Sjoerd Simons <sjoerd at luon.net>  2009-11-13 08:09:53 PST ---
Myself and Simon had a small spec meet last week about the spec, the following
are the notes from them.

* Hangup (ss) or (uss) => Close implies unexpected channel closure.
  -  might be deprecated by TP 1.0

The hangup method on the Call channel should be able to take an error. We need
to make up our minds if this should be (uss) (Error enum, Dbus error string,
Debug message) or just (ss) (Dbus error string, Debug message)..

The former has the advantage that we use the enum for categories that rarely
gets extended, such that applications can fallback to using the enum value if
they don't recognize the (more detailed) dbus error string.

* AddContents:
  * flesh out the rationale for content name.
  * E_INVAL is only for content types ? E_INVAL maybe be NotCapable instead.

What error should be reported when a content is added with a media type that
the CM doesn't support. Also what error should be reported if a media type is
added which isn't possible in this call (can't add a second video stream, can't
add a content when the content set isn't mutable etc)

* InitialTransport: s => Needs to be given a type, we might have one in the old
api already
* Make it very clear that we mandate that either InitialAudio or InitialVideo
is
  mandatory. 

* Need a way to expose rtp profiles (AVP/AVPF)

* Capability tokens need to be nicely namespaced. and also add a capability
  token for shared memory transport (as implemented by farsight)

* HardwareStreaming needs to be specced as an immutable property

* Add rationale hardware streaming (no need to start S-E,  open a webcam etc
etc
  if it's streamed by hardware)

* Rumor has it that some stuff are partially hardware streamed (e.g. GSM for
audio, SIP for video),  
   would be good if we could verify it, although the wording already such that
this is allowed. 

* unnamespaced asv keys should be in the same style as GObject properties

* Ponder poking the possible handler before approvers are ongoing (so we can
send
  candidates while the call isn't approvered yet).

With ice you want to start exchanging candidates as soon as the call comes in
(iotw, when the phone is ringing, which is when the call is at the approver
stage). This means that ideally the handler would already have the channel. If
another handler is decided it could restart the negotiation by doing an ice
restart (although hopefully this will be uncommon...). So what we might need is
an AddRequest like thing from mission-control, to warn handlers that they might
get a channel.

* Document and ponder when to actually start the outgoing calling.

For voip calls this is not a problem, you can usually only start calling once
you've given all the contents a set of codecs. But for calls with hardware
streaming this might be a bit more tricky, as in, 
it might be undesirable to start dailing before the handler has popped up.
Maybe the handler should also Accept() outgoing calls (and starts of in the
pending call state)?

* Work out division of responsibility between approver and handler.

iotw, should the Handler or the Approver call Accept. Imho the handler should,
so you can make sure that you have a Call UI once you accept the call.

* Mention that CallState is exhaustive ?
* CallState add 0 for unknown.


The enum in the CallState should be complete, as in, it should encompass the
complete state machine. Where extra information is part of the asv. Also, we
should change the call state to (uua{sv}) aka (State, Flags, Info). Where
minimal voip UI's should be able to get the basic information from the State +
Flags and more complete handlers can get extra information from the info dict.

* For 1-1 calls have a error state for the self-handle if they missed the call

* Explicitely mention that the target handle is the person you initially called

This is important for conference calls, where the person that initially called
you or invited you might not be in the channel anymore, so handlers shouldn't
rely on this

* Invent a channelstate for the health of the channel

To make it easier the understand the overall state of the channel we should
have ChannelState property with an actor. So you only have to look at this
property to decide for example that the call ended because the other side
rejected it, without needing to dig in the CallState property

* Have an InitialContent boolean instead of Disposition

The Disposition enum has <none>, <early media>, <initial> but on protocols like
SIP you can't actually know what stream is early media, so just <none>,
<initial> might be better. In which case it can be replaced by a simple boolen.

* StreamAdded might become plural
* Stream: Document what the PendingSend sending state means for the self
handle.

The PendingSend state for the self handle indicates that the other side
requested our side to start sending media, which can be done by calling
SetSending. When a call is accepted, all _initial_ contents with streams in the
PendingSend state for the self-handle are automatically set to sending.

e.g. on an incoming call it means you need to Accept to start the actual call,
on an outgoing call it might mean, you need to accept before actually starting
the call.. 

* Stream: Rename Senders to Members

On the Stream interface the Senders property should be renamed to Members for a
bit more clarity

* Need to ponder on calls from anonymous number.


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