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

[bugzilla-daemon at freedesktop.org]

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





--- Comment #11 from Sjoerd Simons <sjoerd at luon.net>  2009-12-01 05:25:29 PST ---
(In reply to comment #9)
> (In reply to comment #7)
> > 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.)
> 
> I've changed these in my branch, except that I left ICE as-is rather than
> renaming to ICE_UDP in case we want to use it for ICE-TCP. (Do we?)

Probably better to just call it ICE_UDP for clarity. If ICE-TCP ever happens we
probably won't use it on voip calls.

> More questions/gaps, having looked at Content and Stream in detail:
> 
> * What significance/rationale does the Content.Name have? I assume that this is
> the mostly-opaque content name from Jingle? 
Yes
> Do clients really need to be able to specify this? 

My nefarious plan is to start putting better names in it from the UI, because i
want a nice demo UI that can both send a camera and say slides. In case of
having multiple streams from the same content this names suddenly become a lot
more useful for the UI.

> Do they have to be able to cope with being given a Name that
> wasn't what they asked for?

Yes, the Name is only advisory. One shouldn't rely on it in any way.

> * Content.Disposition seems to be a bit of a mixed bag. Should it really be an
> enum, or should it be a flag-set?
Enum is correct, olivier had the correct remark that the protocol doesn't
always tell you things have early media. So maybe it might be better to just
have an Initial boolean property

> * Please explain what's going on with "early media"?

We just don't know... Jingle has a way of telling you that a stream is going to
use early media, SIP doesn't in any way and just sends you media whether you
want it or not. Which makes me think we shouldn't need to distinguish this on
the non-media interface after all

> * Is Call.Accept canonically called Accept (as in Call) or Answer (as
> referenced in Content)? I've assumed the former.

Accept, it used to be Answer at some point i think and they got out of sync.
Especially now both sides need to call Accept() Answer doesn't make sense
anymore :)

> * Should Sending_State have a state for "I've asked the remote contact to shut
> up, but they haven't", for symmetry with Pending_Send?

Maybe. Maybe have <tp:enumvalue suffix="Pending_Shutup" value="4"> or somesuch
? :)

> * Am I right in my clarifications of Stream and sending states? I got quite
> confused...
Seems correct.

> Still to spec-lint: Content.I.Media, Stream.I.Media and Endpoint.

I've merged your branch as-is. The one comment i have is that we should
probably make it so that there is always at least one content. Similar in
spirit to:
http://xmpp.org/extensions/xep-0166.html#def-action-content-remove

As in if you're about the remove the last content, you should just end the call
instead. Open question here is if trying to remove the last content will result
in an error or the call being automagically hung up.. 


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