Re: [MMUSIC] ICE SDP/JSEP peace accords

[Roman Shpount <[e-mail]>]

Hi Adam,

I would like to bring up a couple of points:

1. We are discussing the JSEP update that changes the protocol behavior.
Subsequent offers in JSEP always specified transport, address and port of
the only (default) candidate present. No version of JSEP draft was ever
published where it was not the case. This is a protocol change which is
being done when document is already in Editor Queue. If any implementations
currently exist that send UDP/TLS/RTP/SAVPF in subsequent offers when only
TCP candidates are present, they are not compliant with latest published
JSEP draft.

2. So far nothing specifies what is being placed in address and port of c=
and m= line when m= line specifies UDP based protocol but all the ICE
candidates are TCP. If anybody thinks this is specified somewhere except
the latest JSEP editorial update, please let me know. What I do not want to
happen is to make JSEP specify that m= and c= line should contain address
from TCP candidate with protocol in m= line being UDP. This would be a new
behavior introduced only to save an extra sentence. Ideally, I would prefer
that in this case IN IP4 0.0.0.0 address was used in the c= line and port 9
was used in m= line to indicate that this information is supposed to be
discarded. I do not think this would break any existing implementations and
can be done without any changes to the current JSEP draft with an
ice-sip-sdp update.

3. I am not sure your analysis is entirely correct. There is a problem with
was it being proposed and exiting RFC5245 implementations. According to RFC
5245 section 9.2 (https://tools.ietf.org/html/rfc5245#section-9.2):

When receiving a subsequent offer within an existing session, an agent MUST
reapply the verification procedures in Section 5.1 without regard to the
results of verification from any previous offer/answer exchanges.


In  RFC 5245 section 5.1:

The agent will proceed with the ICE procedures defined in this
specification if, for each media stream in the SDP it received, the default
destination for each component of that media stream appears in a candidate
attribute.
...
If this condition is not met, the agent MUST process the SDP based on
normal RFC 3264 procedures...


Default destination in RFC 5245 includes transport, address and port. So if
all three of these do not match any of the candidates, entire offer is
processed as non-ICE. This means all the sections marked as * in your
description will break against the RFC 5245. If we agree to the proposed
change in JSEP, all implementations that need to interop with RFC 5245 will
need to munge the SDP and change the m= line protocol. This was not
necessary until the currently proposed change.

Regards,
_____________
Roman Shpount


On Mon, Jan 14, 2019 at 5:53 PM Adam Roach <[e-mail]> wrote:

> [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.
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>