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.
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. 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". 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 :) ). Youness. > > Best regards, > Mikhail > _______________________________________________ > telepathy mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
