[Bug 31274] Call: NewCodecOffer signal should contain the properties of the optional CodecOffer interfaces
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Jan 10 15:26:35 CET 2011
--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-01-10 06:26:35 PST ---
> + <p> If the remote codecs and other content information is available
trivia: are available
> + >NoRemoteInformation</tp:dbus-ref> property will be false
I'm a bit hesitant to have "negative" boolean properties if there's no good
reason for it (so I'd prefer to define HasRemoteInformation to be the inverse
of your NoRemoteInformation, and remove NoRemoteInformation).
> <h4>Changing codecs mid-call</h4>
> + accepted, then
trivia: trailing whitespace after "then"
+ <tp:member name="Remote_Contact" type="u" tp:type="Handle">
+ The remote contact this description refers to
Can this be 0?
+ <p>A map from contact handles to the descriptions as response.</p>
This could do with expanding. Do you mean: each key is a remote contact handle
(is 0 allowed here btw?), and depending how far into the negotiation we've got,
the value is either the description we have offered to that remote contact, or
the intersection of local/remote descriptions that we have negotiated with the
+ <arg name="MediaDescription" type="o">
trivia: Ugly_Case please (it matters somewhat in Qt-land)
In LocalMediaDescriptionsChanged and RemoteMediaDescriptionsChanged, is the map
a diff, or a new value for the property? (I assume it's a diff, so keys that
are omitted from the change notification stay the same.)
+ <arg name="Removed_Media_Descriptions" type="au">
tp:type="Contact_Handle" I assume? It'd be nice to clarify that members of this
list are removed from the keys of both maps (I assume that that's what
+ <property name="MediaDescriptionOffer"
In a multi-user call, can we have more than one of these active? I assume the
answer must be "no" - is that because it can't arise anyway, or is it enforced
by the CM not announcing a new media description until the previous one has
<p>Change notification is via the
+ <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> and
+ <tp:member-ref>MediaDescriptionOfferDone</tp:member-ref> signal.
trivia: ... signals.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ This object represents a remote Description Offer to which the local
+ streaming implementation should reply with its local Description
If Description is well-known jargon, perhaps you could hyperlink to SDP or
Jingle or something for the definition?
+ <p>Extra interfaces provided by this codec offer. This SHOULD
+ NOT include the Description interface itself, and cannot change
+ once the content has been created.</p>
trivia: this is neither a codec offer nor a content
+ <method name="Reject" tp:name-for-bindings="Reject">
+ Reject the proposed update to the remote description
+ FIXME add error codes and strings here
I hope there's a bug for that :-)
+ <p> This property will never be part of the DescriptionProperties used
+ to describe this object. If this property is true then the
+ DescriptionProperties describing this object will be empthy (as
+ there is no remote information to put in it)
DescriptionProperties seems like a dangling reference, which should be to
Media_Description_Properties; but you seem to be using
Qualified_Property_Value_Map directly, elsewhere.
Is the contact handle in a Media_Description_Offer and/or
Contact_Media_Description_Properties_Map redundant with the
Please open a bug for the Remote_Contact = 0 thing, unless you plan to leave
this bug open after merging to represent it.
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs