[Telepathy] Just what is stream directionality?

[Sjoerd Simons]

On Fri, Mar 13, 2009 at 05:51:54PM +0000, Simon McVittie wrote:
> 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.
> 
> If a call to RequestStreamDirection enables sending, we'll accept a
> pending local send if there is one; otherwise, we'll alter the "senders"
> attribute on the Jingle content to inform the peer that we would like to send
> them media.
> 
> When we move our own handle from local-pending to member state
> (= accept the call), all currently pending local sends are automatically
> accepted (i.e. we start sending if we were asked to).
> 
> Streams created by us are set to Bidirectional immediately; the remote contact
> might refuse this by changing the direction at their end.
> 
> If a call to RequestStreamDirection enables receiving, we tell the remote
> contact to send us media, and blindly assume that they will do so (the
> StreamDirectionChanged signal immediately indicates that we expect to receive)

You never have any guarantee that the remote side will actually send though.
You can argue whether it makes sense to request the remote side to start
sending immediately  (apart from when the call is initiating), as it should
always be something the user on the other side decides not their peer.

> If they refuse our request, they'll do so by removing the Receive direction
> later.
>
> This appears to be because the protocol has no concept of an
> intermediate/requested state. Conceptually, the stream is bidirectional
> as soon as we say it is, and the contact's only recourse is to change it
> back to (from their point of view) receive-only if they don't actually want
> to send us media. This doesn't really seem right, though - surely they send
> back *some* sort of affirmative response if they'll be sending us media?

If they'll be sending us media, you'll receive media. The senders property in
jingle as at best informational. If the remote side claims it is sending
(either because we changed the direction or they did) in jingle and you don't
receive either a content-modify for the direction or media/conneciton-checks
within some arbitrary time-limit you know something is wrong. This is all the
information you'll ever get.

To summerize, if you set them sending, they either nack it or send us media.

In case there would be an affirmative message, it would just be for debugging.
You always have to listen for incoming traffic as their media will probably
arrive on your side faster then the message through the signalling.. If you get
the message before the media, you know something might be wrong or maybe you
just need to wait a little bit... Also know as not very usefull.

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

The first option is doable because only have two CM implement streamed media
atm (tp-sofiasip and gabble) and we can just fix them.. And it seems vaguely
preferable to prevent a mandatory extra roundtrip.


  Sjoerd
-- 
In 1869 the waffle iron was invented for people who had wrinkled waffles.