[MMUSIC] ICE SDP/JSEP peace accords

[Adam Roach <[e-mail]>]

[as an individual]

Okay, so I sat down and looked at JSEP, ice-sip-sdp, and RFC 5245/RFC 
6544 to
try to figure out what we might be able to do here. I'll note that the issue
at hand is the transport (aka <proto>) field for audio and video only. I'm
going to give a summary of the issues as I understand them so that 
people who
haven't been following along closely can come up to speed and hopefully 
weigh
in on the topic.

Before I get too far into this, I want to point out that there are some
constraints on the solution that we need to keep in mind. The first, of 
course,
is that RFC 5245 is deployed and unchangeable. The second is that JSEP is
effectively an as-built description of a deployed system, and is already 
in the
RFC Editor Queue. It's not quite as immutable as RFC 5245 (as we can see 
from
the recent changes to make it internally consistent), but I think the 
chances of
getting the existing (now almost six years old) deployed WebRTC ecosystem to
make a protocol-visible change are approximately zero.

So that leaves us with the question of what to do with ice-sip-sdp.

Implementations using RFC 5245/6544 do the following:

  - New sent offers will contain a proto corresponding to the default 
candidate.
  - Mid-session sent offers (including the "fix-up" offer sent 
exclusively for
    the benefit of middleboxes) will contain a proto corresponding to the
    selected ICE candidate.
  - New and mid-session received offers can contain any proto 
corresponding to
    a supported AVP profile.


WebRTC implementations do the following:

  - New sent offers always contain "UDP/TLS/RTP/SAVPF"
    regardless of the default candidate or the selected candidate
  - Mid-session sent offers always contain "UDP/TLS/RTP/SAVPF"
    regardless of the default candidate or the selected candidate
  - "fix-up" offers are not generated.
  - New and mid-session received offers can contain any of the eight proto
    types listed in JSEP [1]. These are all treated as functionally 
identical
    to "UDP/TLS/RTP/SAVPF" [2].


draft-ietf-mmusic-ice-sip-sdp currently says:

  - New sent offers (prior to candidate nomination) will contain a proto
    corresponding to the default candidate.
  - Mid-session offers corresponding to the nominated/selected ICE 
candidate.
  - "fix-up" offers are only generated for changed offers. (I think? 
Language in
    §3.3.4 is unclear about the timing of the "subsequent offer/answer")
  - New and mid-session received offers can contain any proto 
corresponding to
    a supported AVP profile.


In all cases:
  - All sent answers always match, on a line-for-line basis, the protos 
in the
    received offer.
  - Handling of the receipt of an answer with mismatched protos is
    undefined, and deployed products probably have varying behaviors.
  - Handling receipt of an unrecognized proto in a new offer will (probably)
    result in the media section being rejected.


The lack of a "fix-up" offer may cause older intermediaries that aren't
prepared to deal with WebRTC some heartburn; however, neither 5245/6544 nor
ice-sip-sdp call for any endpoint behavior that will result in failures.

It's also clear that answers of all kinds will work just fine, as the 
handling
is functionally identical between JSEP and ice-sip-sdp.

So the issue at hand seems confined to mid-session offers, and only in those
cases where the transport of either the candidate in use or the initial 
default
candidate is TCP.

This leaves five cases to analyze:

A) A WebRTC endpoint sends an initial offer where the default candidate is
    UDP. ICE selects a TCP candidate.

B) A WebRTC endpoint sends an initial offer where the only offered 
candidates
    are TCP. (This is extremely unusual, but not impossible.)

C) A non-WebRTC endpoint sends an initial offer where the default 
candidate is
    UDP. ICE selects a TCP candidate.

D) A non-WebRTC endpoint sends an initial offer where the default 
candidate is
    TCP. ICE selects a TCP candidate.

E) A non-WebRTC endpoint sends an initial offer where the default 
candidate is
    TCP. ICE selects a UDP candidate. (This really shouldn't happen 
unless an
    implementation has gone bonkers.)

Case A:
  - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
  - non-WebRTC endpoint sends answer with UDP/TLS/RTP/SAVPF
  - ICE runs and selects a TCP candidate
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint accepts this per its rules, and sends answer for
      TCP/DTLS/RTP/SAVPF
    - Absolutely no problems ensue.
  - If WebRTC client sends a subsequent offer:
    - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - non-WebRTC endpoint's answer will contain UDP/TLS/RTP/SAVPF.
      * If an implementation checks that the transport matches the in-use
        candidate, it might get upset about things, although nothing in
        ice-sip-sdp requires such a check.
      - The previous point notwithstanding, per ice-sip-sdp §3.4.1.1.1, this
        will not trigger a change in candidates or a restart of ice 
procedures.
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer with TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
    - Everything works fine.

Case B:
  - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF but only TCP 
candidates
    - This won't work with non-ICE clients. WebRTC's security design 
does not
      allow working with non-ICE clients, so this isn't an issue.
  - non-WebRTC endpoint sends answer with UDP/TLS/RTP/SAVPF
    * If the non-WebRTC implementation does some kind of complex 
validation that
      the default candidate matches the specified transport, it might 
get upset
      about things.
  - ICE runs and selects a TCP candidate
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint accepts this per its rules, and sends answer for
      TCP/DTLS/RTP/SAVPF
    - Absolutely no problems ensue.
  - If WebRTC client sends a subsequent offer:
    - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - non-WebRTC endpoint's answer will contain UDP/TLS/RTP/SAVPF.
      * If an implementation checks that the transport matches the in-use
        candidate, it might get upset about things, although nothing in
        ice-sip-sdp requires such a check.
      - The previous point notwithstanding, per ice-sip-sdp §3.4.1.1.1, this
        will not trigger a change in candidates or a restart of ice 
procedures.
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer with TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
    - Everything works fine.

Case C:
  - non-WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
  - WebRTC endpoint sends answer with UDP/TLS/RTP/SAVPF
  - ICE runs and selects a TCP candidate
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint accepts this per its rules, and sends answer for
      TCP/DTLS/RTP/SAVPF
    - Absolutely no problems ensue.
  - If WebRTC client sends a subsequent offer:
    - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - non-WebRTC endpoint's answer will contain UDP/TLS/RTP/SAVPF.
      * If an implementation checks that the transport matches the in-use
        candidate, it might get upset about things, although nothing in
        ice-sip-sdp requires such a check.
      - The previous point notwithstanding, per ice-sip-sdp §3.4.1.1.1, this
        will not trigger a change in candidates or a restart of ice 
procedures.
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer with TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
    - Everything works fine.

Case D:
  - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
  - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
  - ICE runs and selects a TCP candidate
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint accepts this per its rules, and sends answer for
      TCP/DTLS/RTP/SAVPF
    - Absolutely no problems ensue.
  - If WebRTC client sends a subsequent offer:
    - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - non-WebRTC endpoint's answer will contain UDP/TLS/RTP/SAVPF.
      * If an implementation checks that the transport matches the in-use
        candidate, it might get upset about things, although nothing in
        ice-sip-sdp requires such a check.
      - The previous point notwithstanding, per ice-sip-sdp §3.4.1.1.1, this
        will not trigger a change in candidates or a restart of ice 
procedures.
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer with TCP/DTLS/RTP/SAVPF
    - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
    - Everything works fine.

Case E:

  - non-WebRTC endpoint sends offer for TCP/DTLS/RTP/SAVPF
  - WebRTC endpoint sends answer with TCP/DTLS/RTP/SAVPF
  - ICE runs and selects a UDP candidate
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - WebRTC endpoint accepts this per its rules, and sends answer for
      UDP/TLS/RTP/SAVPF
    - Absolutely no problems ensue.
  - If WebRTC client sends a subsequent offer:
    - WebRTC endpoint sends offer for UDP/TLS/RTP/SAVPF
    - non-WebRTC endpoint's answer will contain UDP/TLS/RTP/SAVPF.
    - Everything works fine.
  - If non-WebRTC client sends a subsequent offer:
    - non-WebRTC endpoint sends offer with UDP/TLS/RTP/SAVPF
    - WebRTC endpoint sends answer with UDP/TLS/RTP/SAVPF
    - Everything works fine.

While the WebRTC and non-WebRTC implementations can be distinguished 
from each
other in each of these cases, no incompatabilities arise. The only 
places where
there is *any* potential for problems are highlighted above with an "*" 
instead
of a "-". All such cases involve a non-WebRTC implementation deciding to
validate peer behavior that has no bearing on its own operation.

While Postel's Law would hopefully counsel implementors away from such 
behavior,
it seems that we can head off this behavior completely by explicitly 
instructing
implementations not to treat these situations as failures of any kind
("Implementations MUST NOT treat a mismatch between the transport in an 
m= line
and the default or selected candidate as an error, and MUST NOT alter 
ICE state
in reaction to such a mismatch").

I think that gets us to 100% compatibility between JSEP and ice-sip-sdp 
-- and,
except for busybody implementations checking compliance where they 
should not be
-- it doesn't require any changes in anyone's code.

This does leave the kind of fiddly protocol-nerd issue that JSEP says to 
do one
thing where ice-sip-sdp says to do another. I think this difference is best
handled by a note in ice-sip-sdp along the lines of: "Note that 
implementations
of [RFC-jsep] will indicate a transport of 'UDP/TLS/RTP/SAVPF' regardless of
whether the default and/or selected ICE candidate is UDP or TCP. While 
this is
functionally compatible with this specification, future users of ICE in
conjunction with SDP Offer/Answer procedures are expected to use the 
procedures
specified in this document."

As far as I can tell, this gets us past the current impasse with the 
addition of
two sentences to ice-sip-sdp, neither of which has any real practical 
effect on
implementations.

I know that there are parts of this proposal that will disappoint people who
want JSEP to change to match ice-sip-sdp, and parts that will disappoint 
people
who want ice-sip-sdp to change to match JSEP; but I think that this is 
the most
practical fix, and the only one I can imagine that doesn't imply the 
need for
large-scale software updates to comply with the final published protocols
(taking careful note that any such changes would almost certainly never
happen).

/a

____
[1] RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF, TCP/DTLS/RTP/SAVP,
     TCP/DTLS/RTP/SAVPF, UDP/TLS/RTP/SAVP, and UDP/TLS/RTP/SAVPF. This 
is a list
     of the currently registered proto values that carry RTP over either 
UDP or
     TCP, minus the new protos defined in RFC 7850 (users of those 
values are
     presumably aware of the nuanced meanings of each value) and minus
     "TCP/RTP/AVP", which is unencrypted, and whose use with 
encryption-related
     attributes is inherently ambiguous, unlike the other "SAVP(F)" 
protos in
     this list.

[2] WebRTC's permissive list is a practical hack in response to existing
     deployed implementations that say one thing but mean another. This can
     lead to kind of strange failures -- mostly due to differing notions of
     media encryption -- but that's a carefully-considered and 
already-litigated
     option that impacts only WebRTC.