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. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
