Subject: [clue] Coupling between Protocol and Signaling wrt O/A

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Oct 2014 12:01:17 -0400

(Special note to Rob, who wasn't on the call today. This is important 
for the signaling doc.)

On the design team call today we got into a discussion about how the SDP 
O/A fits into the protocol state machines. Currently the state machines 
have a *state* for doing O/A. There was concern that this doesn't 
reflect the way these things occur asynchronously.

As I understood the discussion, the desire is that the O/A be addressed 
by the signaling draft. I think that makes sense, but it leaves open the 
question of how the two layers coordinate to handle this.

My thought is that there is some *state* information from the protocol 
layer that must be available to the signaling layer. In particular, I 
think the signaling layer needs the following information to do its job:

1) the most recent configuration sent by the MC layer that has been
    ACKed without error, and the ADV it references.

2) the most recent configuration received by the MP layer and
    ACKed without error, and the ADV it references.

3) the most recent ADV received by the MC layer that has been
    ACKed without error - if different from (1).

4) the most recent ADV sent by the MP layer, if different from (2).

5) an indication when any of the above change.

Given all that, the signaling layer can handle O/A as follows:

- if an offer is received, the answer SHOULD be generated to
   be compatible with the above, as best possible. (It may not
   be possible to include everything desired because of the
   need to be compatible with the offer.)

- when any of the state info (1)-(4) changes, then as soon as
   not already in the midst of an O/A, a new offer should be
   generated to be compatible with the above. If it differs from
   the last SDP send as an offer or answer, then offer should
   be sent.

Note that there is quite a bit of discretion about how the offers and 
answers are generated. For instance, when an ADV has been sent, a 
matching offer could immediately be sent, even without waiting for an 
ACK. Or sending the new offer could be delayed until the ACK is 
received. In some cases (e.g., when the ADV drops a capture) the offer 
could be delayed until a new configure is received. In other cases 
(e.g., when adding an encoding) it can't wait for a configure because 
the consumer needs the SDP to decide whether to configure it.

I don't think there is any need for the signaling layer to inform the 
protocol layer when O/A occurs. (Except for indications when the SCTP 
association comes and goes.)

It is unfortunate that the "surface" between signaling and protocol is 
so large, but I don't see how to make it smaller.

When things are viewed this way, I think "SDP O/A" should not be a 
*state* in the MC/MP state machines. Rather, there need to be *actions* 
on some state transitions, that update the state information shared with 
the signaling layer.

	Thanks,
	Paul