[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 #14 from David Laban <david.laban at collabora.co.uk> 2011-02-14 13:55:36 PST ---
I'm just going to brainstorm the SIP call forking case here so that we can know
that the API is sane.

Make a call
channel pops up
content pops up
MediaDescription pops up empty
You fill it with codecs = h264 and vp8
Stream pops up
You fill it with candidates
INVITE sent

answer comes back from A as RINGING, with candidates and codecs = h264
endpoint pops up with candidates
RemoteMediaDescription changes to codecs = h264, or does it stay empty?

answer comes back from B as RINGING, with candidates and codecs = vp8
endpoint pops up with candidates
RemoteMediaDescription changes to codecs = vp8, or does it stay empty?

endpoint A picks up
A new MediaDescriptionOffer pops up? (should we clarify this in the spec
preamble?)
RemoteMediaDescription changes to codecs = h264
The stream goes to bidirectional

I think that sounds passable. We can't support early media unless
RemoteMediaDescription is keyed by remote endpoint path or something, but do we
care?

Can you explain why RemoteMediaDescription is keyed by remote contact (and
separate from LocalMediaDescription), if the aim is to make them the same by
the end of the negotiation? I don't think I've quite understood this part of
the spec.

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