Structure for group conversation

[James Pellow]

Greetings,

This is our first test of Medooze.  I appreciate the approach you are taking with the project.  The code is very understandable and you have good examples.  We are creating a group chat application where users are free to come and go.  Each new client may or may not send media, but each should receive all available media.

Here are my questions:

* First, for a number of reasons it seems best practice with p2p WebRTC has been to create a separate receive and send transport.  Some of the issues may be solved by perfect negotiation which it appears can be implemented with Medooze(next question)?  With the Medooze, are separate send and receive transports still best practice?

* In the transport, I don't see any logic preventing me from being the polite side in the perfect negotiation scheme.  It appears to be as simple as just applying an offer when I get one and sending an answer.  If I just sent out an offer and I get an offer I can just set it as the remote description, generate an answer and be done.  If I get an answer later I can just set that as my remote description and be done.  No need for any kind of rollback.  Is this correct?

* I'd like to use the SDPManager, however I've run into a problem with it.  Looking at the source code, I can't generate a local description that includes tracks I want to send from the SFU before it has received an offer from the client.  Since I'm often not sending media from the client, just receiving, I would have to send a trackless offer from the client to setup the transport with.  Unfortunately at least chrome doesn't send ice information along with a trackless offer and the Medooze transport crashes on setting a remote description that doesn't include ice information.  The solution seems to be to not use the SDPManager on the server side and manually create a Transport to publish media through.  I can easily create a local offer and send that to the client. Then I don't need an offer from the client side.  A nice feature of the SDP manager would be to allow setting up tracks to publish prior to calling createLocalDescription.  Is there another way that I'm missing?

Thanks for your help.

Best Regards,

James

[Sergio Garcia Murillo]

Hi James

On 04/12/2020 1:20, James Pellow wrote:

Greetings,

This is our first test of Medooze.  I appreciate the approach you are taking with the project.  The code is very understandable and you have good examples.  We are creating a group chat application where users are free to come and go.  Each new client may or may not send media, but each should receive all available media.

Here are my questions:

* First, for a number of reasons it seems best practice with p2p WebRTC has been to create a separate receive and send transport.  Some of the issues may be solved by perfect negotiation which it appears can be implemented with Medooze(next question)?  With the Medooze, are separate send and receive transports still best practice?

I have never used different send/recv transports, you can make medooze behave that way, but never understood the reasoning behind having them separated.

* In the transport, I don't see any logic preventing me from being the polite side in the perfect negotiation scheme.  It appears to be as simple as just applying an offer when I get one and sending an answer.  If I just sent out an offer and I get an offer I can just set it as the remote description, generate an answer and be done.  If I get an answer later I can just set that as my remote description and be done.  No need for any kind of rollback.  Is this correct?

Yes, the transport has no issues with race conditions on SDP negotiation. You can add/remove tracks/streams as needed.

* I'd like to use the SDPManager, however I've run into a problem with it.  Looking at the source code, I can't generate a local description that includes tracks I want to send from the SFU before it has received an offer from the client.  Since I'm often not sending media from the client, just receiving, I would have to send a trackless offer from the client to setup the transport with.  Unfortunately at least chrome doesn't send ice information along with a trackless offer and the Medooze transport crashes on setting a remote description that doesn't include ice information.  The solution seems to be to not use the SDPManager on the server side and manually create a Transport to publish media through.  I can easily create a local offer and send that to the client. Then I don't need an offer from the client side.

Medooze does not require any kind of ICE information to work as it is an ICE lite server meant to have a know public ip address. Could you open a new issue with more details of the how the "transport chrashes" and the SDP generated by chrome?

  A nice feature of the SDP manager would be to allow setting up tracks to publish prior to calling createLocalDescription.  Is there another way that I'm missing?

Can you open a new issue with the feature request? I think it could be interesting to add support for it too.

I particularly like to use the client lib better than the SDP manager:

https://github.com/medooze/media-server-client-js

Thanks for your help.

Best Regards,

James

--
You received this message because you are subscribed to the Google Groups "medooze" group.
To unsubscribe from this group and stop receiving emails from it, send an email to medooze+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/medooze/4bfa46c1-5f94-4a59-b333-004355270cffn%40googlegroups.com.

[James Pellow]

Hey Sergio,

Thanks for your reply.  I'll take a look at the media-server-client-js project.  The reasons I've separated send and recv in the past was because then you only had one side sending out offers for a given transport, which reduced the race conditions you faced in browsers.  I also had issues with the msids attached to streams and tracks on the answering side not matching the tracks themselves, which was never an issue on the offering side.  I don't think either of those issues are really at play here.

I'll create the tickets you requested.

Best Regards,

James