Subject: [rtcweb] Proposal to break the ICE impasse

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jan 2019 13:12:08 -0600

Based on conversations in MMUSIC, as well as several offline 
conversations with interested parties, I've put together a proposed 
change to JSEP that, if accepted, will allow publication of the Cluster 
238 documents to move forward.

Note that this new text has no impact on existing implementations (at 
least, as far as I am able to discern), which do not currently have the 
capability of producing media sections consisting of exclusively TCP 
candidates. From that perspective, the change makes existing 
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future 
compatibility between WebRTC implementations once they finalize TCP 
candidate handling (and candidate handling in general for mid-session 
offers).

   https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any 
meaning associated with the transport parameter, while SIP's use of ICE 
does not. The trivial change that I propose, which bears only on future 
WebRTC implementations -- that is, which has no as-built specification 
to point to -- allows JSEP to continue to ignore the value of the 
transport parameter, while specifying that it says the right thing for 
SIP implementations to function properly.

/a

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Jan 2019 12:58:38 -0800

For what it is worth, I think this way forward should work reasonably
well.  It doesn't create a conflict for the current implementations, but
does leave the breadcrumbs needed so that any implementations in the future
that do add support for this will do so interoperably.

If folks can review the PR (it's quite short) and comment, I would
appreciate it.  Assuming we get consensus, I think a quick re-spin is all
that's necessary to move forward.

thanks,

Ted

On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <[email-masked]> wrote:

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jan 2019 15:02:01 -0600

On 1/24/19 1:39 PM, Roman Shpount wrote:
> Would you prefer to reply to you directly with my comments or as a 
> comment on the Github?

Here for discussion, there for specific text change proposals.

>
> The text you are proposing is slightly ambiguous due to trickle-ice. 
> Theoretically, during trickle ICE candidate collection SDP might 
> contain only TCP candidates but UDP candidates can be added at some 
> point in the future. Based on the proposed text proto will start of as 
> TCP/DTLS/RTP/SAVP and then change when UDP candidates are collected.

I don't think that's true -- the way JSEP specifies trickle ice, offers 
for trickle ice will always start with zero candidates, and so the 
trickling will always use UDP/DTLS/RTP/SAVPF from the start.

> Also, for consistency, the next paragraph, which is talking about 
> UDP/DTLS/SCTP should be updated as well to use TCP/DTLS/SCTP when 
> offer does not initiate ICE restart and only TCP candidates are present.

I'm okay if we require applications that use WebRTC data channels to 
have to do things the WebRTC way.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jan 2019 15:03:27 -0600

On 1/24/19 3:02 PM, Adam Roach wrote:
> I don't think that's true -- the way JSEP specifies trickle ice, 
> offers for trickle ice will always start with zero candidates, and so 
> the trickling will always use UDP/DTLS/RTP/SAVPF from the start. 

Of course, I meant "UDP/TLS/RTP/SAVPF"

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 24 Jan 2019 13:13:52 -0800

Thanks Adam for the proposal. I do feel this is a reasonable way forward

Thanks
Suhas

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Jan 2019 09:23:08 -0800

I'm not yet persuaded this is needed. The alleged need here is that there
are some ICE-implementing endpoints which will choke if they see a profile
that doesn't match any actual candidate. I recognize that this is required
by 5245, but that doesn't mean anyone ever did it. Can you please point me
to a client which would interoperate with a WebRTC endpoint with this
change that would not if you just always sent the same profile as JSEP
currently requires.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Sat, 26 Jan 2019 17:45:17 -0800

I agree with Eric, but in the interest of moving forward, I am willing to
live with the relatively straightforward solution of using TCP in the m=
line when the default candidate is a TCP candidate.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 27 Jan 2019 11:21:56 +0000

Hi,

> I'm not yet persuaded this is needed. The alleged need here is that there are some ICE-implementing endpoints which will choke if
> they see a profile that doesn't match any actual candidate. I recognize that this is required by 5245, but that doesn't mean anyone
> ever did it. Can you please point me to a client which would interoperate with a WebRTC endpoint with this change that would not
> if you just always sent the same profile as JSEP currently requires.

I don't think it is ok to *specify* that discarding a MUST is ok as long as nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generally ok with Adam's approach. I would like my pull request comments to be addressed, though, that is related to separation between the JSEP API and an application using it: an application should be allowed to act according to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to the way the JSEP API works such applications might sometimes always include the same value in the c/m- line.

I also think it shall be explicitly written that JSEP does not update 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer

On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

/a

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 28 Jan 2019 14:51:05 -0800

Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a consensus.
This basically says that the offerer fills in either UDP/TLS/foo or
TCP/DTLS/foo based on the current default or selected candidate, in
accordance with sip-sdp. As Adam mentioned before, this shouldn't have any
impact on JSEP functionality.

If this looks good, I'll polish it up.

On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
> > I'm not yet persuaded this is needed. The alleged need here is that
> there are some ICE-implementing endpoints which will choke if
> > they see a profile that doesn't match any actual candidate. I recognize
> that this is required by 5245, but that doesn't mean anyone
> > ever did it. Can you please point me to a client which would
> interoperate with a WebRTC endpoint with this change that would not
> I don't think it is ok to *specify* that discarding a MUST is ok as long
> as nobody can show an implementation that would break by doing so.
>
> Having said that, in order to prevent an RTCWEB shutdown I am generally ok
> with Adam's approach. I would like my pull request comments to be
> addressed, though, that is related to separation between the JSEP API and
> an application using it: an application should be allowed to act according
> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to
> the way the JSEP API works such applications might sometimes always include
> the same value in the c/m- line.
>
> I also think it shall be explicitly written that JSEP does not update
> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.
>
> Regards,
>
> Christer
>
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 28 Jan 2019 17:57:32 -0500

This looks good to me.
_____________
Roman Shpount

On Mon, Jan 28, 2019 at 5:51 PM Justin Uberti <juberti=
[email-masked]> wrote:

> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a
> consensus. This basically says that the offerer fills in either UDP/TLS/foo
> or TCP/DTLS/foo based on the current default or selected candidate, in
>> Having said that, in order to prevent an RTCWEB shutdown I am generally
>> ok with Adam's approach. I would like my pull request comments to be

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 16:35:26 -0800

If we assume that this is a real problem as opposed to a specification
problem, then I agree this is reasonable. However, so far nobody has shown
me that this is a real problem, and until that this happens, I'm not in
favor.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Jan 2019 09:46:33 +0900

> me that this is a real problem, and until that this happens, I'm not in
As a chair, I wish to confirm my understanding:  you have no technical
objection to this solution, but you do not wish to include this because you
have seen no evidence of the problem.  Is that correct?

Yours is, at the moment, the only objection I have seen.  Before going to a
call for a consensus, I want to make sure that the nature of any objection
is as clear as possible.

thanks,

Ted

>>> > they see a profile that doesn't match any actual candidate. I
>>> recognize that this is required by 5245, but that doesn't mean anyone

---

From: Roman Shpount <[email-masked]>
Date: Mon, 28 Jan 2019 19:50:25 -0500

On Mon, Jan 28, 2019 at 7:36 PM Eric Rescorla <[email-masked]> wrote:

> What would you consider a real problem?

Would the fact that SDP manipulation in WebRTC JavaScript client or on the
server to work with WebRTC be considered a real problem or a minor
inconvenience?

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 16:55:53 -0800

> have seen no evidence of the problem.  Is that correct?

No. I object to it because it's unnecessary complexity and moves against
the consensus direction that we had that this field was meaningless.

If it's necessary, then I'm willing to live with it.

-Ekr

> Yours is, at the moment, the only objection I have seen.  Before going to
> a call for a consensus, I want to make sure that the nature of any
> objection is as clear as possible.
>
> thanks,
>
> Ted
>
>
>
>
>>>> I don't think it is ok to *specify* that discarding a MUST is ok as
>>>> long as nobody can show an implementation that would break by doing so.
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 16:58:44 -0800

>> What would you consider a real problem?

A system with substantial deployment that works properly with WebRTC if the
default candidates are UDP but not when the default candidates are TCP and
the proto is UDP/foo

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Jan 2019 19:09:43 -0600

[as an individual]

On 1/28/19 6:55 PM, Eric Rescorla wrote:
> it's unnecessary complexity

To make sure we're not all overlooking something that is obvious to you 
-- can you describe the complexity involved here?

/a

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Jan 2019 10:09:48 +0900

In-line.

On Tue, Jan 29, 2019 at 9:56 AM Eric Rescorla <[email-masked]> wrote:

> That consensus was limited to JSEP; other related uses of SIP/SDP do not
treat it as meaningless.

The additional complexity added to a system is, of course, always a
concern.  But  I interpret your statement "If it's necessary, then I'm
willing to live with it." as agreeing that this solution will work if the
additional domain of interoperability which results is not empty.

Please correct me, if I have gotten this wrong.

thanks,

Ted

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 17:23:27 -0800

On Mon, Jan 28, 2019 at 5:10 PM Ted Hardie <[email-masked]> wrote:

>> That consensus was limited to JSEP;
>

Yes, and we're talking about the JSEP spec here.

other related uses of SIP/SDP do not treat it as meaningless.

That seems to be assuming the answer to my question.

> additional domain of interoperability which results is not empty.

No, that's not what I said. What I said was "A system with substantial
deployment that works properly with WebRTC if the default candidates are
UDP but not when the default candidates are TCP and the proto is UDP/foo"

-Ekr

>>>>> Having said that, in order to prevent an RTCWEB shutdown I am
>>>>> generally ok with Adam's approach. I would like my pull request comments to
>>>>> be addressed, though, that is related to separation between the JSEP API
>>>>> and an application using it: an application should be allowed to act
>>>>> according to 5245/draft-ice-sdp and update the c/m line if it wishes to,
>>>>> but due to the way the JSEP API works such applications might sometimes
>>>>> always include the same value in the c/m- line.
>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 17:24:25 -0800

> -- can you describe the complexity involved here?

Having to condition what you put in the proto line depending on the
candidates is more complexity than not having to do so.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Jan 2019 02:26:33 +0100

On Tue, 29 Jan 2019 at 02:10, Ted Hardie <[email-masked]> wrote:

> That consensus was limited to JSEP; other related uses of SIP/SDP do not treat it as meaningless.
>
> The additional complexity added to a system is, of course, always a concern.  But  I interpret your statement "If it's necessary, then I'm willing to live with it." as agreeing that this solution will work if the additional domain of interoperability which results is not empty.

The summary is basically that it adds extra complexity to WebRTC
without absolutely any advantage or added feature. Anyway:

> Implementations MUST indicate this profile for each media m= line they
produce in an offer unless the media section contains only TCP candidates;
if all candidates use TCP as a transport, implementations MUST indicate
"TCP/DTLS/RTP/SAVPF," to allow for compatibility with non-WebRTC
implementations

Some concerns:

1) Browser and WebRTC "clients" will always offer UDP candidates, so
the above is not likely to happen.

2) If it happens (there are just TCP candidates) this is probably
because the server mandates TCP, so the "service monitoring system"
already knows that.

3) The browser offers UDP and TCP candidates so will place
"UDP/TLS/RTP/SAVPF" in the transport. Then the server replies with
just TCP candidates. I assume that the server would also use
"UDP/TLS/RTP/SAVPF" in the answer (because it must match the transport
value in the offer) but, do we expect that the browser will "send a
re-offer with TCP/DTLS/RTP/SAVPF" to conform to this spec? That won't
happen. So how is this useful at all for the service monitoring
system?

Instead of all this folklore, couldn't the "phone" just send a
multi-purpose OPTIONS somewhere once it knows the selected ICE tuple
and we are done? That can be easily implemented in flexible SIP and
WebRTC stacks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Jan 2019 19:42:05 -0600

On 1/28/19 7:24 PM, Eric Rescorla wrote:
>
>
> On Mon, Jan 28, 2019 at 5:10 PM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [as an individual]
>

Thanks. I think we're all on the same page regarding complexity.

/a

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Jan 2019 11:05:22 +0900

> UDP but not when the default candidates are TCP and the proto is UDP/foo"

 When we call for consensus, we will take this into account.

My current plan is to discuss the timing with Sean tomorrow (Japan time)
and call for consensus by the end of the week, with the usual time frames.

Ted

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 04:10:21 -0500

Iñaki,

Please consider the following:

1. Browser client is placed behind the firewall which only allows TCP
connections

2. No TURN servers are configured

3. Client establishes connection to a server which supports ICE TCP

4. ICE nomination completes

5. Client browser app calls createOffer with no options (ICE restart option
is not present)

Based on the current set of specifications, in this case ICE nomination is
complete and the TCP candidate is nominated. No other candidates should be
present in the offer.

Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Jan 2019 13:02:43 +0100

Hi, Roman.

In SIP world (and in many others) 5 will happen before 3, so I don't
understand. Do I miss something?

El mar., 29 ene. 2019 10:10, Roman Shpount <[email-masked]> escribió:

> 5. Client browser app calls createOffer with no options (ICE restart
> option is not present)
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 08:36:13 -0500

1-4 are for initial connection. 5 is for the new offer. It can be a "fix
up" offer or simply an offer which happened not to change transport
parameters and is simply adding a codec.

I can write this up in more detail if you need.

Roman Shpount

On Tue, Jan 29, 2019, 7:02 AM Iñaki Baz Castillo <[email-masked] wrote:

>> Based on the current set of specifications, in this case ICE nomination
>> is complete and the TCP candidate is nominated. No other candidates should
>> be present in the offer.
>>
>> Roman Shpount
>>
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 29 Jan 2019 09:46:10 -0800

What I don’t quite understand here: 1-4 with the initial connection will use UDP in the protocol field. Only the subsequent re-offer from step 5 on would use TCP in the protocol field. How come that 1-4 works, but 5 does not?

Best
  Nils Ohlmeier

> On 29Jan, 2019, at 05:36, Roman Shpount <[email-masked]> wrote:
> 
> 1-4 are for initial connection. 5 is for the new offer. It can be a "fix up" offer or simply an offer which happened not to change transport parameters and is simply adding a codec.
> 
> On Tue, Jan 29, 2019, 7:02 AM Iñaki Baz Castillo <[email-masked] <mailto:[email-masked]> wrote:
> Hi, Roman.
> 
> In SIP world (and in many others) 5 will happen before 3, so I don't understand. Do I miss something?
> 
> El mar., 29 ene. 2019 10:10, Roman Shpount <[email-masked] <mailto:[email-masked]>> escribió:
> Iñaki,
> 
> 1. Browser client is placed behind the firewall which only allows TCP connections
> 
> 5. Client browser app calls createOffer with no options (ICE restart option is not present)
> 
> Based on the current set of specifications, in this case ICE nomination is complete and the TCP candidate is nominated. No other candidates should be present in the offer.
> 
> Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Jan 2019 18:50:48 +0100

> What I don’t quite understand here: 1-4 with the initial connection will use UDP in the protocol field. Only the subsequent re-offer from step 5 on would use TCP in the protocol field. How come tha…

The sysadmin realized about dangerous and suspicious UDP traffic so
changed the firewall rules. He also blocked ICMP (for security!!!) but
that's not a problem because static constexpr uint16_t MTU = 1200.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 13:05:40 -0500

On Tue, Jan 29, 2019 at 12:46 PM Nils Ohlmeier <[email-masked]>
wrote:

> What I don’t quite understand here: 1-4 with the initial connection will
> use UDP in the protocol field. Only the subsequent re-offer from step 5 on
> would use TCP in the protocol field. How come that 1-4 works, but 5 does
> not?
>
>
During steps 1-4, browser client sends an offer which includes both UDP and
TCP candidates. It is using one of the UDP candidates as a default
candidate in c= and m= line (proto is UDP/... something). Server, also
responds with UDP and TCP candidates. It also uses one of the UDP
candidates as a default candidate in c= and m= line (proto is UDP/...
something). Since client location blocks everything except TCP, only the
connectivity check for TCP candidate pair succeeds and TCP candidate gets
nominated. Once ICE nomination process is completed, new offer is generated
from the client without ICE restart (for instance to add a codec or
initiate "fix up" offer). This offer must include locally nominated
candidate pair and no other candidates (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2).
This means this offer will only have TCP candidates present. This TCP
candidate is the default candidate and will be used in c= and m= line
resulting in TCP/... proto in the m= line.

There is literally one call scenario here which is affected. TCP candidates
should not be used as default candidates or TCP based proto should not be
used in the m= line in the offer in any other scenario.

If you do not understand this scenario, please ask questions before
commenting.

Thank You,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 13:07:59 -0500

> that's not a problem because static constexpr uint16_t MTU = 1200.
This has absolutely nothing to do whit what we are discussing.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Jan 2019 19:33:18 +0100

On Tue, 29 Jan 2019 at 19:05, Roman Shpount <[email-masked]> wrote:

> During steps 1-4, browser client sends an offer which includes both UDP and TCP candidates. It is using one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Server, also responds with UDP and TCP candidates. It also uses one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Since client location blocks everything except TCP, only the connectivity check for TCP candidate pair succeeds and TCP candidate gets nominated. Once ICE nomination process is completed, new offer is generated from the client without ICE restart (for instance to add a codec or initiate "fix up" offer). This offer must include locally nominated candidate pair and no other candidates (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2). This means this offer will only have TCP candidates present. This TCP candidate is the default candidate and will be used in c= and m= line resulting in TCP/... proto in the m= line.

This is a very good point:

> This (re)offer must include locally nominated candidate pair and no other candidates

But how is the draft above useful at all if browsers do not set the
selected candidate into c=/m= lines during a re-offer? Imagine browser
do implement the draft above and, indeed, they set "TCP/DTLS/..." in
the proto line of the re-offer with just TCP candidates. Assuming that
they do NOT set the selected candidate pair in the m=/c= line, this is
just valid to know whether UDP or TCP has been selected, nothing else.
Am I wrong?

In the other side, and assuming this is about JavaScript SIP+WebRTC
clients, wouldn't it work if they mangle the SDP re-offer? By checking
the peerconnection stats you can know the selected candidate and so
on.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 13:48:37 -0500

On Tue, Jan 29, 2019 at 1:33 PM Iñaki Baz Castillo <[email-masked]> wrote:

> > During steps 1-4, browser client sends an offer which includes both UDP
> and TCP candidates. It is using one of the UDP candidates as a default

One way to interpret JSEP in its current state, that it specifies that
address and port in c= and m= line should be updated to the selected
candidate, but proto should always be UDP/..., even if address in c= and
port in m= lines are from the TCP candidate. All I am asking, is if end
point updates address c= and port in m= line, it should update the proto to
match.

> the peerconnection stats you can know the selected candidate and so
JS SIP + WebRTC clients are one of the issues. For instance, it is possible
to build a network using JS SIP clients (jssip works great :), regular VoIP
clients that support DTLS-SRTP (for instance something pjsip based), and
SBC which support DTLS-SRTP+ICE TCP. All are connected to the SIP-over-WS
enabled proxy. CDRs and monitoring are done from proxy using proxy
generated CDR and SIP signaling capture using something like SIP Homer. The
simplest way to get client connection information is by using "fix-up"
offers and extracting data from SIP signaling. It is possible to build a
separate monitoring solution for WebRTC clients using stats, but using
existing SIP based solutions already works well enough except for bogus
info about nominated candidate in c= and m= lines.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Jan 2019 20:05:31 +0100

I understand your point. But still I don't understand the purpose of the
new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates
in the offer).

Of course, if browser follow the ICE spec and set the selected candidate in
the c/m lines, they must also indicate whether that is over UDP or TCP. The
problem here is what such a proto line is intended to mean when there is
ICE candidates of UDP and TCP. But ok, let's assume that browser do update
c/m lines in the trigger with the selected candidate, and they JUST change
the proto line to TCP/DTLS if there are just TCP candidates. Now thing
about this scenario:

1) Client initial offer with UDP and TCP candidates.

2) Server answers with both UDP and TCP candidates.

3.1) UDP is selected. Re-offer is created with just UDP candidates (as per
spec).

3.2) or TCP is selected. Re-offer is created with just TCP candidates (as
per specs).

In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the proto
line. It can just check the protocol (UDP or TCP) of *any* candidate in the
offer to know whether UDP or TCP was selected.

Am I wrong?

El mar., 29 ene. 2019 19:48, Roman Shpount <[email-masked]> escribió:

> JS SIP + WebRTC clients are one of the issues. For instance, it is
> possible to build a network using JS SIP clients (jssip works great :),
> regular VoIP clients that support DTLS-SRTP (for instance something pjsip
> based), and SBC which support DTLS-SRTP+ICE TCP. All are connected to the
> SIP-over-WS enabled proxy. CDRs and monitoring are done from proxy using
> proxy generated CDR and SIP signaling capture using something like SIP
> Homer. The simplest way to get client connection information is by using
> "fix-up" offers and extracting data from SIP signaling. It is possible to
> build a separate monitoring solution for WebRTC clients using stats, but
> using existing SIP based solutions already works well enough except for
> bogus info about nominated candidate in c= and m= lines.
>
> Regards,
> _____________
> Roman Shpount
>
>

---

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

> new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates

The purpose is standard compliance. If nominated candidate is UDP, proto
line should be UDP. If nominated candidate is TCP, proto line should be
TCP. If you do not care about the c= and m= line, put the dummy values and
UDP there, but this breaks legacy interop by causing ICE mismatch. Putting
UDP proto and address from TCP candidate breaks legacy interop as well, but
it is typically localized to provider managed server, so it is possible to
patch around this either in JS client or on the server to treat WebRTC
clients differently. Alternatively, WebRTC clients can add a couple lines
of code and become compliant with the RFC they decided to implement and
remove the need for patching.

> In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the
> proto line. It can just check the protocol (UDP or TCP) of *any* candidate
> in the offer to know whether UDP or TCP was selected.
>
> Am I wrong?
>

You are correct. Checking c= and m= line is simply to avoid checking and
parsing ICE candidates. If monitoring client would handle ICE candidates,
then the monitoring client would still need to figure out which candidate
is default to record client media IP. Keeping c= and m= line in sync with
default candidate on the client seemed to cause the least amount of
problems which is why it was left in ice-sip-sdp.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Jan 2019 13:52:43 -0800

On Tue, Jan 29, 2019 at 11:28 AM Roman Shpount <[email-masked]> wrote:

> UDP there, but this breaks legacy interop by causing ICE mismatch.
>

This is two separate statements that don't necessarily follow form each
other

1. This is a matter of standards compliance.
2. It breaks legacy interop

I agree on point (1). I'm still waiting for someone to demonstrate point (2)

-Ekr

Putting UDP proto and address from TCP candidate breaks legacy interop as
> well, but it is typically localized to provider managed server, so it is
> possible to patch around this either in JS client or on the server to treat
> WebRTC clients differently. Alternatively, WebRTC clients can add a couple
> lines of code and become compliant with the RFC they decided to implement
> and remove the need for patching.
>
> Of course, if browser follow the ICE spec and set the selected candidate
>> in the c/m lines, they must also indicate whether that is over UDP or TCP.
>> The problem here is what such a proto line is intended to mean when there
>> is ICE candidates of UDP and TCP. But ok, let's assume that browser do
>> update c/m lines in the trigger with the selected candidate, and they JUST
>> change the proto line to TCP/DTLS if there are just TCP candidates. Now
>> thing about this scenario:
>>
>> 3.1) UDP is selected. Re-offer is created with just UDP candidates (as
>> per spec).
>>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Jan 2019 17:08:23 -0500

> I agree on point (1). I'm still waiting for someone to demonstrate point
Unfortunately 2 is impossible to demonstrate to your satisfaction since:

a. Browsers currently do something different from the spec (once again is
being debated) and include additional candidates even after ICE nomination
was completed

b. Using UDP based proto when TCP based candidate is nominated only affects
server provider SBC or media servers. These components are typically easier
to patch when dealing with non-compliant implementations similar to current
JSEP clients. What you are arguing is to keep the "special" profile for
SBC/Media Servers indefinitely instead of making browsers and VoIP end
points do the same thing. This is simply moving the complexity from one
place to another.

As an observation, since JSEP currently mandates that c= and m= lines are
already updated (address and port) based on the ICE candidate which is
nominated, I am not sure if additional complexity of updating the proto
line at the same time is all that great.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 30 Jan 2019 00:21:51 +0100

On Tue, 29 Jan 2019 at 20:28, Roman Shpount <[email-masked]> wrote:
> WebRTC clients can add a couple lines of code and become compliant with the RFC they decided to implement and remove the need for patching.

I can just agree. If vendors do not want to implement something in the
spec they should fight the spec itself and not those who try to
conform to it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2019 14:16:39 +0000

Hi,

It is also worth noting that this is not something that has recently changed in ICE, which could be a reason why there are existing deployments doing things differently. 

Regards,

Christer

On 30/01/2019, 1.22, "rtcweb on behalf of Iñaki Baz Castillo" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Iñaki Baz Castillo
    <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2019 14:21:29 +0000

Hi,

>>> I understand your point. But still I don't understand the purpose of the new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates in the offer).
>> 
>> The purpose is standard compliance. If nominated candidate is UDP, proto line should be UDP. If nominated candidate is TCP, proto line should be TCP. 
>> If you do not care about the c= and m= line, put the dummy values and UDP there, but this breaks legacy interop by causing ICE mismatch.
>>
>> This is two separate statements that don't necessarily follow form each other
>>

There are networks where nodes (not always SBCs) use the c/m- information to control network resources (e.g., radio bandwidth). Whether UDP vs TCP will have a major impact I don't know, but the point is that the c/m- information IS used.

Whether the WG has agreed that the c/m- information is "meaningless" in the JSEP API I don't know, but it for sure is not "meaningless" on the wire.

Regards,

Christer

Putting UDP proto and address from TCP candidate breaks legacy interop as well, but it is typically localized to provider managed server, so it is possible to patch around this either in JS client or on the server to treat WebRTC clients differently. Alternatively, WebRTC clients can add a couple lines of code and become compliant with the RFC they decided to implement and remove the need for patching.

Of course, if browser follow the ICE spec and set the selected candidate in the c/m lines, they must also indicate whether that is over UDP or TCP. The problem here is what such a proto line is intended to mean when there is ICE candidates of UDP and TCP. But ok, let's assume that browser do update c/m lines in the trigger with the selected candidate, and they JUST change the proto line to TCP/DTLS if there are just TCP candidates. Now thing about this scenario:

3.1) UDP is selected. Re-offer is created with just UDP candidates (as per spec).

3.2) or TCP is selected. Re-offer is created with just TCP candidates (as per specs).

In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the proto line. It can just check the protocol (UDP or TCP) of *any* candidate in the offer to know whether UDP or TCP was selected.

Am I wrong?

You are correct. Checking c= and m= line is simply to avoid checking and parsing ICE candidates. If monitoring client would handle ICE candidates, then the monitoring client would still need to figure out which candidate is default to record client media IP.. Keeping c= and m= line in sync with default candidate on the client seemed to cause the least amount of problems which is why it was left in ice-sip-sdp.

Regards,
_____________
Roman Shpount
 
mailto:[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 30 Jan 2019 10:58:27 -0500

On Mon, Jan 28, 2019 at 8:25 PM Eric Rescorla <[email-masked]> wrote:

> I just want to note that m= line containing the proto field already
depends on ICE candidates present in the offer and that the port in m= line
already required to be updated whenever default (active in JSEP which is
even more common) candidate changes. We are talking about dynamically
generated string and discussing complexity of updating one or two parts of
this string based on the same condition while keeping them in sync. I would
assume additional complexity required for this is minimal.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Jan 2019 13:21:44 -0800

On Wed, Jan 30, 2019 at 6:21 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >>> I understand your point. But still I don't understand the purpose of
> the new draft (set TCP/DTLS/etc in proto line if there are just TCP
> candidates in the offer).
> >>
> >> The purpose is standard compliance. If nominated candidate is UDP,
> proto line should be UDP. If nominated candidate is TCP, proto line should
> be TCP.
> >> If you do not care about the c= and m= line, put the dummy values and
> There are networks where nodes (not always SBCs) use the c/m- information
> to control network resources (e.g., radio bandwidth). Whether UDP vs TCP
> will have a major impact I don't know, but the point is that the c/m-
> information IS used.
>

> Whether the WG has agreed that the c/m- information is "meaningless" in
> the JSEP API I don't know, but it for sure is not "meaningless" on the wire.
>

We're talking solely about the format field in this discussion, and the
whole import of the decision have a fixed field was that in fact we agreed
it was meaningless.

-Ekr

> is default to record client media IP.. Keeping c= and m= line in sync with

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2019 21:56:34 +0000

Hi,

…

>>There are networks where nodes (not always SBCs)
>> use the c/m- information to control network
>> resources (e.g., radio bandwidth). Whether UDP vs
>> TCP will have a major impact I don't know, but the
>> point is that the c/m- information IS used.
>>
>> Whether the WG has agreed that the c/m-
>> information is "meaningless" in the JSEP API I don't
>> know, but it for sure is not "meaningless" on the
>> wire.
>
>We're talking solely about the format field in this
>discussion,

I assume you meant the proto field?

> and the whole import of the decision have a fixed
> field was that in fact we agreed it was
>meaningless.

Perhaps it's meaningless in the JSEP API, and even for WebRTC endpoints, as they are required to support ICE, but I don't agree on a general statement that it is meaningless on the wire. There are entities that make policy decisions based on the information in the c/m- lines.

Regards,

Christer