[jitsi-dev] changing rtp channel direction before ice connection


#1

We've recently run into the following issue:

Signaling allocates channels on the bridge to create an offer. Allocates
audio, video and data channels and sets all to 'sendrecv'.
Signaling gets a response from the bridge, creates an offer, sends it to
the client
Client sends back with an answer that has audio and video mlines set to
'inactive'
Signaling updates the bridge via a REST patch with the answer information
The bridge ignores the direction setting because of the following check in
RTPChannel:

  public void setDirection(MediaDirection direction)
      {
          // XXX We modify the stream direction only after latching has
finished.
          if (streamTarget.getDataAddress() != null) {
            ..

The connection isn't up yet, so the bridge basically drops the direction
update and leaves the channels as sendrecv.

I asked Boris about it and he believes the check is there for non-ice (i.e.
raw udp) use cases, so removing it altogether felt a bit worrisome. Wanted
to start some discussion on the list about if there's perhaps another
option to handle this case if the above check can't be removed.

If we find that the check can be removed, that would be great (I did that
on my local branch and didn't see any immediate issues, but we're using ICE
and I haven't tested exhaustively). If not, maybe something along the
lines of storing the most recent state and updating it once the connection
is created (haven't checked if there's an event fired for that or not).

-brian