As for your other question, a colibri channel is used to transfer multiple RTP streams/WebRTC streams/WebRTC tracks, same goes for the RtpChannel implementation in the bridge. I don’t expect this to change anytime soon, if ever.
In Unified Plan, a track is the same as an m-line, so therefore, some sort of Unified Plan translation needs to happen anyway because of colibri.
As for why we do we decided to do this translation at the SDP level, you can go ahead and read the README document of the sdp-interop project that Antony has linked.
I hope this clarifies things a bit.
On Mar 28, 2018, at 6:30 AM, John Hemming <firstname.lastname@example.org> wrote:
I tried using "require.js", but that did not seem to want to work.
However, on the basic question it is more complex as it raises a question as to whether an RtpChannel has a one to one relationship with an m section in an SDP or not.
From the unified plan perspective you could end up with more than one AudioChannel for each endpoint. (If I understand things correctly which sometimes I do and sometimes I don't).
On 28/03/2018 11:10, Antony Stone wrote:
On Wednesday 28 March 2018 at 11:56:56, John Hemming wrote:
I think I am right that Jitsi assumes browers are using Plan B for the
SDP and converts any unified plans (Firefox) to plan B.
Is there a plan as to what to do when all the browsers are using
Unified Plan (which is what I understand is possible/likely). Obviously
it is possible to convert back to Plan B or to constrain what the
browsers are doing to limit the number of streams in some way. However,
it strikes me that there could be some issues here.
If there is a plan could someone please tell me what it is?
https://github.com/jitsi/sdp-interop may give you useful information on this.
dev mailing list
Unsubscribe instructions and other list options: