[Telepathy] Just what is stream directionality?

[Peter Saint-Andre]

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.

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090316/10840e01/attachment.bin