[Telepathy] StreamedMedia/Call spec ambiguities

[Olli Salli]

On Tue, Apr 5, 2011 at 4:59 AM, Youness Alaoui
<youness.alaoui at collabora.co.uk> wrote:
> Hi,
>
> On 04/04/2011 10:57 AM, mikhail.zabaluev at nokia.com wrote:
>> Hi,
>>
>>> -----Original Message-----
>>> From: telepathy-
>>> bounces+mikhail.zabaluev=nokia.com at lists.freedesktop.org
>>> [mailto:telepathy-
>>> bounces+mikhail.zabaluev=nokia.com at lists.freedesktop.org] On Behalf Of
>>> ext Olli Salli
>>> Sent: Monday, April 04, 2011 4:24 PM
>>> To: David Laban
>>> Cc: telepathy at lists.freedesktop.org
>>> 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
>> telepathy at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>



-- 

Br,
Olli Salli