[Bug 31274] Call: NewCodecOffer signal should contain the properties of the optional CodecOffer interfaces

[bugzilla-daemon at freedesktop.org]

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

--- Comment #20 from David Laban <david.laban at collabora.co.uk> 2011-02-16 10:42:40 PST ---
I pushed some changes to to explain my thoughts.

http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/mediadesc-update

== "Clarify UpdateLocalMediaDescription's purpose." ==
is mostly a demonstration of how the semantics of your Renegotiate parameter
for UpdateLocalMediaDescription gets messy very quickly, so please don't merge
it into master. If someone proposes some good names for a pair of functions to
replace this function (I'm not feeling very imaginative) that would be good. I
might not actually understand the use-case for that properly though, so please
read my commit and correct my understanding if necessary.

I found myself struggling to document the difference between a
NewMediaDescriptionOffer signalled because of an incoming SDP-style offer and a
NewMediaDescriptionOffer signalled because of an SDP-style answer. I'm pretty
sure that either Farstream or Rakia should be reacting differently in each
case, so I documented the latter as "the CM will almost-silently drop the
arguments to Accept on the floor for the latter case" but there's no way to
distinguish between the two cases in advance, so this doesn't seem like the
right solution.

Incoming MediaDescription updates that don't require negotiation (see my
concerns about UpdateLocalMediaDescription, above) are another case of not
being able to tell the difference between "need to reply to this" and "no more
negotiation required".

I was thinking of splitting the NewMDOffer signal into NewMDOffer, NewMDAnswer
and NewMDUpdate or something, but sjoerd said that it complicates the Farstream
side unnecessarily. Should I be digging into tpfs' mechanics to convince myself
that it doesn't need to distinguish between offer, answer and update?

== The other commits ==
The other commits document some other subtle bits of the API. If you could skim
read them and make sure they actually describe the api correctly, that would be
good. Hopefully they don't stumble on any subtle api limitations.

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