Subject: [rtcweb] Draft Minutes

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Nov 2018 10:04:04 -0800

Attached are the draft minutes from the IETF 103 meeting; thanks to
Jonathan Lennox for taking the notes.

Please review and provide corrections to the list.

thanks,

Ted, Sean, (and it feels odd not have a third name here)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 13:28:23 -0500

Hi All,

The current language in JSEP makes it incompatible with any ICE
implementation, either existing or the future ones compliant with
ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this will
mean JSEP will be a completely incompatible system.

The problem is that JSEP proposes to use UDP protocol in the m= line and at
the same time update address and port to the currently selected candidate.
Based on ice-sip-sdp, if protocol of the current selected candidate does
not match protocol in the m= line, this will mean either ICE mismatch or
additional candidate with protocol, address, and port form m= and c= line.

Second, ice-sip-sdp treats SDP during ICE restart, when multiple candidates
are present different from SDP when ICE is not restarted (single
candidate). According to ice-sip-sdp, when only a single candidate is
present, this candidate protocol, address and port are set in m= and c=
line. JSEP proposes to put original UDP protocol and address and port from
the single candidate.

To be specific, it is not the fact that protocol in m= line is not updated
is an issue. It is that protocol in not updated but address and port in m=
and c= line are updated. In the ice-sip-sdp draft there is a solution for
this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is
specifically supposed to be ignored and not cause the ICE mismatch or extra
candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m-
line protocol should always be set to UDP based protocol, c= line address
should be set to   IN IP4 0.0.0.0 and m= line port set to 9. In case of an
ICE only system where c= and m= line address information is irrelevant,
this makes implementation simpler since m= and c= line address information
can stay constant for the duration of the session.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 Nov 2018 10:34:51 -0800

IIRC, one reason JSEP chose the behavior described is because
5245-compliant implementations would declare an ICE mismatch if we used a
bogus address/port in the c=/m= lines. Is this not a problem?

On Mon, Nov 19, 2018 at 10:28 AM Roman Shpount <[email-masked]> wrote:

> mean JSEP will be a completely incompatible system..
>
> The problem is that JSEP proposes to use UDP protocol in the m= line and
> at the same time update address and port to the currently selected
> candidate. Based on ice-sip-sdp, if protocol of the current selected
> candidate does not match protocol in the m= line, this will mean either ICE
> mismatch or additional candidate with protocol, address, and port form m=
> and c= line.
>
> Second, ice-sip-sdp treats SDP during ICE restart, when multiple
> candidates are present different from SDP when ICE is not restarted (single
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 14:30:52 -0500

> bogus address/port in the c=/m= lines. Is this not a problem?

RFC 5245 compatibility is a problem, but I assume we were past this point
and was trying to propose something that at least is going to be compatible
with ice-sip-sdp. BTW, Edge browser with RTCPeerConnection-shim is already
putting 0.0.0.0 and port 9 in all session descriptions:

v=0 o=thisisadapterortc 3331475186201587 0 IN IP4 127.0.0.1 s=- t=0 0
a=group:BUNDLE mzxjdusv69 a=ice-options:trickle m=audio 9 UDP/TLS/RTP/SAVPF
104 102 0 8 103 97 13 118 101 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0
(codec parameters removed for clarity)
a=maxptime:100 a=rtcp-mux a=extmap:1
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://skype.com/experiments/rtp-hdrext/fast_bandwidth_feedback#version_2
a=ice-ufrag:x+3s a=ice-pwd:Re8NpJqQfXVtpbOg7oBgmoHL a=setup:actpass
a=fingerprint:sha-256
14:B5:2D:3D:0E:CE:E9:F1:F7:E3:56:A6:55:DD:23:BD:1A:65:F0:FE:64:B5:78:30:FA:64:06:9B:F0:8B:D2:3D
a=mid:mzxjdusv69 a=sendrecv a=msid:6E374666-5BBB-43E9-B1C2-89312C920723
BD9F838A-5483-42E5-99A7-A861999D5C0A a=ssrc:1001
msid:6E374666-5BBB-43E9-B1C2-89312C920723
BD9F838A-5483-42E5-99A7-A861999D5C0A a=ssrc:1001 cname:m4gynh3dc1
a=rtcp-rsize a=candidate:1 1 UDP 2130706431 172.129.12.1 63862 typ host
ufrag x+3s a=candidate:2 1 UDP 2130705919 10.7.18.135 55458 typ host ufrag
x+3s a=candidate:3 1 TCP 1684798463 172.129.12.1 63862 typ srflx raddr
172.29.182.1 rport 63862 tcptype active ufrag x+3s a=end-of-candidates

If RFC 5245 compatibility is required, it means offer/answer exchange with
no trickle, session refresh after nomination completion, and using default
candidate protocol, address and port in c= and m= line. No trickle and
session refresh can be achieved through existing API. Setting protocol,
address, and port in c= and m= line is harder and will require SDP mangling.

When ICE-SIP-SDP and related protocols were discussed in mmusic, in order
to be RFC 5245 compatible, the plan was to:
1. Use protocol, address, and port of the default candidate in c= and m=
lines
2. In order to avoid protocol mismatch during offer/answer, require in
specific protocol specifications, such as sctp-sdp, that end points should
implement UDP based transport and use it as default transport during ICE
restart in both offer and answer
3. In subsequent offers, where only a single candidate is present, use
protocol, address and port of this candidate in c= and m= lines

This means the same protocol should always be used for the specific m= line
during offer/answer, but it can change between offer/answer exchanges. For
instance, m= line which was UDP/DTLS/SCTP during the initial exchange, can
become TCP/DTLS/SCTP in subsequent exchange, and then change back to
UDP/DTLS/SCTP when ICE restart is initiated. It was assumed that it should
not be a problem but JSEP is currently trying to overwrite this. I
understand this is ugly, but this was the only thing we came up with to
keep things compatible with existing implementations.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 20:36:18 +0100

On Mon, 19 Nov 2018 at 19:28, Roman Shpount <[email-masked]> wrote:
> The problem is that JSEP proposes to use UDP protocol in the m= line and at the same time update address and port to the currently selected candidate. Based on ice-sip-sdp, if protocol of the current selected candidate does not match protocol in the m= line, this will mean either ICE mismatch or additional candidate with protocol, address, and port form m= and c= line.

We could just assume that no WebRTC capable endpoint will (absolutely
never) rely on the content of the c= line or the proto indicated in
the m= line (no matter it indicates "CHICKEN" as proto).

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

---

From: T H Panton <[email-masked]>
Date: Mon, 19 Nov 2018 19:49:16 +0000

> On 19 Nov 2018, at 19:36, Iñaki Baz Castillo <[email-masked]> wrote:
> 

or QUIC
?

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 15:02:08 -0500

> the m= line (no matter it indicates "CHICKEN" as proto).

This is incorrect. Only the transport part of the proto line does not
matter since it is overwritten by the ICE candidate. The rest of the proto
is needed to know if this m= line is audio, video, or data channel.

In any case, this is about interop with existing (and already WebRTC
compatible) implementations. At this point, I would be happy, if either c=
and m= line were populated by some constant data or modified based on rules
which serve some purpose like legacy interop. I would actually greatly
prefer former, but if someone still cares about RFC 5245 interop will be
fine with the later. Right now JSEP requires to change the c= and m= line
but does not achieve the interop.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 21:08:50 +0100

On Mon, 19 Nov 2018 at 21:02, Roman Shpount <[email-masked]> wrote:
> This is incorrect. Only the transport part of the proto line does not matter since it is overwritten by the ICE candidate. The rest of the proto is needed to know if this m= line is audio, video, or data channel.

Yes, I just meant the "proto" component.

> In any case, this is about interop with existing (and already WebRTC compatible) implementations. At this point, I would be happy, if either c= and m= line were populated by some constant data

If it's an already WebRTC compatible device, then it does not need to
read the IP in c= nor the proto in m=.

> or modified based on rules which serve some purpose like legacy interop.

Which interop? If a peer is WebRTC compatible then it MUST use ICE, so
whatever is written in the c= line and whatever the m= protoo is, it
won't need to read it. And if the other party is "legacy" and does not
implement WebRTC, then they both just can not communicate.

So this is just cosmetic and has zero value. And there are endless
discussions about this topic for the last 3-4 years just because those
fields exist in the SDP.

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 15:20:53 -0500

On Mon, Nov 19, 2018 at 3:09 PM Iñaki Baz Castillo <[email-masked]> wrote:

> ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that these
fields are not cosmetic. All I am asking is to put values in these fields
that indicate that they are cosmetic instead of creating some rules on how
these fields should change which would cause potential interop issues.

BTW, there are plenty of VoIP phones which use ICE and support Opus (or
G.711). They will also produce ICE mismatch since they implement RFC 5245.
So, these end points are WebRTC compatible except for this specific issue.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 21:31:13 +0100

On Mon, 19 Nov 2018 at 21:21, Roman Shpount <[email-masked]> wrote:
> ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that these fields are not cosmetic. All I am asking is to put values in these fields that indicate that they are cosmetic instead of creating some rules on how these fields should change which would cause potential interop issues.

I suggest:

m=KIND 9 ICE [codec PTs]

> BTW, there are plenty of VoIP phones which use ICE and support Opus (or G.711). They will also produce ICE mismatch since they implement RFC 5245. So, these end points are WebRTC compatible except for this specific issue.

If those phones already implement ICE (and let's assume also
DTLS-SRTP), how will a wrong or "invalid" c= or m= content affect
them? Browsers won't complain no matter what the SDP re-offer contains
in those lines, so the phone can put whatever it wishes. And the phone
should not read them in received SDP re-offers, so I don't fully
understand what the problem is.

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 15:47:44 -0500

> these fields should change which would cause potential interop issues.

If you are re-inventing the protocol, why would you build SDP or m= lines?
If you are using an existing protocol, why do you modify it in the way it
is not compatible with anything in existence?

I am suggesting always doing something like:

m=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=IN IP4 0.0.0.0

Do you see any issues with this except being aesthetically offended?

> understand what the problem is.

Please read
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
Some people for some reason insist on following specifications. If you
propose to do two opposite things, random things start being implemented.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 21:53:36 +0100

>> I suggest:
>>
>> m=KIND 9 ICE [codec PTs]
>
>
> If you are re-inventing the protocol, why would you build SDP or m= lines? If you are using an existing protocol, why do you modify it in the way it is not compatible with anything in existence?

Why is proto="ICE" not compatible? ICE represents a virtual path that
does not correspond to a specific 5-tuple (such a tuple may
dynamically change without requiring any new SDP O/A).

> Please read https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
> Some people for some reason insist on following specifications. If you propose to do two opposite things, random things start being implemented.

So, that spec is completely making it imposible to enable ICE trickle
because it mandates that the value in c= and m= must already match an
existing a=candidate line in the same SDP. This is not true when using
Trickle ICE since candidates may be sent later that the SDP:

https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 16:08:22 -0500

On Mon, Nov 19, 2018 at 3:53 PM Iñaki Baz Castillo <[email-masked]> wrote:

> > If you are re-inventing the protocol, why would you build SDP or m=
> lines? If you are using an existing protocol, why do you modify it in the
> way it is not compatible with anything in existence?
>

There are differences between AVP/SAVP/SAVPF even when ICE is used. You
quietly discarded them which can cause issues.

If anybody ever implements data channels over QUICK vs SCTP, proto is the
place to specify this. ICE candidates will only tell the end point that UDP
vs TCP,. Kind only tells the type of stream. If there is more then one way
to transport this data (SCTP vs QUICK), proto is required.

Also, you ignored the question that I asked you. What is the issue that you
see with:
m=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=IN IP4 0.0.0.0

> https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18
ICE trickle is supported. Please read  second bullet point of
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 22:16:54 +0100

On Mon, 19 Nov 2018 at 22:08, Roman Shpount <[email-masked]> wrote:

> If anybody ever implements data channels over QUICK vs SCTP, proto is the place to specify this. ICE candidates will only tell the end point that UDP vs TCP,. Kind only tells the type of stream. If there is more then one way to transport this data (SCTP vs QUICK), proto is required.

I understand your points, and you are right in all of them. I just
don't believe that this is gonna happen in SIP world within next 25
years. I mean: in order to explain this you have moved to
DataChannels, which will never exist in SIP-land (BFCP already exists
which is implemented by 2-3 devices).

> Also, you ignored the question that I asked you. What is the issue that you see with:

No problem other than announcing UDP while the effective candidate
pair may use TCP. If that's not a problem, then ok.

> ICE trickle is supported. Please read  second bullet point of https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5

Didn't know that. Thanks.

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 16:20:49 -0500

On Mon, Nov 19, 2018 at 4:17 PM Iñaki Baz Castillo <[email-masked]> wrote:

> > If anybody ever implements data channels over QUICK vs SCTP, proto is
> the place to specify this. ICE candidates will only tell the end point that
> UDP vs TCP,. Kind only tells the type of stream. If there is more then one
> way to transport this data (SCTP vs QUICK), proto is required.
>
In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and
UDP/TLS/RTP/SAVP which is the problem. In first case no encryption is
allowed, in second case SDES-SRTP is required, and in third case DTLS-SRTP
is required. Then there are AVP vs AVPF differences.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Nov 2018 22:24:22 +0100

On Mon, 19 Nov 2018 at 22:21, Roman Shpount <[email-masked]> wrote:
> In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and UDP/TLS/RTP/SAVP which is the problem. In first case no encryption is allowed, in second case SDES-SRTP is required, and in third case DTLS-SRTP is required. Then there are AVP vs AVPF differences.

Instead of UDP/TLS/RTP/SAVP, I still suggest ICE/TLS/RTP/SAVP, so
everything covered. ICE itself handles UDP or TCP, so no need to
specify it in the m= proto.

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 Nov 2018 15:08:38 -0800

Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245
<https://tools.ietf.org/html/rfc5245#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.  For example, in the case of RTP, the IP
   address and port in the c and m lines, respectively, appear in a
   candidate attribute and the value in the rtcp attribute appears in a
   candidate attribute.

Ergo, I don't think this proposal will fly. Of the three options being
considered (below), only #1 avoids violating 5245 while simultaneously
minimizing busywork.

1) (current) Match IP and port, but stipulate an exact proto value
2) Match IP, port and proto
3) Set IP, port, and proto to fixed values

If we think avoiding ice-mismatch when interacting with 5245 endpoints is
not important, that point needs to be made clearly. Otherwise, I think the
easiest path is to update ice-sip-sdp to permit #1 as a legacy interop
behavior (and it can continue to recommend #3 for interop with 8445
clients).

On Mon, Nov 19, 2018 at 1:24 PM Iñaki Baz Castillo <[email-masked]> wrote:

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Nov 2018 19:16:15 -0500

> behavior (and it can continue to recommend #3 for interop with 8445

The RFC 5245 does not define any candidate transports except UDP, so it
does not seem to mention protocol in most of the examples. I believe that
language in 5245 that you are quoting actually specifies that default
address, port and protocol foundation in c= and m= line must match.

Specifically it says that  "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 we look the term definitions,in
https://tools.ietf.org/html/rfc5245#section-3 it says:

Default Destination/Candidate: *The default destination for a component of
a media stream is the transport address that would be used by an agent that
is not ICE aware. *For the RTP component, the default IP address is in the
c line of the SDP, and the port is in the m line. For the RTCP component,
it is in the rtcp attribute when present, and when not present, the IP
address is in the c line and 1 plus the port is in the m line. A default
candidate for a component is one whose transport address matches the
default destination for that component.

Transport Address: The combination of an IP address and transport protocol
(such as UDP or TCP) port.

>From this  it looks like the document simply assumes that port has type
which is UDP or TCP and in order for port to match both its value and type
must match.

Furthermore, without protocol foundation candidate default destination is
ambiguous and cannot be used without ICE.  So, 1, as proposed will likely
to cause ICE mismatch with existing implementations and will not be RFC
5245 compatible.

2 is the only RFC 5245 compatible option.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 Nov 2018 20:41:24 -0800

Are you aware of any implementations that will trigger ICE mismatch if the
proto does not match? Also, this would only happen in situations where the
client offers *only* TCP candidates, which would require manual filtering
by the client and is clearly a corner case.

On Mon, Nov 19, 2018 at 4:16 PM Roman Shpount <[email-masked]> wrote:

> Default Destination/Candidate: *The default destination for a component
> of a media stream is the transport address that would be used by an agent
> that is not ICE aware. *For the RTP component, the default IP address is
> in the c line of the SDP, and the port is in the m line. For the RTCP
> component, it is in the rtcp attribute when present, and when not present,
> the IP address is in the c line and 1 plus the port is in the m line. A
> default candidate for a component is one whose transport address matches
> the default destination for that component.
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Nov 2018 00:31:02 -0500

> by the client and is clearly a corner case.

I think a couple of popular hardware VoIP phones and one widely used SIP
based business communication/messaging product will trigger a mismatch in
case of incorrect protocol (non UDP if UDP candidates are present and non
TCP, if only TCP candidates are present according to their ICE
implementation document). I have to say, that these things do have a
tendency to change between product updates and I have not tested this
product for a while. Our own products currently match the protocol to
default candidate, so we did not need to retest this issue.

TCP based transport will happen for any subsequent offer/answer exchange
when TCP candidate is nominated. Only a single TCP ICE candidate will be
present in the session description, so that protocol in m= line will have
to be TCP. In case of the above mentioned product, their ICE protocol
implementation document says that call must be terminated, if in subsequent
offer, protocol in the m= line does not match the protocol in the ICE
candidate.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 Nov 2018 21:57:47 -0800

On Mon, Nov 19, 2018 at 9:31 PM Roman Shpount <[email-masked]> wrote:

>> Are you aware of any implementations that will trigger ICE mismatch if
>> the proto does not match? Also, this would only happen in situations where
>> the client offers *only* TCP candidates, which would require manual
>> filtering by the client and is clearly a corner case.
>>
>

VoIP phones will almost certainly never receive TCP ICE candidates from a
WebRTC implementation, which only gather active TCP candidates.

Anyway, we have the 3 choices listed below. We differ on which is the most
pragmatic solution. If the WG has enough voices in support of #2 or #3 to
overturn the consensus of #1 from IETF 103, I will write it up accordingly.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Nov 2018 01:15:49 -0500

> overturn the consensus of #1 from IETF 103, I will write it up accordingly.

So the 3 choices are:

1) (current) Match IP and port, but stipulate an exact proto value -- This
choice is not compliant with either RFC 5245 or draft ice-sip-sdp. If this
is selected, ice-sip-sdp will need to be updated
2) Match IP, port and proto -- Compliant with both RFC 5245 and ice-sip-sdp
3) Set IP, port, and proto to fixed values -- Compliant with only
ice-sip-sdp but not with RFC 5245

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Nov 2018 01:26:28 -0500

On Tue, Nov 20, 2018 at 1:15 AM Roman Shpount <[email-masked]> wrote:

>> Anyway, we have the 3 choices listed below. We differ on which is the
>> most pragmatic solution. If the WG has enough voices in support of #2 or #3
>> to overturn the consensus of #1 from IETF 103, I will write it up
>> accordingly.
>>
>
> So the 3 choices are:
>
> choice is not compliant with either RFC 5245 or draft ice-sip-sdp. If
> this is selected, ice-sip-sdp will need to be updated

P.S. There is a compromise option 4) Proto is fixed (UDP).  If default
candidate is UDP, address and port should match the candidate. If default
candidate is TCP, set address to IN IP4 0.0.0.0 and port to 9. This is
compliant with both RFC 5245 and ice-sip-sdp for UDP default candidates,
but only compliant with ice-sip-sdp for TCP default candidates.

Regards,
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Nov 2018 17:10:09 -0700

Sounds like the ice-sip-sdp draft has not concerned itself much with working with the existing deployed endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP solution will work much better in practice. 

This is discussed a bit in 
https://tools.ietf.org/html/rfc6337#section-5.4 <https://tools.ietf.org/html/rfc6337#section-5.4>

> On Nov 19, 2018, at 11:28 AM, Roman Shpount <[email-masked]> wrote:
> 
> Hi All,
> 
> The current language in JSEP makes it incompatible with any ICE implementation, either existing or the future ones compliant with ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this will mean JSEP will be a completely incompatible system..
> 
> Second, ice-sip-sdp treats SDP during ICE restart, when multiple candidates are present different from SDP when ICE is not restarted (single candidate). According to ice-sip-sdp, when only a single candidate is present, this candidate protocol, address and port are set in m= and c= line. JSEP proposes to put original UDP protocol and address and port from the single candidate.
> 
> To be specific, it is not the fact that protocol in m= line is not updated is an issue. It is that protocol in not updated but address and port in m= and c= line are updated. In the ice-sip-sdp draft there is a solution for this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is specifically supposed to be ignored and not cause the ICE mismatch or extra candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m- line protocol should always be set to UDP based protocol, c= line address should be set to   IN IP4 0.0.0.0 and m= line port set to 9. In case of an ICE only system where c= and m= line address information is irrelevant, this makes implementation simpler since m= and c= line address information can stay constant for the duration of the session.
> 
> Regards,
> _____________
> Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Nov 2018 20:25:11 -0500

On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <[email-masked]> wrote:

>
> Sounds like the ice-sip-sdp draft has not concerned itself much with
> working with the existing deployed endpoint which treat 0.0.0.0 as a hold
> indicator. I think the JSEP solution will work much better in practice.
>
> https://tools.ietf.org/html/rfc6337#section-5.4
>
>
I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP,
and recently trickle ICE. The ice-sip-sdp draft did not break anything new.
All of this was broken in RFC 5245. None of these new protocols work with
endpoints which treat 0.0.0.0 as a hold indicator since all of them need
media addresses of both endpoints in order to work. End point cannot use
0.0.0.0 to create a send only stream. Both addresses are still needed to
creat it. All of these new protocols assume that endpoints use
a=sendonly/a=inactive instead of 0.0.0.0. This is not a major problem in
practice, since end points which use 0.0.0.0 hold, do not use ICE or
DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not
put candidate or fingerprint attributes for this m= line, which avoids the
conflict.

If we are being pedantic, it was trickle ICE that decided to re-use 0.0.0.0
hold for other purposes. The ice-sip-sdp simply added that if default
candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never
triggered, which has no effect on using 0.0.0.0 for hold. This language was
added to make ice-sip-sdp implementations to be compatible with future
trickle ICE implementations.

Also, if you are concerned with breaking changes, sdp-bundle changed using
port 0 for disabled m= lines, which will likely break a lot of B2BUA, since
B2BUA often drop all the attributes from disabled ports.

Regards,
_____________
Roman Shpount

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Nov 2018 18:14:06 -0500

It doesn't seem like this thread has reached any conclusion - how do 
people suggest moving forward here ?

Thanks

-- Flemming (with MMUSIC co-chair hat on)

On 11/20/18 8:25 PM, Roman Shpount wrote:
> On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Sounds like the ice-sip-sdp draft has not concerned itself much
>     with working with the existing deployed endpoint which treat
>     0.0.0.0 as a hold indicator. I think the JSEP solution will work
>     much better in practice.
>
> I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, 
> DTLS-SRTP, and recently trickle ICE. The ice-sip-sdp draft did not 
> break anything new. All of this was broken in RFC 5245. None of these 
> new protocols work with endpoints which treat 0.0.0.0 as a hold 
> indicator since all of them need media addresses of both endpoints in 
> order to work. End point cannot use 0.0.0.0 to create a send only 
> stream. Both addresses are still needed to creat it. All of these new 
> protocols assume that endpoints use a=sendonly/a=inactive instead of 
> 0.0.0.0. This is not a major problem in practice, since end points 
> which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. 
> These end points will put 0.0.0.0 and will not put candidate or 
> fingerprint attributes for this m= line, which avoids the conflict.
>
> If we are being pedantic, it was trickle ICE that decided to re-use 
> 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if 
> default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is 
> never triggered, which has no effect on using 0.0.0.0 for hold. This 
> language was added to make ice-sip-sdp implementations to be 
> compatible with future trickle ICE implementations.
>
> Also, if you are concerned with breaking changes, sdp-bundle changed 
> using port 0 for disabled m= lines, which will likely break a lot of 
> B2BUA, since B2BUA often drop all the attributes from disabled ports.
>
> Regards,
> _____________
> Roman Shpount
>
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 27 Nov 2018 15:45:39 -0800

>From the RTCWEB perspective, allowing the current JSEP behavior to remain
and making adjustments to draft-ice-sip-sdp is preferable. I've cc'ed Adam
on this message, because I believe he may ultimately need to weigh in on
the way forward.

Ted

On Tue, Nov 27, 2018 at 3:14 PM Flemming Andreasen <[email-masked]>
wrote:

> default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Nov 2018 18:46:26 -0500

Hi Flemming,

> people suggest moving forward here ?
During this discussion I had a chance to think about this issue quite a bit
and I would suggest the following solution:

As far as I can see, RFC 5245, ice-sip-sdp, jsep-25 section-5.2.2, sctp-sdp,
rand fc4583bis all differentiate between initial offer/answer exchange
which initiates ICE restart and subsequent offer/answer exchanges which do
not. All these documents specify that UDP based m= line proto SHOULD be
used during ICE restart and that proto MUST match the only ICE candidate
present when not doing ICE restart. The only place that does not
differentiate between the two is JSEP Section 5.1.2. This section tries to
simplify things and apply the same rule to both exchanges saying that
"UDP/TLS/RTP/SAVPF"
proto MUST always be used. This is the root cause of the current issue. I
suggest to update JSEP section 5.1.2 to match the rest of the documents to
say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When
ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if
default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto
MUST be used if default (only) candidate is TCP candidate.

While discussing the current issue, I see that there is something that can
be clarified in ice-sip-sdp and potentially in JSEP. Specifically it make
sense to specify better what to do during ICE restart when UDP based proto
is used in the m= line, as it is recommended, but the only candidates
collected are TCP. This can happen in WebRTC implementations due to trickle
ICE, if only TCP candidates are collected initially. Outside of WebRTC this
can happen due to the client generating an answer being configured to
collect only TCP based candidates (Microsoft ICE implementation guide lists
such use case specifically). I think in such cases, if no ICE candidates
match the proto in the m= line, then address IN IP4 0.0.0.0 should be used
in the c= line and port 9 should be used in the m= line. This is consistent
with current behavior of trickle ICE when no candidates have been collected.

In any case, it looks to me that only JSEP section 5.1.2 needs to be
modified to make all the current documents consistent. JSEP is already
being modified to fix this issue, so I would suggest to modify it in a way
that will cause the least disruption. If needed I can provide the pull
request to fix this.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Nov 2018 18:47:41 -0500

On Tue, Nov 27, 2018 at 6:46 PM Ted Hardie <[email-masked]> wrote:

> and making adjustments to draft-ice-sip-sdp is preferable. I've cc'ed
> Adam on this message, because I believe he may ultimately need to weigh in
> on the way forward.
>
>>
>>
Which one? JSEP-25 currently specifies two contradictory things in sections
5.1.2 and 5.2.2.

Regards,
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Nov 2018 09:38:41 -0700

> On Nov 27, 2018, at 4:46 PM, Roman Shpount <[email-masked]> wrote:
> 
>  I suggest to update JSEP section 5.1.2 to match the rest of the documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP candidate.

I don’t see any real befits to implementations to this change and I don’t think the rtcweb consensus was around the currently solution. Do you see some advantage to implementations to this?

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Nov 2018 11:57:13 -0500

On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <[email-masked]> wrote:

>  I suggest to update JSEP section 5.1.2 to match the rest of the
> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE
> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto
> MUST be used if default (only) candidate is a UDP candidate and
> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP
> candidate.
>
>
> I don’t see any real befits to implementations to this change and I don’t
> think the rtcweb consensus was around the currently solution. Do you see
> some advantage to implementations to this?
>

This is what every other document related to ICE, including JSEP section
5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB
need a really good reason why it needs to be different.

Also, if we are not going to do this, then every ICE implementation for
RTCWEB would be different from every other ICE implementation. For
instance, without this change, when ICE TCP candidate is selected, WebRTC
compliant implementation MUST use UDP/TLS/RTP/SAVPF in subsequent
offer/answer exchanges, but it MUST use TCP/TLS/RTP/SAVPF in the same case
when communicating with VoIP phone. It would be very hard to change this
behavior in ice-sip-sdp, since it will make it incompatible with RFC5245m
so this difference is likely to be permanent.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Wed, 28 Nov 2018 12:22:45 -0600

On 11/28/18 10:57 AM, Roman Shpount wrote:
> On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <[email-masked] 
>>     On Nov 27, 2018, at 4:46 PM, Roman Shpount <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used
>>     during ICE restart. When ICE restart is not in progress,
>>     "UDP/TLS/RTP/SAVPF"proto MUST be used if default (only) candidate
>>     is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto MUST be used if
>>     default (only) candidate is TCP candidate.
>
>     I don’t see any real befits to implementations to this change and
>     I don’t think the rtcweb consensus was around the currently
>     solution. Do you see some advantage to implementations to this?
>
>
> This is what every other document related to ICE, including JSEP 
> section 5.2.2 currently specifies. It was also consensus in MMUSIC. I 
> think RTCWEB need a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the 
document that you think are in conflict. I can't find any explicit 
<proto> field handling in 5.2.2.

In terms of changing technical aspects of JSEP: the only reason the 
document is out of the RFC Editor's queue right now is to address issues 
arising from rationalizing the reference to RFC 8445 within Cluster 238. 
This is not an opportunity to re-litigate previously settled consensus 
decisions. Technical issues such as the one at hand should have been 
raised during WG development, WG last call, or -- in extremis, since 
you're a regular RTCWEB participant -- during IETF last call. It's up to 
the chairs what to allow, but I wouldn't expect anything other than 
catastrophic flaws to be open for change at this time.

/a

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Nov 2018 13:41:33 -0500

Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <[email-masked]> wrote:

>> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is
>> TCP candidate.
>>
>>
> document that you think are in conflict. I can't find any explicit <proto>
> field handling in 5.2.2.
>
 I have mentioned this already in the previous message, but I guess this
got lost in the traffic.

JSEP-25 in section 5.2.2 says (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2):

Each "m=" and c=" line MUST be filled in with the port, *protocol*, and
address of the default candidate for the m= section, as described in
[I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.

At the same time section 5.1.2 says (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2):

For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate this
profile for each media m= line they produce in an offer. For data m=
sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST
indicate this profile for each data m= line they produce in an offer.

So, section 5.2.2 says m= line should be filled with currently used
protocol, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default
candidate is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVPF"
or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought that
section 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed
only applies to ICE restart. Authors disagree and want to update the
document.

> decisions. Technical issues such as the one at hand should have been raised
> during WG development, WG last call, or -- in extremis, since you're a
> regular RTCWEB participant -- during IETF last call. It's up to the chairs
> what to allow, but I wouldn't expect anything other than catastrophic flaws
> to be open for change at this time.
>
I am not the one who opened this can of worms. I am fine if the current
draft version is not changed. This is why I did not comment during the WG
last call. Draft authors are introducing the new change in
https://github.com/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible
with ice-sip-sdp. I oppose this change. If the group considers that a
change to clarify things is necessary, I would suggest that section 5.1.2
should be changed instead to that it only applies during ICE restart, so
that JSEP is compatible with ice-sip-sdp.

Regards,
______________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 28 Nov 2018 10:58:55 -0800

Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed
in https://github.com/rtcweb-wg/jsep/issues/854, and the editor team
concluded that 5.2.2 should be brought in line with 5.1.2 by removing the
need to match the protocol field. I think this change is important to make
to avoid future confusion.

This conclusion was a result of reviewing the prior discussion in
https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM,
where this topic was previously litigated. That email thread concluded with
the message in
https://mailarchive.ietf.org/arch/msg/mmusic/p6AFDGqbNm57P6s1cN2ZOUUDj2U,
where Roman seemed to be in agreement with the proposal.

On Wed, Nov 28, 2018 at 10:41 AM Roman Shpount <[email-masked]> wrote:

>>> I don’t see any real befits to implementations to this change and I
>>> don’t think the rtcweb consensus was around the currently solution. Do you
>>> see some advantage to implementations to this?
>>>
>>
> 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>):
>
> or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought
> that section 5.2.2, since it is more specific, overwrites 5.1.2, which I
> assumed only applies to ICE restart. Authors disagree and want to update
> the document.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 28 Nov 2018 11:00:34 -0800

Hi Roman,

The current pull request resolves the 5.1.2 vs. 5.2.2 ambiguity in line
with the discussion here:

https://github.com/rtcweb-wg/jsep/issues/394

and then here:

https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM

I understand from your comments on
https://github.com/rtcweb-wg/jsep/issues/854 that you disagreed with that
being the final consensus, and it has since been discussed on the list as
Justin suggested in that issue.

At the moment I continue to see only you objecting to the combination of
the current pull and an update to ice-sip-sdp.   Since ice-sip-sdp is in
MMUSIC, not RTCWEB, it's not up to the RTCWEB chairs to call the final
consensus here, but I believe my previous statement on the preference for
RTCWEB remains true.

regards,

Ted

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Nov 2018 14:50:09 -0500

> where Roman seemed to be in agreement with the proposal.

The discussion you are referring to was about the initial ICE offer/answer
exchange. I agree that during offer/answer exchange which initiate ICE
restart, only UDP based protocols should be used in the m= line. For me,
this is what section 5.1.2 describes. When ice-sip-sdp and related
documents (sctp-sdp and fc4583bis) were written, this logic was slightly
"fine tuned" for offer/answer exchanges which do not initiate ICE restart.
For these exchanges, it was decided to use the protocol of the only ICE
candidate pair present. This was important for backwards compatibility with
RFC 5245, especially when signaling agent monitors values in c= and m=
lines and actually cares about the address and protocol used there.  This
is what JSEP section 5.2.2 is describing and what you want to change. I
agree this is not extremely important for JSEP use cases, but unlikely to
change in ice-sip-sdp, since it is important there. Because of this, we are
going to end up with two specifications, and ICE implementations, which are
slightly different for no reason. As an implementer, this is an extra
"flag" I need to set when instantiating my ICE library.

Second part of the problem for me are the values of address and port in the
c= and m= line when no candidates in session description match the protocol
in the m= line. I do not think it was discussed anywhere except during
trickle ICE, where it was specified to set c= to IN IP4 0.0.0.0 and m= line
port to 9 when no candidates are present. If this can be extended to the
case when ICE candidates are present but do not match the proto in the m=
line, I would be happy since this will prevent ICE mismatch with
ice-sip-sdp compliant implementations. If you do not want to update JSEP to
do this, it can be added in ice-sip-sdp. Just please do not put something
in JSEP which will force it to update c= and m= line with address and port
of mismatching candidate.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Nov 2018 14:54:35 -0500

Hi Ted,

> consensus here, but I believe my previous statement on the preference for
I think at this point it is up to the chairs to decide. Just please keep in
mind that updating ice-sip-sdp and sctp-sdp to be inline with what JSEP is
proposing would be difficult since this will cause backward
compatibility issues with RFC 5245 outside of RTCWEB.

Also, proposed change raises a new issue, which is what values should be
set in c= and m= lines when protocol in m= line does not match the default
candidate.

Regards,
_____________
Roman Shpount