[Bug 24936] Channel.Type.Call (StreamedMedia 2.0)

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24936





--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-27 08:33:26 PST ---
Assorted comments about this spec:

I've hijacked the spec branch as smcv/call to make editorial changes,
clarifications, etc. that I'm reasonably sure about. See that branch:

*
http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/call
* http://people.freedesktop.org/~smcv/telepathy-spec-call/spec/

Stream_Transport_Type takes values Raw_UDP, ICE, GTALK_P2P, MSN and WLM2009.
Why not Raw_UDP, ICE_UDP, GTalk_P2P, WLM_8_5 and WLM_2009, which would be the
obvious mapping from the MediaSignalling transports? Is there some other source
we're trying to remain consistent with? (The handler-capability-tokens in Call
should be kept in sync with these.)

Is Call_Flag_Ringing meant to work on outgoing 1-1 calls, or only on incoming
calls?

Does Call_Member_Flag_Ringing make sense in conference calls? Is it really
useful to be able to have a conference call in which Will is a member and
Sjoerd has the Ringing flag?

If Call_Flag_Held means locally held (I believe it does), could we rename it
accordingly?

I believe I've addressed all the points brought up in the spec meeting, and
applied "spec-linting" to the Call channel type. I haven't looked at the
subsidiary objects in detail yet - it's taking longer than I expected!


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.