[Bug 47296] Call: Can not be used with Approvers

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Olivier Crête <olivier.crete at ocrete.ca> 2012-03-28 13:45:52 PDT ---
(In reply to comment #4)
> (In reply to comment #0)
> > The problem is that the Call spec says that the user should not be notified of
> > an incoming call before the Call reaches the INITIALISED state, but it will
> > only reach that state when network connectivity has been been established,
> > which requires a Handler to be present. So the handler need to runs before the
> > approver. Which isn't how the Approver/handler interaction currently works.
> 
> Why does the Call spec say this? The only rationale I can find is "to reduce
> the probability that the user will pick up the call and have it immediately
> fail". In what situations would this happen? Being behind a particularly nasty
> firewall?

That is one thing, also, the other big advantage of doing ICE as early as
possible is that the call will be immediately connected after you accept it.

> I feel as though the user should be notified that someone tried and failed to
> call them (or at least Telepathy shouldn't make it unnecessarily hard to do
> so), but it should probably look more like an instantly-missed call than an
> "answer?" prompt, yes.

Yes, one should be notified. But probably only a bubble or something in the
log, not a incoming call that you can't answer...

> The Call spec as written defeats part of the purpose of Approvers, which was to
> avoid taking up memory/CPU time/bandwidth for an operation that the user hadn't
> agreed to (being in a call). Perhaps that's a necessary sacrifice to make VoIP
> reliable, though - you want to start the ICE process as quickly as possible,
> right?

The Call spec definitely breaks Approvers, hence me proposing something else.
The amount of RAM/CPU/etc that will be used to just connect the call without
accepting it is minimal, even for an embedded device.

> It's possible for a Call Handler to be an Observer, Claim() the CDO
> non-interactively, and deal with notification and "user-approval" internally. 
> think the N900/N9 might have done this? This would defeat parts of the purpose
> of Approvers while preserving others.

That doesn't really work with the current spec, what if the approver gives the
channel to a different handler? Well we've lost, because we can't change
handlers.

> The other major purposes that I can remember for Approvers are:
> 
> [...]
>
> * Avoid divulging that the user is even online at all
>   if they don't want to talk to the remote party. If you want to start
>   ICE as early as possible, then this isn't really possible, though.

This is entirely pointless. In XMPP, you need the presence to initiate a call.
And in SIP, the first thing the CM does is to send a "provisional ack" (PRACK)
telling the sender that it received the INVITE request.


> * Choose the Handler explicitly (for "always give the user every
>   possible choice" UIs) or implicitly (the user can be nagged by more
>   than one Approver, but can only say "yes" to one of them, and that
>   Approver's favourite Handler gets priority).

You can't change the Handler choice if you start it before the Approver anyway.

> One reason for multiple Approvers is "the full-screen media player use case".
> While running, a full-screen media player which you can run on your desktop or
> a dedicated machine (I think the one we discussed was Elisa?) wants to be an
> Approver so *it* can notify you of incoming calls; Empathy/Shell in the
> background will still notify you, but not visibly, because Elisa is in the way.

I think that case could be handled by having a well-known name that the
full-screen app can take over as long as it does it before the call comes in.
We could use something like Lennart's ReserveDevice spec
http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt 

> > For the NEXT branch, I suggest we re-work the approver/handler process around
> > the same principles for Call/FT/Tubes:
> > 
> > - Have a single Handler per type and call it right after observers
> 
> How can this work if you have both Empathy and telepathy-kde installed? Would
> they both have their Handler not be activatable, and run it as a side-effect of
> running a main process or entering the desktop session?
>
> In the Elisa use-case, how does Elisa take over from Empathy or telepathy-kde
> and impose itself as the preferred Handler? 

I think one solution is to have some kind of configuration that is set on
mission-control by the desktop-specific session manager maybe ? Or add some
keys to the .client file like .desktop files have.

> (Not entirely a rhetorical question: one possible answer is to do clever things
> with D-Bus name-ownership semantics - but that requires a special case for Call
> channels in the spec, rather than using generic dispatching machinery that
> doesn't know about channel types, and I think that'd be a backward step.)

I think we should re-work all channel types. For Jingle file-transfers, it
probably makes sense to work like Calls (as a file transfer that doesn't
connect is pretty much useless). Same thing can be said of any kind of tube
where the IBB mode isn't fast enough (for VNC tubes for example).

> The same questions apply to Text channels.

If you ask me, p2p Text channels should probably only be handled by the logger.
And other apps should access the data through the logger. I believe this is how
the N9 works (where tracker is their logger)?

> > - Drop the DispatchOperation (do we really have any case where you dispatch
> > more than one channel at the same time).
> 
> (We do, in MUC Tubes channels, but nobody copes with it.)

So it's pretty much pointless..

> The CDO needs to exist in MC in some form - it contains most of the logic for
> actually dispatching channels (at least since I refactored it - before I did
> that, McdDispatcher was giant and impossible to understand). Channel requests
> also have a secret CDO which isn't visible on D-Bus, but exists internally.

How it's implemented inside MC isn't really important imho.

> It'd be possible to have the dispatcher D-Bus API be entirely in terms of
> calling a method on the ChannelDispatcher and passing the Channel (or
> Channels?) you're talking about as an argument,  but I don't think that'd help
> clarity.

I think the Approval API really needs to be on the Channel itself, not on some
other object inside MC, that's the basic problem here. I should not that
FileTransfer, Tubes and Call all have a Accept() call of some kind.

> The CDO is also somewhere we can put things that are part of MC's state, but
> not part of the Channel in the CM. There's not much of that yet, but the list
> of possible handlers is there, and I think it's somewhat important to have it
> as an extension point for the future. (In outgoing calls, the ChannelRequest
> takes on this role, which is partly why the CDO isn't made visible on D-Bus.)

I think we should avoid designing for things that may or may not exist at some
point in the unpredictable future, as unpredictable things tend to not be what
we expect them to be. And we should rather concentrate on problems that exist
today with the things that we are trying to achieve.

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