On Tue, Apr 5, 2011 at 4:59 AM, Youness Alaoui <[email protected]> wrote: > Hi, > > On 04/04/2011 10:57 AM, [email protected] wrote: >> Hi, >> >>> -----Original Message----- >>> From: telepathy- >>> [email protected] >>> [mailto:telepathy- >>> [email protected]] On Behalf Of >>> ext Olli Salli >>> Sent: Monday, April 04, 2011 4:24 PM >>> To: David Laban >>> Cc: [email protected] >>> Subject: Re: [Telepathy] StreamedMedia/Call spec ambiguities >>> >>> Following IRC discussion, let me condense the current issues with >>> StreamedMedia and its Gabble implementation into a few bullet points: >>> >>> - Is the direction of a stream in a StreamedMedia channel a valid >>> concept unless the Stream is in state Connected? >> >> Specifying that a CM should emit StreamDirectionChanged with actual >> direction (if different from the assumed Receive/PendingLocalSend) before >> signaling the stream as Connected could be a useful cop-out for clients who >> are not requesting the streams and only receive the signals. >> >>> - What should the direction be reported as for a freshly requested >>> stream for which we don't yet know if the remote user accepts to send >>> on, or even can send? >> >> Telepathy-Rakia should return the stream with direction Receive and the >> Pending_Remote_Send flag. >> What Gabble does is probably bong, ignored by all clients because they >> really listen for StreamHandler signals.
Umm, you mean Send + Pending_Remote_Send, right? That would be the natural complement for the Receive + Pending_Local_Send combination mandated for remote-initiated streams. > > I might be wrong here, but from what Olivier told me, although it is not > specified in any way in the spec, StreamedMedia direction when the call starts > is used to represent the "maximum direction". So Gabble setting it to BOTH, > means that the protocol supports that the call may be sending, receiving or > sending+receiving... eventually. OK, so the way to distinguish locally requested video streams in which the remote has accepted to send and in fact can send is to wait for the stream state to become connected and only check the stream direction then? So in essence, the stream direction (and pending send flags) would be an indication of "what might be possible" for pre-Connected streams and, be the actual direction only in the Connected state? > In the case of MSN for example, where there are different audio/video call > protocols that can be used, there is a unidirectional protocol for webcam, and > that initial direction would be used to specify to the UI/user whether to show > that the "<contact> wants to send his webcam" or "<contact> wants to receive > your webcam" or "<contact> wants to start a video chat". Shouldn't the pending send flags be used for that? To me, the sensible ways to signal those cases would be: <contact> wants to send his webcam: Direction: Receive, Pending: none (remote indicated they want to send, but nobody else is asked to send) <contact> wants to receive your webcam: Direction: None, Pending: local send (nobody has indicated being willing to send, but we are being asked if we would want to send) <contact> wants to start a video chat: Direction: Receive, Pending: local send (the remote wants to send, and we are asked if we would want to send too) This already conveys the eventually possible stream direction perfectly in my books: a pending send can either become active send (accept) or disappear completely (reject). > > At least, that's what Olivier told me, he also said that it's not specified > anywhere in the spec, but that's what he was told the CM implementations > should > do. Someone else probably needs to confirm though. > Hope it sheds some light on the matter (although it might generate the > opposite > effect :) ). Yeah, I'm trying to make the spec more explicit here exactly because people have interpreted "what they need to do" and what they in fact CAN do in such a multitude of ways currently :) > > Youness. > >> >> Best regards, >> Mikhail >> _______________________________________________ >> telepathy mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/telepathy > > > > _______________________________________________ > telepathy mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy > > -- Br, Olli Salli _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
