[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 Feb 14 19:03:18 CET 2011


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

--- Comment #13 from Olivier Crête <olivier.crete at ocrete.ca> 2011-02-14 10:03:18 PST ---
The goal of the negotiation is to reduce all descriptions to a single one that
is acceptable to everyone. You have to think of a multicast group where the
exact same media stream is sent to everyone. Farsight2 will accept the Codec PT
from the first peer as-is, but will override those of any subsequent peer with
its own. If you need to encode differently for different people, you need to
have multiple contents.

If in the muji-style stuff we want to have different mixers that produce
different formats, then we need to split Content.Media from Content... and make
it a subsidiary object and have a Call->Content->ContentMedia->Stream->Endpoint
hierarchy... (because a stream cannot cross multiple ContentMedia in that case)

Your streaming framework might want to renegotiate in many cases:
1. You realize that you need more bandwidth.
2. You're a gateway and the other side is changed
3. You try to stream from a file, and you change files, you want to see if the
other side can do more optimal settings?
4. You want to record a stream and would prefer the other side to have
different codecs

That said, the Renegotiate param is only for XMPP, in SIP you always
renegotiate in practice (since the way to update codecs is to do a re-invite
with everything but the codecs not changing).

-- 
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 mailing list