Subject: [rtcweb] JSEP - Blocking SDP operations ?

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Jan 2012 08:19:12 -0700

The basic question is there any limitations on when setLocal and setRemote can be called. 

Imagine the case where side A does a createOffer and setLocal and is waiting for an answer from the far side. Before the answer arrives, a camera is added to side A and side A wants to send an updated offer that includes video. Can it do this? can it create a new offer and call setLocal a second time before receiving the answer from the far side? 

I have a hard time seeing how this is going to work. Similarly you could have a case where the camera was removed before the answer had been received. 

SDP has some very interesting assumptions and invariants about the pairing of offers and answers. I think SDP introduces the need for constraints on how and when setLocal and setRemote can be called by the JS. I don't have my head around this yet but can you explain what sequences of operations you think are legal and which aren’t?

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Jan 2012 14:28:09 -0500

On Fri, Jan 27, 2012 at 10:19 AM, Cullen Jennings <[email-masked]> wrote:

> Imagine the case where side A does a createOffer and setLocal and is
> waiting for an answer from the far side. Before the answer arrives, a
> camera is added to side A and side A wants to send an updated offer that
> includes video. Can it do this? can it create a new offer and call setLocal
> a second time before receiving the answer from the far side?
>

Surely it can, but it means the app protocol needs to have some notion of
sequence number, and in the case that the answer that is received is an
answer to the initial offer, it gets a bit messy. setLocalDescription needs
to be called again with the initial offer to roll the local description
back to the original state, and then setRemoteDescription will be called
with the answer, and lastly setLocalDescription will be called with the
second offer, as a new offer-answer exchanged is kicked off.

In short, it's definitely possible, but I imagine most app signaling
protocols won't support this.

>
> I have a hard time seeing how this is going to work. Similarly you could
> have a case where the camera was removed before the answer had been
> received.
>
> SDP has some very interesting assumptions and invariants about the pairing
> of offers and answers. I think SDP introduces the need for constraints on
> how and when setLocal and setRemote can be called by the JS. I don't have
> my head around this yet but can you explain what sequences of operations
> you think are legal and which aren’t?
>

I think the general rules are:
- OFFERs need to always be followed by an ANSWER from the other side
- ANSWERs must be preceded by an OFFER from the remote side
- You can update your own OFFER prior to getting a remote ANSWER, if you're
prepared to handle the hard case
- An ANSWER can also be updated by another ANSWER from the remote side
(needs more details here; the first ANSWER most likely needs to be marked
as provisional)

Simple cases:
setLocal(OFFER) -> setRemote(ANSWER)
setRemote(OFFER) -> setLocal(ANSWER)

Simple error cases:
setLocal(OFFER) -> setRemote(OFFER)
setRemote(OFFER) -> setLocal(OFFER)
setLocal(ANSWER)
setRemote(ANSWER)

Early media case:
setLocal(OFFER) -> setRemote(ANSWER1) -> setRemote(ANSWER2)  // probably
need some sort of "moreToFollow" on ANSWER1

Case above, easy path:
setLocal(OFFER1) -> setLocal(OFFER2) -> setRemote(ANSWER2)

Case above, complex path:
setLocal(OFFER1) -> setLocal(OFFER2) -> setLocal(OFFER1) ->
setRemote(ANSWER1) -> setLocal(OFFER2) -> setRemote(ANSWER2)

Does this match what you're thinking?

>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>