Subject: [MMUSIC] ICE SDP/JSEP peace accords

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2019 16:53:39 -0600

[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.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2019 18:39:02 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jan 2019 17:57:30 -0600

On 1/14/19 5:39 PM, Roman Shpount wrote:
>
> 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.
>

The JSEP document was internally inconsistent, as you have pointed out 
in the past. Two statements conflicted with each other, so no matter 
what an implementation did, it was possible to point to a normative 
statement in JSEP that it was violating. The change to JSEP is being 
made to bring it in line with the behavior that was actually developed 
and deployed.

> 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.

This is a rough edge, but -- again -- we're really at a point where the 
currently deployed JSEP behavior is what JSEP needs to document. It 
might make you sad, but it's the only really practical approach. I can 
see why you prefer what you prefer, but I can't work out what breaks if 
we don't do your preferred thing.

> 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:
>
>     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.

That is an interesting and rather unfortunate wrinkle. I fear it falls 
victim to the preconditions I laid out at the top of my message, and 
there's probably no helping it. I mean, we can make the documents say 
the right things, but the chances of that causing the implementations to 
do what you want are probably as close to zero as to make no difference.

/a

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Jan 2019 19:26:34 -0500

On Mon, Jan 14, 2019 at 6:57 PM Adam Roach <[email-masked]> wrote:

> The JSEP document was internally inconsistent, as you have pointed out in
> the past. Two statements conflicted with each other, so no matter what an
> implementation did, it was possible to point to a normative statement in
> JSEP that it was violating. The change to JSEP is being made to bring it in
> line with the behavior that was actually developed and deployed.
>
Can we see some sort of indication of what is actually currently
implemented? As far as I remember this changed a couple of times, so it
would be interesting to see what is currently deployed. At the end of the
day, we are talking about changing of a few lines in existing
implementations which are still deploying huge compatibility breaking
changes, like unified plan.

> currently deployed JSEP behavior is what JSEP needs to document. It might
> make you sad, but it's the only really practical approach. I can see why
> you prefer what you prefer, but I can't work out what breaks if we don't do
> your preferred thing.
>
 The result of putting random information in c= and m= line is that it
means SDP from WebRTC implementation would need to be munged and modified
when passed to non WebRTC implementations. If you have a server which
processes SDP from both regular phones and WebRTC, offers from these two
sources will need to be treated differently. In case of phones, default
candidate that does not match any ICE candidates should be treated as an
additional candidate. In case of WebRTC, it should be ignored.

> 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:
>
> 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
> description will break against the RFC 5245.
>
>
> there's probably no helping it. I mean, we can make the documents say the
> right things, but the chances of that causing the implementations to do
> what you want are probably as close to zero as to make no difference.
>
I thought that RFC5245 interop is something which was important to WebRTC.
Are we dropping this now?

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Jan 2019 09:24:59 +0000

Hi,

>> 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.
>
> The JSEP document was internally inconsistent, as you have pointed out in the past. Two statements conflicted with each other, so no matter 
> what an implementation did, it was possible to point to a normative statement in JSEP that it was violating. The change to JSEP is being made 
> to bring it in line with the behavior that was actually developed and deployed.

If the JSEP contains two conflicting statements, and we have to choose one, it sounds strange that we would choose the one that is inconsistent with the ICE spec.

Also, as I have indicated before, JSEP defines an internal API - not a signaling protocol. I DO understand that it is convenient to use the same "JSEP SDP O/A & ICE procedures" alsao on the wire, but AFAIK that is not defined anywhere. What SDP O/A & ICE procedures is a WebRTC endpoint that do NOT implement JSEP expected to use?

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 22 Jan 2019 15:17:47 -0500

MMUSIC folks

It would be helpful if more people would chime in on this thread so we 
can gauge how to proceed.

Thanks

-- Flemming (with co-chair hat on)

On 1/15/19 4:24 AM, Christer Holmberg wrote:
> .

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jan 2019 20:36:05 +0000

Hi,

I think Roman requested information about what exactly has been implemented.

Regards,

Christer

________________________________
From: Flemming Andreasen <[email-masked]>
Sent: Tuesday, January 22, 2019 10:17 PM
To: Christer Holmberg; Adam Roach; Roman Shpount; [email-masked]
Subject: Please Read and Comment: Re: [MMUSIC] ICE SDP/JSEP peace accords

MMUSIC folks

It would be helpful if more people would chime in on this thread so we can gauge how to proceed.

Thanks

Hi,

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic
.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Jan 2019 15:51:37 -0500

> I think Roman requested information about what exactly has been
We have discussed this with Adam Roach off-list.

Currently both Chrome and Firefox use outdated protocol TCP/TLS/RTP/SAVPF
instead of TCP/DTLS/RTP/SAVPF which is defined in rfc7850 Section 3.5 (
https://tools.ietf.org/html/rfc7850#section-3.5).

Chromium Code Search:

https://cs.chromium.org/search/?q=TCP/DTLS/RTP/SAVPF&sq=package:chromium&type=cs

Your search - TCP/DTLS/RTP/SAVPF - did not match any documents.

https://cs.chromium.org/search/?q=TCP/TLS/RTP/SAVPF&sq=package:chromium&type=cs

src/third_party/webrtc/pc/media_session.cc
 cricket::IsDtlsRtp
    81: // Most-likely values first.
    82: return protocol == "UDP/TLS/RTP/SAVPF" || protocol ==
"TCP/TLS/RTP/SAVPF" ||
    83:        protocol == "UDP/TLS/RTP/SAVP" || protocol ==
"TCP/TLS/RTP/SAVP";

src/third_party/webrtc/pc/media_session_unittest.cc
   230: static const char* kMediaProtocolsDtls[] = {
   231:     "TCP/TLS/RTP/SAVPF", "TCP/TLS/RTP/SAVP", "UDP/TLS/RTP/SAVPF",
   232:     "UDP/TLS/RTP/SAVP"};

Firefox Code Search:

https://dxr.mozilla.org/mozilla-central/search?q=TCP%2FDTLS%2FRTP%2FSAVPF
0 results from the mozilla-central tree

https://dxr.mozilla.org/mozilla-central/search?q=TCP%2FTLS%2FRTP%2FSAVPF
media/webrtc/signaling/src/sdp/SdpMediaSection.h
57 kTcpTlsRtpSavpf,    // TCP/TLS/RTP/SAVPF [JSEP-TBD]
264 return os << "TCP/TLS/RTP/SAVPF";

media/webrtc/signaling/src/sdp/rsdparsa/src/media_type.rs
272 "TCP/TLS/RTP/SAVPF" => SdpProtocolValue::TcpTlsRtpSavpf,

media/webrtc/signaling/src/sdp/sipcc/sdp_main.c
273 {"TCP/TLS/RTP/SAVPF", sizeof("TCP/TLS/RTP/SAVPF")},

This means both Chrome and Firefox never generate SDP with
TCP/DTLS/RTP/SAVPF. In fact, neither browser currently can parse SDP with
 TCP/DTLS/RTP/SAVPF and as a result they are not compliant with JSEP 5.1.2 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2). So,
JSEP section 5.1.2 does not actually describe current implementations and
both Chrome and Firefox would need to be updated to be compliant with this
section of JSEP draft.

I would think that since both Chrome and Firefox would need to be updated
to be compliant with JSEP section 5.1.2 anyway, it should be possible to
update section 5.1.2 and clarify that it only applies to the offers during
ICE restart.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Jan 2019 15:04:07 -0600

Yeah, so that's a one-character typo that made it from JSEP into both 
codebases. Firefox is fixed now (as of Firefox 66 [1]), and the editor's 
copy of JSEP is as well [2].

In terms of current offer-generation behavior, I had an brief exchange 
with the Chrome folks; the offers it generates /always/ indicate its 
preferred (default) candidate in the m=/o= line, regardless of the 
candidate in use. Since the preferred candidate will always be UDP, the 
transport is always sent as UDP/TLS/RTP/SAVPF.

Ironically, I don't yet know what the equivalent behavior in Firefox is. 
I'll ask around.

/a

____
[1] https://hg.mozilla.org/mozilla-central/rev/34476dc321b5
[2] https://github.com/rtcweb-wg/jsep/pull/861/files

On 1/22/19 2:51 PM, Roman Shpount wrote:
> On Tue, Jan 22, 2019 at 3:36 PM Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Currently both Chrome and Firefox use outdated protocol 
> TCP/TLS/RTP/SAVPF instead of TCP/DTLS/RTP/SAVPF which is defined in 
> rfc7850 Section 3.5 (https://tools.ietf.org/html/rfc7850#section-3.5).
>
> Chromium Code Search:
>
> <http://media_type.rs>
> TCP/DTLS/RTP/SAVPF. In fact, neither browser currently can parse SDP 
> with  TCP/DTLS/RTP/SAVPF and as a result they are not compliant with 
> JSEP 5.1.2 
> (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2). 
> So, JSEP section 5.1.2 does not actually describe current 
> implementations and both Chrome and Firefox would need to be updated 
> to be compliant with this section of JSEP draft.
>
> I would think that since both Chrome and Firefox would need to be 
> updated to be compliant with JSEP section 5.1.2 anyway, it should be 
> possible to update section 5.1.2 and clarify that it only applies to 
> the offers during ICE restart.
>
> Regards,
> _____________
> Roman Shpount
>
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Jan 2019 16:15:45 -0500

On Tue, Jan 22, 2019 at 4:04 PM Adam Roach <[email-masked]> wrote:

> with the Chrome folks; the offers it generates *always* indicate its
Just to clarify, there is no argument that preferred (default) candidate
should be used in the m=/o= line.

When ICE restart is initiated, UDP based candidate must be present (or in
case of trickle ICE eventually added), used as a default candidate, thus
UDP based protocol must be used in the m= line in both offer and answer.

The issue is the offer generated when ICE restart is not initiated and TCP
candidate is currently nominated. TCP candidate is the only candidate which
is present in both offer and answer. It is also the default candidate. No
UDP candidate will be added it any point during the offer/answer exchange.
Both end points support TCP protocol, since TCP candidate was already
successfully nominated. In  this case, according to RFC5245 abd
ice-sip-sdp, TCP protocol must be used in the m= line in both offer and
answer. JSEP is trying to change this to use UDP based protocol even though
default candidate is TCP.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jan 2019 21:18:47 +0000

Hi,

>Yeah, so that's a one-character typo that made it from JSEP into both codebases.
>Firefox is fixed now (as of Firefox 66 [1]), and the editor's copy of JSEP is as well [2].

Did that also fix the parsing issue Roman mentioned?

Regards,

Christer

On 1/22/19 2:51 PM, Roman Shpount wrote:
On Tue, Jan 22, 2019 at 3:36 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Currently both Chrome and Firefox use outdated protocol TCP/TLS/RTP/SAVPF instead of TCP/DTLS/RTP/SAVPF which is defined in rfc7850 Section 3.5 (https://tools.ietf.org/html/rfc7850#section-3.5).

Chromium Code Search:

src/third_party/webrtc/pc/media_session.cc
 cricket::IsDtlsRtp
    81: // Most-likely values first.
    82: return protocol == "UDP/TLS/RTP/SAVPF" || protocol == "TCP/TLS/RTP/SAVPF" ||
    83:        protocol == "UDP/TLS/RTP/SAVP" || protocol == "TCP/TLS/RTP/SAVP";

Firefox Code Search:

media/webrtc/signaling/src/sdp/rsdparsa/src/media_type.rs<http://media_type.rs>
272 "TCP/TLS/RTP/SAVPF" => SdpProtocolValue::TcpTlsRtpSavpf,

This means both Chrome and Firefox never generate SDP with TCP/DTLS/RTP/SAVPF. In fact, neither browser currently can parse SDP with  TCP/DTLS/RTP/SAVPF and as a result they are not compliant with JSEP 5.1.2 (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2). So, JSEP section 5.1.2 does not actually describe current implementations and both Chrome and Firefox would need to be updated to be compliant with this section of JSEP draft.

I would think that since both Chrome and Firefox would need to be updated to be compliant with JSEP section 5.1.2 anyway, it should be possible to update section 5.1.2 and clarify that it only applies to the offers during ICE restart.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Jan 2019 15:24:48 -0600

On 1/22/19 3:15 PM, Roman Shpount wrote:
> The issue is the offer generated when ICE restart is not initiated and 
> TCP candidate is currently nominated. TCP candidate is the only 
> candidate which is present in both offer and answer. It is also the 
> default candidate. No UDP candidate will be added it any point during 
> the offer/answer exchange.

This is what I tried to indicate with the use of an italicized "always" 
in my previous reply.

EVEN IF it is generating an offer when ICE restart is initiated and the 
TCP candidate is nominated, Chrome will still always (always, always) 
generate an SDP that includes a UDP candidate and use that candidate's 
value in the m=/o= lines.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Jan 2019 15:26:02 -0600

On 1/22/19 3:18 PM, Christer Holmberg wrote:
> codebases.

It's _only_ a parsing issue at this point, as no current WebRTC browsers 
ever _send_ an m= line with a TCP transport indicated in the m= line.

/a

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Jan 2019 16:33:45 -0500

> value in the m=/o= lines.

Unless I am mistaken, if ICE restart is not initiated, only the nominated
candidate must be included. No other candidates must be present. If Chrome
does not follow this, then it is most likely not complaint with either ICE
or JSEP specifications.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Jan 2019 15:36:31 -0600

On 1/22/19 3:33 PM, Roman Shpount wrote:
> On Tue, Jan 22, 2019 at 4:25 PM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Unless I am mistaken, if ICE restart is not initiated, only the 
> nominated candidate must be included. No other candidates must be 
> present. If Chrome does not follow this, then it is most likely not 
> complaint with either ICE or JSEP specifications.

Based on the conversation I had with their engineers, that seems to be 
the case.

/a

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Jan 2019 16:40:49 -0500

On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <[email-masked]> wrote:

> Based on the conversation I had with their engineers, that seems to be the
> case.
>

Based on RFC 5245 section 9.1.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.1.2.2) this is wrong:

The agent MUST include candidate attributes for candidates matching the
default destination for each component of the media stream, and MUST NOT
include any other candidates.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Jan 2019 15:42:33 -0600

On 1/22/19 3:40 PM, Roman Shpount wrote:
> On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <[email-masked] 
>>     present. If Chrome does not follow this, then it is most likely
>>     not complaint with either ICE or JSEP specifications.
>
>
>     Based on the conversation I had with their engineers, that seems
>     to be the case.
>
>
> Based on RFC 5245 section 9.1.2.2 
> (https://tools.ietf.org/html/rfc5245#section-9.1.2.2) this is wrong:
>
>     The agent MUST include candidate attributes for candidates
>     matching the default destination for each component of the media
>     stream, and MUST NOT include any other candidates.
>

I'm not disagreeing.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Jan 2019 07:40:28 +0000

Hi,

Assuming that the default candidate is UDP, but a TCP candidate is eventually nominated, since there is no update offer does that mean that the setup and connection attributes (and possible other TCP-specific attributes) will never be provided in an offer/answer from the JSEP endpoint? Wouldn’t that also break RFC4145?

Regards,

Christer

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 22 January 2019 at 23.43
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Please Read and Comment: Re: [MMUSIC] ICE SDP/JSEP peace accords

On 1/22/19 3:40 PM, Roman Shpount wrote:
On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 1/22/19 3:33 PM, Roman Shpount wrote:
On Tue, Jan 22, 2019 at 4:25 PM Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Unless I am mistaken, if ICE restart is not initiated, only the nominated candidate must be included. No other candidates must be present. If Chrome does not follow this, then it is most likely not complaint with either ICE or JSEP specifications.

Based on the conversation I had with their engineers, that seems to be the case.

Based on RFC 5245 section 9.1.2.2 (https://tools.ietf.org/html/rfc5245#section-9.1.2.2) this is wrong:

The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates.

I'm not disagreeing.

/a

---

From: Roman Shpount <[email-masked]>
Date: Wed, 23 Jan 2019 14:11:49 -0500

On Wed, Jan 23, 2019 at 2:40 AM Christer Holmberg <
[email-masked]> wrote:

> Assuming that the default candidate is UDP, but a TCP candidate is
> eventually nominated, since there is no update offer does that mean that
> the setup and connection attributes (and possible other TCP-specific
> attributes) will never be provided in an offer/answer from the JSEP
> endpoint? Wouldn’t that also break RFC4145?
>
>
>
Values of setup and other TCP specific attributes are encoded within the
TCP ICE candidate. Providing TCP connection attributes, or providing any
information about the actual nominated candidate in c=/m= line in the
update offer is optional in ice-sip-sdp. This typically does not break
anything unless signaling agent needs to record the actual communication
address and protocol used for connection. In case of JSEP, update offer can
be implemented via the API when ICE nomination is complete. I think it is
good enough that JSEP API provides a mechanism to develop an offer/answer
ICE negotiation compatible with RFC5245 but allows to relax those
constraints when they are not necessary.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Jan 2019 19:28:56 +0000

Hi,

>>Assuming that the default candidate is UDP, but a TCP candidate is eventually nominated,
>>since there is no update offer does that mean that the setup and connection attributes
>>(and possible other TCP-specific attributes) will never be provided in an offer/answer
>>from the JSEP endpoint? Wouldn’t that also break RFC4145?

>
>Values of setup and other TCP specific attributes are encoded within the TCP ICE candidate.
>Providing TCP connection attributes, or providing any information about the actual nominated
>candidate in c=/m= line in the update offer is optional in ice-sip-sdp.

Ok. I just saw they were included in the examples.

>This typically does not break anything unless signaling agent needs to record the actual
>communication address and protocol used for connection. In case of JSEP, update offer
>can be implemented via the API when ICE nomination is complete. I think it is good enough
>that JSEP API provides a mechanism to develop an offer/answer ICE negotiation compatible
>with RFC5245 but allows to relax those constraints when they are not necessary.

Then ANY app (JSEP or no JSEP) could consider the constraints not being necessary.

But, as you say, eventhough the JSEP API does not automatically provide the updated offer, the JS app can do it.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Jan 2019 09:05:53 -0500

On 1/22/19 4:42 PM, Adam Roach wrote:
>>>     nominated candidate must be included. No other candidates must
>>>     be present. If Chrome does not follow this, then it is most
>>>     likely not complaint with either ICE or JSEP specifications.
>>
>>

So where does this leave us ?

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Jan 2019 14:10:31 +0000

Hi,

There seems to be ongoing discussion on both the MMUSIC and RTCWEB lists. Could we please use one list, or include both lists?

Regards,

Christer

From: Flemming Andreasen <[email-masked]>
Date: Friday, 25 January 2019 at 16.06
To: "[email-masked]" <[email-masked]>, Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Please Read and Comment: Re: [MMUSIC] ICE SDP/JSEP peace accords

I'm not disagreeing.

Thanks

-- Flemming

/a

---

From: Roman Shpount <[email-masked]>
Date: Fri, 25 Jan 2019 13:50:03 -0500

> So where does this leave us ?
I think JSEP sections 5.1.2 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2) and
potentially 5.2.2 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2) would
need to be updated to be consistent with each other and mmusic drafts.

There is currently a discussion on RTCWEB of pull request
https://github.com/rtcweb-wg/jsep/pull/862/files which attempts to fix this.

Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 25 Jan 2019 10:58:28 -0800

I think Adam’s Pr on this topic is reasonable way forward.

Thanks
Suhas

On Fri, Jan 25, 2019 at 10:50 AM Roman Shpount <[email-masked]> wrote:

>>> nominated candidate must be included. No other candidates must be present.
>>> If Chrome does not follow this, then it is most likely not complaint with
>>> either ICE or JSEP specifications.
>>>
>>>
> https://tools.ietf..org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2
> <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2>)
> and potentially 5.2.2 (
> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2)
> would need to be updated to be consistent with each other and mmusic drafts.
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 25 Jan 2019 14:35:06 -0500

I have provided my comments on pull request. I think this is a reasonable
way forward but the language requires clarification.

We will also need to update ice-sip-sdp to deal with some of the
ambiguities:

1. We need to specify that protocol in the answer must match protocol in
the offer, even if none of the ICE candidates in the answer match. For
instance, if an offer is received with TCP/DTLS/RTP/SAVPF , but the answer
contains only UDP candidates, answer MUST sill use  TCP/DTLS/RTP/SAVPF

2. We need to specify what address and port must be used if protocol in the
m= line does not match any of the candidates. I think using IN IP4 0.0.0.0
and port 9 is a safe option which avoids ICE mismatch.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Jan 2019 15:30:47 -0600

On 1/25/19 8:10 AM, Christer Holmberg wrote:
>
> There seems to be ongoing discussion on both the MMUSIC and RTCWEB 
> lists. Could we please use one list, or include both lists?
>

I posted to MMUSIC when I thought that the SIP-ICE draft was the best 
place to fix the problem. Roman has convinced me that it probably is 
best handled by changing JSEP, which is an RTCWEB issue rather than an 
MMUSIC issue, so that discussion is going on over there. I suspect 
anyone in a position to meaningfully comment on the topic is subscribed 
to both (so copying both lists would just result in a doubling of 
mailing list traffic for everyone), and I think it's important that the 
governance of the conversation is handled by the responsible WG chairs, 
which is why the discussion for MMUSIC documents is happening on the 
MMUSIC list, and the discussion for RTCWEB documents is handling on the 
RTCWEB list.

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 25 Jan 2019 15:22:26 -0800

Hi Roman,

Clarification question inline

On Fri, Jan 25, 2019 at 11:35 AM Roman Shpount <[email-masked]> wrote:

> instance, if an offer is received with TCP/DTLS/RTP/SAVPF , but the
> answer contains only UDP candidates, answer MUST sill use
> TCP/DTLS/RTP/SAVPF
>
>
[Suhas] If none of the candidates match, shouldn't we report ice-mismatch.
So in the example, if one side has just UDP and other side just TCP , we
can't proceed with the connection, isn't it ?

> 2. We need to specify what address and port must be used if protocol in
> the m= line does not match any of the candidates. I think using IN IP4
> 0.0.0.0 and port 9 is a safe option which avoids ICE mismatch.
>
> Regards,
> _____________
> Roman Shpount
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 25 Jan 2019 18:33:06 -0500

Hi Suhas,

On Fri, Jan 25, 2019 at 6:22 PM Suhas Nandakumar <[email-masked]>
wrote:

> [Suhas] If none of the candidates match, shouldn't we report
> ice-mismatch.  So in the example, if one side has just UDP and other side
> just TCP , we can't proceed with the connection, isn't it ?
>

Imagine in you have an offer which contains both UDP and TCP candidates but
the m= line proto is UDP/TLS/RTP/SAVPF. Response has only TCP candidates.
The m= line proto should still be UDP/TLS/RTP/SAVPF since RFC3264 requires
that protocols for the m= line in offer and answer must match.

If offer has only TCP candidates and answer only UDP candidates, the
offer/answer will obviously fail.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 26 Jan 2019 10:38:31 +0000

Hi,

I have also provided some comments on Adam's PR. I haven't posted them on the RTCWEB list, but I can do that too.

All I ask for is to make a clear separation between implementations of the JSEP API (e.g., browsers) and implementations using the JSEP API (e.g. JavaScript applications). The spec now talks about "JSEP implementations", and at least to me it is unclear what that really refers to.

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Friday, January 25, 2019 9:35 PM
To: Suhas Nandakumar
Cc: Christer Holmberg; Flemming Andreasen; [email-masked]
Subject: Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords

I have provided my comments on pull request. I think this is a reasonable way forward but the language requires clarification.

We will also need to update ice-sip-sdp to deal with some of the ambiguities:

1. We need to specify that protocol in the answer must match protocol in the offer, even if none of the ICE candidates in the answer match. For instance, if an offer is received with TCP/DTLS/RTP/SAVPF , but the answer contains only UDP candidates, answer MUST sill use  TCP/DTLS/RTP/SAVPF

2. We need to specify what address and port must be used if protocol in the m= line does not match any of the candidates. I think using IN IP4 0.0.0.0 and port 9 is a safe option which avoids ICE mismatch.

Regards,
_____________
Roman Shpount

On Fri, Jan 25, 2019 at 1:58 PM Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:
I think Adam’s Pr on this topic is reasonable way forward.

Thanks
Suhas

On Fri, Jan 25, 2019 at 10:50 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Jan 25, 2019 at 9:05 AM Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

I'm not disagreeing.

I think JSEP sections 5.1.2 (https://tools.ietf..org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2>) and potentially 5.2.2 (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2) would need to be updated to be consistent with each other and mmusic drafts.

There is currently a discussion on RTCWEB of pull request https://github.com/rtcweb-wg/jsep/pull/862/files which attempts to fix this.

Regards,
_____________

Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 16:31:28 -0500

> include any other candidates.
I wanted to update this thread that according to Justin in our discussion
regarding https://github.com/rtcweb-wg/jsep/pull/863, JSEP specifies that
even after ICE nomination is complete, offer must include all candidates
collected up to this point. This is not explicitly stated anywhere in JSEP
draft, but it is implied by example in section 7.2 and by the fact that
subsequent offers are generated using the same procedures described in JSEP
section 5.2.2 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2),
regardless if ICE nomination is in progress or complete. Specifically,
section 5.2.2 states:

If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering phase
(see Section 3.5.1), an "a=candidate" line MUST be added, as defined in
[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1.

This explicitly contradicts RFC 5245 section 9.1.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.1.2.2) and mmusic-ice-sip-sdp
Section 3.4.1.2.2 (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2
).

Regards,
_____________
Roman Shpount