[Telepathy] StreamedMedia/Call spec ambiguities

[David Laban]

> 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).

If you want to write some spec patches for StreamedMedia, add me to the CC 
list when you post them. Patches which point out undefined behavior are most 
welcome.

I am in the process of trying to get the new Call spec into a useful state. If 
you want to take a look at my working copy [1] (once I get the bugs worked 
out) and point out the glaring omissions.

[1] http://people.freedesktop.org/~alsuren/telepathy-spec-call/spec/ 

> 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.
In call, we use Call_Content_Disposition for this. If you could read that part 
of the spec and make sure it makes sense (/does what you need), that would be 
really helpful.

> 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.
> 
We use Sending_State = Pending_Send for this in Call, if I understand you 
correctly (if I've misunderstood, please correct me).