[Telepathy] StreamedMedia/Call spec ambiguities

[Olli Salli]

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.

StreamedMedia.RequestStreams has no way to specify the initial
directionality of the streams, and is documented as returning a
bidirectional stream if possible. It's not specified at all which
local / remote sending states the streams that auto-pop-up in a newly
added Call.Content should be.

Gabble does the following in its StreamedMedia stream constructor:

  if (priv->created_locally)
    {
      g_object_set (stream, "combined-direction",
          MAKE_COMBINED_DIRECTION (TP_MEDIA_STREAM_DIRECTION_BIDIRECTIONAL,
            0), NULL);
    }

In other words, streams are unconditionally created being actively
bidirectional, with neither local nor remote sending marked as
pending. But what if we created a video stream (upgrading from
voice-only call), and the remote doesn't even have a camera? Then we
have signaled that "Media are being sent and received", although
clearly receiving video would be impossible. Sure enough, at this
stage, the stream is also reported as being disconnected. Should we,
in fact, define that stream direction is undefined for non-Connected
StreamedMedia streams, and should not be used in any way? Besides that
being just an admission of underspecification, in Call the Streams are
separate objects, and can't have "undefined" attributes unless we add
some kind of Undefined SendingState value for the corresponding D-Bus
properties on the object to have in this case.

I think it would be sensible to specify that streams MUST be created
as "*eventually* bidirectional". This would mean that the remote
sending state would be initially reported as *pending* and not
actively sending, and would then change to being actively sending if
the remote accepts and has a camera etc, or just unidirectional stream
with us sending and none pending if we find out that isn't going to
happen (the remote actively rejected, say). Of course, if the CM has
some protocol-level knowledge that the remote doesn't have the
capability of send video, it might instantly change to remote not
sending, and not pending (in the case where the remote can receive
video, but just can't send because of e.g. missing camera - this
distinction isn't conveyed by the ContactCapabilities interface).

More generally, even the fact that we claim to in a sense be actively
locally (and currently also remotely) sending in a non-connected
stream has also caused confusion, which would still remain even with
the adjustment of requiring remote send to be pending until we know
whether they actually send or not. This is a separate although related
issue: we could define that the direction reported for non-connected
streams is the one they will have once connected (or which they did
before they were disconnected/errored -> removed), unless actively
changed locally or remotely. So, in a sense the stream state would be
established as the stronger indication of whether any media transfer
actually is taking place.

Of course, all of this could be mimicked client-side in tp-qt4 by
twisting the CM-reported values so that they appear "sensible". I
don't think this is a good idea at all, though. That would just
establish yet another interpretation of the (ambiguous) spec on what
the "sensible" combinations of values actually are, and how the other
combinations should be interpreted - potentially turning some actually
sensible and valid cases to something else.

-- 

Br,
Olli Salli