Unified Plan 3-way handshake and PeerConnection API spec (and current implementations)

[Christoffer A]

I'm looking into how to signal multistream in a conferencing scenario and how it's compatible with the PeerConnection API spec primarily, and also with the current state of implementations.

From what I understand UP suggests a 3-way handshake to solve the problem of when a party creating an initial offer does not know the number of remote streams ahead of time (https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.5) (and Plan-B also seemed to suggest a 3-way handshake, https://tools.ietf.org/html/draft-uberti-rtcweb-plan-00#section-4.2).

Question: Assuming my application would perform 3-way handshake where the conference node (SFU/MCU) would send a subsequent Offer in the reverse direction of the initial Offer (initial direction would be Client -> SFU/MCU) (as per https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.5), does the PeerConnection API spec allow the application to simply pass subsequent Offers to setRemoteDescription and the intention of the API spec is that the implementation should detect the added / removed streams, enable additional transports if needed, etc? 

Use of "PrAnswer" and methods to reduce of signalling glare seems to still be very much work-in-progress and in draft, so I'm also interested in getting pointers to whether the "basic" 3-way handshake outlined above is possible and/or recommended with the current state of web browser implementations, and assuming that regular "full blown" Offer/Answers are being exchanged.

Thanks / Christoffer

[Peter Thatcher]

I'm assuming you mean that the client is the offerer.

In the spec currently, one can:

- bundlePolicy: max-bundle

- offerToReceiveVideo: 10

And you can get 10 in one offer/answer with everything bundled (no impact on the network, just on the SDP size).   If you don't want to do that, or have a really high max (100?), then a re-offer from the server is necessary.

In a future spec, offerToReceiveVideo will go away in favor of other mechanisms to "offer to receive" (currently called PeerConnection.addTransceiver), but the idea will still be there.

In Chrome, we don't currently support Unified Plan, nor offerToReceive > 1.  However, Plan B SDP as currently found in Chrome does allow the remote answer from the MCU to contain an unlimited number of tracks.  Just keep putting in a=ssrc lines :).  Thus, you can get as many as you want in one offer/answer round trip.  However, Plan B SDP is going to go away eventually.

And in the longer-term (WebRTC NV or ORTC), the JS will be able to simply create as many RtpReceiver objects it wants at any time,  so the JS could create them after getting the answer from server.  But then you'd probably need to use something other than SDP for signalling.

[Harald Alvestrand]

To clarify a matter of terminology:

SDP offer/answer is NOT a 3-way handshake.

For many things that would have been easy with a 3-way handshake, SDP has to use two offer/answer cycles. So if you're literally talking about 3-way handshake, you're talking about something different than SDP offer/answer - and Unified Plan is still SDP offer/answer.

Harald

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/46f4dddf-715b-48d7-b016-29d86de8c8ca%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Peter Thatcher]

Yes, that's why I said "a re-offer" is necessary in some cases.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/2Px7o4ZDEm4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVGRrxGudR1OojObLr-YcbKB-w0zfn1oFBX-2BWCSgDoUw%40mail.gmail.com.

[chris...@sinch.com]

Thanks both of you for your answers. Makes sense that given using SDP, it will be two Offer/Answer cycles.

Christoffer