[Telepathy] StreamedMedia/Call spec ambiguities

[Olli Salli]

On Mon, Apr 4, 2011 at 2:54 PM, David Laban <alsuren at gmail.com> wrote:
>> Hi spec beards and CM authors,
>>
>> how certain details of call signaling should work seems to be an
>> endless source of confusion. Namely, I've received numerous bug
>> reports about telepathy-qt4 reporting strange combinations of the
>> stream direction and state values, which have boiled down to tp-qt4
>> actually correctly reporting what the CM told it, but the CM signaling
>> having questionable logic, which seems also inconsistent between the
>> different CMs. Turns out the spec isn't really explicit enough on what
>> the correct behavior would be.
>>
> The various implementations of StreamedMedia are not very consistent in any of
> their behaviour. This is because the spec started out in the wrong shape and
> it scared off anyone seeking to make it better (indeed, I have chosen to
> mostly not respond to your StreamedMedia comments).
>

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?
- 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?
- It's at least very much wrong that Gabble reports all fresh
StreamedMedia streams to be actively bidirectional (instead of remote
send being pending), right?

Consider specifically the use case of having an ongoing voice call,
and then upgrading it to a audio-video call. Currently gabble has in
its RequestStreams return in this case the following (it also happens
to be the case that the remote doesn't even have a camera):

  array [
      struct {
         uint32 2 // stream ID
         uint32 2 // handle of the remote contact
         uint32 1 // type (Video)
         uint32 0 // current state (Disconnected)
         uint32 3 // current direction (Birectional)
         uint32 0 // pending send flags (None)
      }
  ]

A while later, a StreamDirectionChanged is emitted, redundantly
reporting that the direction of stream 2 is 3 (Bidirectional) with no
pending send flags! Only very, very much later it is emitted again,
with direction 1 (send only) and nothing in pending, I guess when
gabble receives the info that the remote isn't going to send to us
from the network.

-- 

Br,
Olli Salli