Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

[[e-mail] (Dale R. Worley)]

> From: Adam Roach <[e-mail]>
> 
> What I was trying to say above is that the only information you would 
> need to convey is literally one, two, or three <mediatype,ordinality> 
> pairs. You don't say what you're planning to do with them, just that you 
> need them.

It seems unlikely that the situation is that simple.  I see a number
of issues.

If the follower (= designated answerer) wants an additional, say,
audio m= line, it asks for that.  But how is it to know when it has
been given them?  The next re-INVITE to arrive from the leader (=
designated offerer) may have been spontaneously sent, and it may have
an additional audio m= line that the leader added, for entirely
different purposes.  The follower may misinterpret the use of the new
m= line as the one that it ordered, and it will get confused when a
further m= line shows up when the solicited re-INVITE arrives.  (I've
written a set of messy railroad diagrams below that show how the
follower can lose track of what the leader is doing.)

In any case, the logic in the draft assumes that the follower can
determine when the leader has sent the solicited INVITE.  (Among other
things, the follower is then allowed to send another solicitation.)

You can probably clean that up by having each solicitation contain a
sequence number or identifier, and the leader copies the identifier
into the INVITE it generates because of the solicitation.  Then the
follower can always tell what the state of the conversation is.

If the solicited INVITE fails, the leader has to send it again,
because the solicitation is still outstanding.  This could lead to bad
failure situations.

There are situations where simply having "an additional audio m= line"
is not sufficient.  I'd expect that the leader, once it sees the
follower's configuration of the m= line, might want to update its
configuration of the m= line.  (Because we are logically (though not
in protocol) *offering* the m= line in the *answer*.)  So the leader
may want to do a re-INVITE cycle to get its end of the media stream
configured.  (This isn't an error, though, and can't cause a delay;
it's just an implementation warning.)

Another complex situation is where the follower wants to split a
bundle.  If the leader is willing to bundle all m= lines, but the
follower wants to bundle 1 with 2 and 3 with 4, it's difficult for the
follower to prompt the leader to offer that bundle configuration.

Three situations that look much alike to the follower:

               Leader         Follower

                  |               |
                  |          sol  |-- send
                  |<--------------|   solicit
                  |               |
        respond --| INV           |
       w/INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
    spontaneous --| INV           |
         INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
                  |               |-- What's
                  |               |   happening?
                  |               |


                  |               |
                  |          sol  |-- send
                  |       +-------|   solicit
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
                  |<------+       |
                  |               |
        respond --| INV           |
       w/INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
                  |               |-- What's
                  |               |   happening?
                  |               |


                  |               |
                  |          sol  |-- send
                  |       +-------|   solicit
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
                  |<------+       |-- What's	
                  |               |   happening?
        respond --| INV           |
       w/INVITE   |------>        |
        to come   |               |
                  |               |

Dale