Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

From: Harald Alvestrand <[email-masked]>
Date: Mon, 2 Jan 2017 14:42:27 +0100

Den 22. des. 2016 18:30, skrev Eric Rescorla:
>      __
> 
>     Okay, I agree that having any rules for what you should offer here
>     based on what the actual outcome is not the best idea here. I think
>     the rules should be based on capability and intent. So if you only
>     are going offer TCP candidates, then you clearly should use TCP/…,
> 
> 
> I'm going to push on this. If we've already agreed that mismatches are
> normal, why should we do that? Wouldn't it be better to just effectively
> deprecate this field?
> 

Concur with EKR.

This field (the TCP/UDP part of the protocol field) was defined in a way
that makes its original purpose (to negotiate profiles) not only
impossible while using ICE, but actively harmful, because you end up
telling lies in very many cases, so people will have to accept things
that don't match reality.

Make the world as simple for implementors as possible: Send a fixed
string, and accept all strings.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jan 2017 16:13:23 +0100

Den 2016-12-22 kl. 18:30, skrev Eric Rescorla:
>
>
> On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund
>

So, my main argument for including any rules for how to set it, would be 
that the this part of the PROTO field still has meaning outside of 
WebRTC context. There one may actually have it to match what is goind to 
be used. Thus, it can provide some guidance to gateways on what to 
expect. It might be that we should actually set it to UDP for those not 
supporting ICE/TCP, and to TCP for the ones that supports both UDP and 
TCP. That would still provide information to the gateway.

I think simple rules based on implementation capabilities for how to set 
it are better than no rules. Especially as it would carry some 
information, not zero, which is the result of no rules.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jan 2017 16:44:22 +0100

> string, and accept all strings.

Okay, can we please be precise with what is suggested here. Because what 
you write above, and what EKR proposed is not really the same thing. The 
issue proposed that it was fine to set either of the strings. You saying 
a fixed string. I want to ask you which UDP/... or TCP/..., or even 
ICE/DTLS/RTP/SAVPF?

 From a strict clarity issue using ICE/... would be my preferred. But, 
that is probably going to throw some implementations, especially 
gateways. It will also require us to actually go write the registration 
to explain what it is.

Using UDP is likely the most compatible and will only fail in gateway 
cases where there are no UDP candidates and the gateway fail to pick 
that up.

Using TCP when there are no TCP candidates are equally misleading to 
gateway cases.

The above is why I proposed that implementation capabilities and any 
configuration to limit what functions being used would be an appropriate 
choice.

I hope at least we can agree that an JSEP Answer MUST use the PROTO 
string of the OFFER?

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2017 17:12:30 +0100

> a fixed string. I want to ask you which UDP/... or TCP/..., or even

The current JSEP language is:

5.1.3.  Profile Names and Interoperability

   For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
   RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of
   these two profiles for each media m= line they produce in an offer.
   For data m= sections, JSEP endpoints must support both the "UDP/DTLS/
   SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

The current proposal (as I interpret EKR) is to replace

        ....and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

with

            ....and MUST indicate UDP/TLS/RTP/SAVPF for each data m= line
   they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, this consistent with ICE eventually
   selecting either either UDP or TCP.

> gateways. It will also require us to actually go write the registration

We lost clarity when ICE was introduced without redesigning the
"protocol" field. Trying to get it back is not helping anyone.

> I hope at least we can agree that an JSEP Answer MUST use the PROTO

We agreed on that long ago.

Section 5.3.1 of JSEP:

   o  The <proto> field MUST be set to exactly match the <proto> field
      for the corresponding m= line in the offer.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jan 2017 12:40:32 -0500

> From a strict clarity issue using ICE/... would be my preferred. But,

+1

> gateways. It will also require us to actually go write the registration

Having to write a registration to explain what it is would be a good thing!

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 10 Jan 2017 17:49:06 +0000

> On Jan 10, 2017, at 10:13 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> So, my main argument for including any rules for how to set it, would be that the this part of the PROTO field still has meaning outside of WebRTC context. There one may actually have it to match what is goind to be used. Thus, it can provide some guidance to gateways on what to expect. It might be that we should actually set it to UDP for those not supporting ICE/TCP, and to TCP for the ones that supports both UDP and TCP. That would still provide information to the gateway.

If you’re using ICE, as far as I can tell there are only two cases where the transport parts of the PROTO field (and the m/c transport values) are still relevant:

1. If you’re talking to an endpoint that doesn’t do ICE, it tells the peer what the fallback protocol should be.  This isn’t relevant for WebRTC, but still is for general MMUSIC cases.

2. If you have an SDP-inspecting middlebox, it tells it what media protocol to look for (for latching and the like).  This mostly isn’t meaningful before ICE has concluded, but it is afterward.

My suggestion would be that the PROTO MUST match the active candidate, if you have one; otherwise, it MUST match the (for WebRTC, generally arbitrarily-chosen) default candidate, if you have one; otherwise (the initial state of trickle) it MUST match one of the protocols of the candidates you’re expecting to gather (ideally, the one that you’ll choose as the default).

This basically matches the rules for m/c transport values already in JSEP, I believe.

Now, the tricky thing is of course whether this works for answers — whether the PROTO for the answer has to match the offer.  A problem occurs when the answerer isn’t expecting to gather any candidates that use the protocol used by the offerer’s default candidate.

My suggestion would be that the rules I’ve specified apply anyway, and that the answer PROTO doesn’t have to match the offer PROTO.  This will only confuse any inspecting middleboxes until the next offer/answer exchange occurs.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 10 Jan 2017 13:08:07 -0500

We can do the registration for ICE transport tag in ICE-SIP-SDP. ICE tag
will indicate that ICE is required for this offer/answer exchange to
succeed. When ICE transport tag is used, c= and m= SDP line would carry no
address information and will contain "c=IN IP4 0.0.0.0" and port 9 in the
m= line. Also, if ICE/ transport tag is used, we should remove the
requirement for a re-INVITE after ICE nomination process is complete, since
it serves no purpose when no address is specified in c= and m= lines.

If we are not going to define ICE/ transport, then I propose the following:

1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to port 9, so
that these lines carry no valid address information as it is specified in
JSEP, protocol should be UDP/DTLS/SAVPF for RTP or UDP/DTLS/SCTP for data

2. When c= line and m= line carry valid address information, protocol
should match the candidate specified in c= and m= lines.

3. In cases when c= line and m= line carry valid address information, when
initial offer and answer are generated, they must include UDP candidates
and UDP candidates must be used as defaults. Once ICE nomination process is
complete, only the active candidate pair MUST be included in SDP, and the
transport for the active pair must be used.

I am not sure about the proper procedure for c= and m= lines during the ICE
nomination process, since active candidate can change during the
offer/answer exchange which can cause protocol line mismatch. One option is
to continue re-sending the initial offer and answer.

P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it be
"UDP/DTLS/RTP/SAVPF"?

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jan 2017 14:27:55 -0500

On 1/10/17 1:08 PM, Roman Shpount wrote:
> succeed. When ICE transport tag is used, c= and m= SDP line would carry
> no address information and will contain "c=IN IP4 0.0.0.0" and port 9 in
> the m= line. Also, if ICE/ transport tag is used, we should remove the
> requirement for a re-INVITE after ICE nomination process is complete,
> since it serves no purpose when no address is specified in c= and m= lines.
>
> 1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to port 9,
> so that these lines carry no valid address information as it is
> specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP
> or UDP/DTLS/SCTP for data

To do this cleanly, IMO there should be no singling out of IP4. The fact 
is that in this case the c= line is not needed. (And this isn't the only 
case where it isn't. It also isn't needed for MSRP and for websockets - 
things that use URLs in attributes instead of c=.) So perhaps we should 
revise 4566bis to make c= optional for m= lines where it isn't needed. 
Or define a new addrtype for use in c= (e.g. simply "IP" or "IP4/6") and 
define a placeholder address value for this case. For example:

   c=IN IP -

> 3. In cases when c= line and m= line carry valid address
> information, when initial offer and answer are generated, they must
> include UDP candidates and UDP candidates must be used as defaults. Once
> ICE nomination process is complete, only the active candidate pair MUST
> be included in SDP, and the transport for the active pair must be used.

I think this could be handled by having different <proto> values:

ICE/DTLS      DTLS over either UDP or TCP
ICE/UDP/DTLS  DTLS over only UDP
ICE/TCP/DTLS  DTLS over only TCP

ICE/DTLS/RTP/SAVPF      Like above, but for RTP/SAVPF
ICE/UDP/DTLS/RTP/SAVPF  "
ICE/TCP/DTLS/RTP/SAVPF  "

So this allows restricting the type of candidates that are allowed, or 
not. And it avoids "lying" about the type that is to be used.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 10 Jan 2017 15:35:12 -0500

On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <[email-masked]>
wrote:

> revise 4566bis to make c= optional for m= lines where it isn't needed. Or
> define a new addrtype for use in c= (e.g. simply "IP" or "IP4/6") and

It is cleaner, but this needs to be defined somewhere. Current JSEP uses
"IN IP4 0.0.0.0" and port 9.

> not. And it avoids "lying" about the type that is to be used.

We can define it this way, but I am not sure defining anything beyond
ICE/DTLS/RTP/SAVPF and ICE/DTLS/SCTP is actually needed. Once we specify
that ICE is used, actual candidates can be examined to see which candidate
types are supported.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jan 2017 17:17:58 -0500

On 1/10/17 3:35 PM, Roman Shpount wrote:
> On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     To do this cleanly, IMO there should be no singling out of IP4. The
>     fact is that in this case the c= line is not needed. (And this isn't
>     the only case where it isn't. It also isn't needed for MSRP and for
>     websockets - things that use URLs in attributes instead of c=.) So
>     perhaps we should revise 4566bis to make c= optional for m= lines
>     where it isn't needed. Or define a new addrtype for use in c= (e.g.
>     simply "IP" or "IP4/6") and define a placeholder address value for
>     this case. For example:
>
>       c=IN IP -
>
>

4566bis is still in progress, so it could be done there.

>     So this allows restricting the type of candidates that are allowed,
>     or not. And it avoids "lying" about the type that is to be used.
>
>
> that ICE is used, actual candidates can be examined to see which
> candidate types are supported.

Perhaps choice of UDP/TCP/both can be left to the candidates. I guess if 
one side wants to restrict to one or the other it can offer only 
candidates of the type it wants.

	Thanks.
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Jan 2017 09:30:33 +0100

Den 2017-01-10 kl. 19:08, skrev Roman Shpount:

> P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it
> be "UDP/DTLS/RTP/SAVPF"?

No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over 
UDP with RTP SAVPF profile. See	[RFC5764]. The "UDP/DTLS/RTP/SAVPF" is 
not registered.

So the alternatives for the dependency of default candidate protocol 
type in your proposal would be:

UDP: "UDP/TLS/RTP/SAVPF"
TCP: "TCP/DTLS/RTP/SAVPF"

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 05:17:52 -0800

On Tue, Jan 10, 2017 at 7:44 AM, Magnus Westerlund <
[email-masked]> wrote:

> issue proposed that it was fine to set either of the strings. You saying a
> fixed string. I want to ask you which UDP/... or TCP/..., or even
> ICE/DTLS/RTP/SAVPF?
>
> From a strict clarity issue using ICE/... would be my preferred. But, that
> is probably going to throw some implementations, especially gateways. It
> will also require us to actually go write the registration to explain what
> it is.
>
> cases where there are no UDP candidates and the gateway fail to pick that
> up.
>
> I hope at least we can agree that an JSEP Answer MUST use the PROTO string
> of the OFFER?

Yes. I think implementations should offer UDP/ (ICE/ will cause problems)
and in the answer echo the offer.

-Ekr

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2017 13:28:39 +0000

Hi,

…

>>I hope at least we can agree that an JSEP Answer MUST use the PROTO string of the OFFER?
>
>Yes. I think implementations should offer UDP/ (ICE/ will cause problems) and in the answer echo the offer.

This is related to the generic issue I raised in Seoul, and sent an e-mail about last week: is it ok to echo the transport in the m- line proto value of the answer even if the answerer doesn’t support the transport (alt #1)?

OR, should we mandate a transport that everyone must support, and mandate to use that transport as m- line proto value in offers and answers (alt #2)?

People in Seoul preferred alt #1, but I know that at least Roman prefers alt #2.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 05:45:07 -0800

On Mon, Jan 16, 2017 at 5:28 AM, Christer Holmberg <
[email-masked]> wrote:

> This is related to the generic issue I raised in Seoul, and sent an e-mail
> about last week: is it ok to echo the transport in the m- line proto value
> of the answer even if the answerer doesn’t support the transport (alt #1)?
>
> OR, should we mandate a transport that everyone must support, and mandate
> to use that transport as m- line proto value in offers and answers (alt #2)?
>

I continue to support #1. We should just stop trying to pretend that this
value has useful semantics.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Jan 2017 16:09:49 +0000

Hi,

…

>> This is related to the generic issue I raised in Seoul, and sent an e-mail about last week: is it ok to echo 
>> the transport in the m- line proto value of the answer even if the answerer doesn’t support the transport (alt #1)?
>>
> I continue to support #1. We should just stop trying to pretend that this value has useful semantics.

As #1 was also the outcome of Seoul, I think we should move ahead with it. Chairs?

Note that #1 does not prevent individual protocols from defining MTI transports, default m- line proto values etc,  but it would not be a general requirement to do so.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Jan 2017 18:37:54 -0500

For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and
UDP/DTLS/SCTP in both the offer and the answer?

Is there a use case to offer only tcp candidates in offer or answer?

Regards,
_____________
Roman Shpount

On Mon, Jan 16, 2017 at 11:09 AM, Christer Holmberg <
[email-masked]> wrote:

> >>>Yes. I think implementations should offer UDP/ (ICE/ will cause
> problems) and in the answer echo the offer.
> >>
> >> the transport in the m- line proto value of the answer even if the
> answerer doesn’t support the transport (alt #1)?
> >>
> >> OR, should we mandate a transport that everyone must support, and
> mandate to use that transport as m- line proto value in offers and answers
> (alt #2)?
> >>
> Note that #1 does not prevent individual protocols from defining MTI
> transports, default m- line proto values etc,  but it would not be a
> general requirement to do so.
>
> Regards,
>
> Christer
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 15:59:18 -0800

> UDP/DTLS/SCTP in both the offer and the answer?
As an answerer, you may get TCP/<blah> from non-JSEP endpoints and the
consensus was that echoing them was better

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Jan 2017 19:11:23 -0500

> consensus was that echoing them was better
Is there a reason why this would ever happen? You use ICE TCP to go through
UDP firewalls when communicating with a server on a public IP. Why would
you ever do only tcp candidates in offer or answer? This is inefficient and
will work worse then offering both udp and tcp candidates. I am all for
options, but they should have some reason for existence. I see no reason
why TCP/anything would ever be used for JSEP offer/answer, unless ICE is
complete and tcp candidate pair is selected.

BTW, we made UDP required protocol for default candidates for
UDP/DTLS/SCTP. I see no reason not to do the same thing for
UDP/TLS/RTP/SAVPF at least in JSEP. It will only make things interop with
non JSEP endpoints better.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 16:20:53 -0800

On Mon, Jan 16, 2017 at 4:11 PM, Roman Shpount <[email-masked]> wrote:

> Is there a reason why this would ever happen?
>

It's permitted behavior.

> You use ICE TCP to go through UDP firewalls when communicating with a
> server on a public IP. Why would you ever do only tcp candidates in offer
> or answer? This is inefficient and will work worse then offering both udp
> and tcp candidates. I am all for options, but they should have some reason
> for existence. I see no reason why TCP/anything would ever be used for JSEP
> offer/answer, unless ICE is complete and tcp candidate pair is selected.
>

Well, as I stated above, this isn't about what JSEP endpoints offer but
what they answer
when other endpoints send TCP/<blah>, however foolish you might think it is.

> non JSEP endpoints better.

What's the evidence that answering TCP/TLS/RTP/SAVP with UDP/TLS/RTP/SAVPF
will improve interop?

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Jan 2017 19:53:22 -0500

For clarity, this is what I would suggest for JSEP:

JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.

If JSEP end point receives an offer with UDP/DTLS/SCTP or
UDP/TLS/RTP/SAVPF, it MUST respond with the same proto and MUST include udp
candidates (and use udp as a default candidate if JSEP endpoint is
providing default candidates).

If JSEP end point receives an offer with TCP/DTLS/SCTP or
TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto and MUST include
tcp candidates (and use tcp as a default candidate if JSEP endpoint is
providing default candidates).

If non JSEP end point responds with a protocol that does not match the
offer, this is considered an error regardless of the ICE candidate supplied
in the answer.

So, what I want is for JSEP not to generate offers with TCP/blah and not to
generate answers were protocol does not match the protocol in the offer, or
does not match ICE candidates provided. I think this will improve interop
and can be satisfied by all existing implementations.

Generic requirements for ICE outside of JSEP can be more complex since we
need to explain what will happen when end point receives an offer with
TCP/blah but does not support TCP candidates. Also, outside of JSEP, things
like ICE mismatch come into play. This, of cause, can be discussed and
decided elsewhere, not in JSEP.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 17:15:06 -0800

> JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.

Yes.

> UDP/TLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.

> and MUST include udp candidates (and use udp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree with this. It should offer whatever candidates it wants
and/or are determined by policy. For example, if the implementation is set
to relay-only, it will be restricted to whatever the TURN relay will do.

> TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.

> and MUST include tcp candidates (and use tcp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree for the reasons above.

> So, what I want is for JSEP not to generate offers with TCP/blah and not
> to generate answers were protocol does not match the protocol in the offer,
>

Yes.

> or does not match ICE candidates provided. I think this will improve
> interop and can be satisfied by all existing implementations.
>

I don't think trying to match the candidates to the proto line is useful,
especially when you are doing trickle ICE.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 Jan 2017 20:35:43 -0500

After considering your arguments regarding trickle ICE argument I agree
with you.

To summarize, I can live with the following:

1. JSEP end point MUST send an offer with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF
2. If JSEP end point receives the offer, it MUST response with the same
transport even if no ice candidate matching this protocol are present in
the answer
3. If non JSEP end point responds with a protocol that does not match the
offer, this is considered an error regardless of the ICE candidate supplied
in the answer.

I do agree to this only within the limit of JSEP. Outside of JSEP it needs
to be discussed in more detail, since things like ICE mismatch will need to
be considered.

Regards,
_____________
Roman Shpount