[Telepathy] Just what is stream directionality?

[Simon McVittie]

On Fri, 13 Mar 2009 at 17:51:54 +0000, Simon McVittie wrote:
> In the process, I've run into a problem with stream directionality: we
> don't always know the direction of streams! When StreamAdded is emitted, it
> doesn't tell the client about the stream direction (although when
> RequestStreams returns, it does).

Stream state (Disconnected, Connecting, Connected) has the same problem, but
I propose to solve this by mandating that newly added streams are always in
the Disconnected state, and that the connection manager MAY immediately emit
StreamStateChanged to set the real state (if different).

> How Gabble implements it
> ========================
> 
> Streams created by the remote contact are created with a direction set by
> the Jingle content, except that if they asked for us to send, we transform that
> into Pending_Local_Send so the user can approve it.

This basically means that in "most" cases, remotely-created streams are
(Receive, Pending_Local_Send)...

> Streams created by us are set to Bidirectional immediately; the remote contact
> might refuse this by changing the direction at their end.

... and locally-created streams are Bidirectional.

> How telepathy-sofiasip implements it
> ====================================
> 
> Streams created by the remote contact are receiving and pending local send,
> which seems right.

Consistent with telepathy-gabble.

> Streams created by the local contact are receiving and pending remote send,
> which seems to me to be clearly wrong. Surely they should be sending and
> pending remote send?

Not so consistent...

> What StreamAdded should imply
> =============================
> 
> Possible solutions seem to be:
> 
> * Arbitrarily pick one of the possible directions (which one?) and declare it
>   to be the default. In all other cases, emit StreamDirectionChanged
>   immediately after StreamAdded.
> * Require clients to call ListStreams after every StreamAdded to find out
>   what's *really* going on.

To keep things simple for clients, I'm inclined to declare that from now on,
CMs MUST emit StreamDirectionChanged at least once per StreamAdded, to fill
in the missing information.

Perhaps a better ordering would be to emit SDC *before* the corresponding SA,
to signal "you are about to receive StreamAdded for the stream whose ID is 42:
when you do, its direction will be..."; this means that when dealing with
0.17.22-compliant connection managers, there will not be a "limbo" period in
which we can only guess the direction.

Which direction to assume when dealing with pre-0.17.22 CMs is an open
question. Having incoming (remotely created) streams send media immediately
would be a privacy violation, but having us expect to receive media
immediately is fine.

I'm inclined to say that when dealing with pre-0.17.22 CMs, the client
SHOULD assume that the stream is Receive and Pending_Local_Send; if the client
is the one that created the stream, then it will learn the real directionality
soon (from the return of RequestStreams).

    Simon