[jitsi-dev] Unified Plan and Plan B


#1

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?


#2

https://github.com/jitsi/sdp-interop may give you useful information on this.

Antony.

···

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?

--
What do you get when you cross a joke with a rhetorical question?

                                                   Please reply to the list;
                                                         please *don't* CC me.


#3

Thank you for this. There is an interesting question as to what is an easy way to take javascript like this and make it work with other javascript without going for a full blown node or browserify implementation. In the end I am modifying it to avoid using "require".

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.

Antony.


#4

Hi John,

I believe there is a way to compile a Javascript module into a standalone lib. I don’t remember how this is done off the top of my head, maybe some other member of the community can comment on that. If it’s useful for people, it’s possible to provide standalone releases of the library.

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.

···

-
George

On Mar 28, 2018, at 6:30 AM, John Hemming <john@hemming.email> wrote:

Thank you for this. There is an interesting question as to what is an easy way to take javascript like this and make it work with other javascript without going for a full blown node or browserify implementation. In the end I am modifying it to avoid using "require".

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.

Antony.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

I have done a bit of work on this and have found that with modifications relating to the case sensitivity of the protocol in the SDP (which is in upper case for Firefox, but lower case for Chrome and Edge) and taking the finger print from the session description rather than the media description, using sdp interop bodged to avoid using node or browserify and the rest interface will work with Firefox. I have tried to also get Edge to work. It doesn't work unless I download adapter.js when it works to the extent of creating an ICE connection (although I am not sure Datachannel is working the SDP answer says a=inactive and adapter.js keeps complaining about some things in the sdp linked to the datachannel) and also telling me that RTP is going to and from the bridge (according to bridge stats), but I am not actually getting any audio from my speakers.

Sadly Edge does not seem to have anything that explains what is happening with the audio element. I have tried to run Edge WebRtc with something that has sound, but not found anything that works (including things that work with Chrome or Firefox).

I note that meet.jit.si does not like Edge.

Are there any suggestions as to how to make Edge interoperate effectively with the bridge. I note that some of the RTCP packets fail parsing for the stats, but I don't think that necessarily matters (apart from reporting a ton of exceptions).

···

On 28/03/2018 12:30, John Hemming wrote:

Thank you for this. There is an interesting question as to what is an easy way to take javascript like this and make it work with other javascript without going for a full blown node or browserify implementation. In the end I am modifying it to avoid using "require".

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.

Antony.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

This is helpful thank you. I am just thinking about this. Obviously for webrtc each packet goes through the srtp encoding and decoding and finally you end up with the payload code and ssrc. Actually thinking about it they are bundled up in the same multiplexed session so it is only the SSRC (and payload) that indicates what m line is applicable.

The data channel is as I understand it going through SCTP. I haven't really tried to get into where that passes between the server and client. I wonder if in a sense it is a separate stream rather than another example of the media and audio streams.

···

On 28/03/2018 19:31, George Politis wrote:

Hi John,

I believe there is a way to compile a Javascript module into a standalone lib. I don’t remember how this is done off the top of my head, maybe some other member of the community can comment on that. If it’s useful for people, it’s possible to provide standalone releases of the library.

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.

-
George

On Mar 28, 2018, at 6:30 AM, John Hemming <john@hemming.email> wrote:

Thank you for this. There is an interesting question as to what is an easy way to take javascript like this and make it work with other javascript without going for a full blown node or browserify implementation. In the end I am modifying it to avoid using "require".

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.

Antony.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

I have played around with Edge and the WebRtc samples and have a reasonable evidenced working hypothesis that my problem with sound is acually that edge is not finding the right (or even any) sound driver and therefore it is sending the sound streams to no-where. At least nowhere that actually vibrates the air.

That is an interesting error. It may be that other people encounter this difficulty. It does, however, not appear to be a problem with the more complex thingies, but a relatively basic error in Edge in that it cannot cope with some configurations for webrtc.