[Telepathy] Just what is stream directionality?

[Sjoerd Simons]

On Mon, Mar 16, 2009 at 09:50:51AM -0600, Peter Saint-Andre wrote:
> On 3/13/09 4:11 PM, Sjoerd Simons wrote:
> > On Fri, Mar 13, 2009 at 05:51:54PM +0000, Simon McVittie wrote:
> >
> >> 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't force the other side to send media. Or at least the concept
> doesn't make much sense to me. Maybe they send and maybe they don't.
> 
> > 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.
> 
> I don't see a strong need for this, but perhaps I'm missing something.
> 
> >> 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. 
> 
> Correct.
> 
> > The senders property in
> > jingle as at best informational. 
> 
> I'd say it is potential -- if the value is "both" then the parties agree
> that media *might* flow in both directions, but nothing guarantees that
> it *will* flow.

That's another way of looking at it. But keep in mind that there is a race
condition here. A client will usually the direction and start sending the media
at the same time, so one *might* get media before senders is changed to reflect
this. The other client *must* be prepared for this to give a good experience.

> > 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.
> 
> /me shrugs
> 
> If we need to change this, let me know. But it seems that this is just
> the messy reality of media exchange.

I don't think it needs to be changed, my main point is that changing it doesn't
actually make things better :)

  Sjoerd
-- 
(1) Never draw what you can copy.
(2) Never copy what you can trace.
(3) Never trace what you can cut out and paste down.