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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jan 5 23:54:28 CET 2010


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


Olivier Crête <tester at tester.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tester at tester.ca




--- Comment #25 from Olivier Crête <tester at tester.ca>  2010-01-05 14:54:27 PST ---
I just noticed this bug exists, some comments on the candidates API comments:

 (In reply to comment #12)
> * It is claimed that STUNServers cannot change once the stream has been
> created. This seems likely to be a lie, given that we now have change
> notification of a sort? It should have proper change notification, though, if
> it can change (perhaps just an "added" signal).
> * Likewise, what is RelayInfo's change notification?

There probably should be separate signals for STUN servers and RelayInfo
changing.. And the signal should probably contain the relevant information
instead of having to do another round trip.

> * Does it ever make sense to remove a local candidate? If it does, we'll need a
> LocalCandidatesRemoved signal

No, it never makes sense to remove one candidate. The only case where you want
to remove candidates is when doing a ICE restart and that means removing all
candidates. And we probably want a special API for that (to be added later I
guess). Doing a ICE restart would tell tp-fs to give all the candidates again.


> * How many times can LocalCredentialsSet happen? 0-1? 0-infinity?

Once.. but they will be re-set if a ICE restart is requested.

Btw, how does the client set the local credentials ? It should be a method, not
a signal.

> * Does SetCredentials() change LocalCredentials? How many times can it be
> called?
> 
> * What is a candidate anyway? What is a component anyway? (Perhaps this
> interface is only meant for use by people who speak fluent RTP, but I'm only
> dimly aware of what a candidate is...)

Yea, that should be documented.. With references to the ICE almost-RFC.

> * If I infer correctly that LocalCredentials, LocalCandidates come from the
> streaming implementation and nowhere else, do they actually need to be readable
> at all, or can they be "write-only" (i.e. not exist as properties at all, only
> as setter methods)?

I tend to agree here that they can't be re-used anyway, so there is no reason
to make them readable.


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


More information about the telepathy-bugs mailing list