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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #62 from Sjoerd Simons <sjoerd at luon.net> 2010-06-24 06:23:51 PDT ---
(In reply to comment #3)
> 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.

Gone with the former, done

> * 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)

#28724

> * InitialTransport: s => Needs to be given a type, we might have one in the old
> api already

#28725

> * Make it very clear that we mandate that either InitialAudio or InitialVideo
> is mandatory. 

#28717

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

#28687 and probably #28686

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

Add capability token for shared memory transport

> * HardwareStreaming needs to be specced as an immutable property
#28728

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

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

#28729 

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

assuming spec linting solved this

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

Solved by always requiring the handler to call Accept before startin the call. 

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

Done

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

Done

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

#28731 

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

#28732

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

#28733

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

#28720


> * StreamAdded might become plural
#28736

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

#28735

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

#28700

> * Need to ponder on calls from anonymous number.

#28730

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