[Telepathy] StreamedMedia/Call spec ambiguities

[Olivier Crête]

On Mon, 2011-04-04 at 21:59 -0400, Youness Alaoui wrote:
> On 04/04/2011 10:57 AM, mikhail.zabaluev at nokia.com wrote:
> >> -----Original Message-----
> >>
> >> 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 :) ).

If I'm not mistaken, that's the direction in the
SessionHandler.NewStreamHandler() signal, not the one in StreamedMedia..
In my experience, clients should call RequestStreamDirection with
whatever they want and the listen for StreamDirectionChanged and then
re-call RequestStreamDirection until they get what they want. That's the
only way I'm sure works with every CM.

-- 
Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20110404/b8275fbd/attachment.pgp>