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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #60 from Sjoerd Simons <sjoerd at luon.net> 2010-06-24 05:24:41 PDT ---
(In reply to comment #11)
> (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.

#28688

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

see also  #28708
> 
> > * 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

#28720 

> > * 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
> ? :)

#28721

> > * 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: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.