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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Dec 2016 15:15:53 +0000

Hi,

See inline.

Den 2016-12-16 kl. 18:05, skrev Eric Rescorla:
> https://github.com/rtcweb-wg/jsep/issues/394
>
> Magnus writes:
>
>     >    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.
>
>
>
>     Do I understand this correct, we are requiring support for the
>     "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the
>     optional to support ICE TCP, they can indicate it, and any WebRTC
>     endpoint will accept it, even if that is just one option? I do know
>     that different profiles are a negotiation issue. But, wouldn't it be
>     more reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases
>     where one offer any candidates that also use UDP? And only use
>     TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus
>     not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it?"
>
>
> We could certainly do this, but it seems to perpetuate the idea that the
> TCP/UDP distinction is
>
> meaningful here, which seems like the opposite direction from the one we
> are going in (see
>
> the mmusic minutes around the topic Non-Supported Transport in m- line).
> See also the note below in this paragraph about either profile being
> consistent with either transport.
>
>
> I think it would be fine to relax the requirement that implementations
> *support* both UDP and TCP, but requiring them to conditionally use one
> or the other depending on whether they have UDP candidates seems like
> it's really going to impose a lot of pain on implementors for no good
> reason, in part because you don't necessarily know at the time of offer
> generation what you will have. Consider the case where you are only
> offering relayed and srflx candidates. At the time of generation, you
> don't know if you will be able to get a UDP candidate, because you might
> be behind a firewall that blocks UDP and your TURN server might be down.
>

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/..., If you have no implementation for TCP candidates then you clearly offers UDP/.... If the implementations intention is to offer both if they are determined, then one has a choice. In the context of WebRTC to WebRTC this does would not matter, as long as the counter part has the rule to accept either. However if you support both, if one you uses UDP, then it also doesn't matter for implementations supporting only UDP, they will accept it. If the incoming offer is TCP/... then with the clarifications you propose below a non TCP candidate supporting implementations answering can't fail immediately. It will have to wait to see if there if there ever shows up any UDP candidates.

Gateways to legacy devices will independently have issues, as what they need to use will depend on the far sides capabilities and the actual set of candidates.

>
> If we make any change, I think it should just be to relax the
> requirement to support TCP and then tell people to ignore the first
> field here in favor of the candidate lines.
>

So, if I interpret the above, I would say: Set the PROTO to UDP/... and on reception ignore the TCP/UDP part of the PROTO string, only looking at candidates. That is very close to my amended suggestion. The only addition I have, is that if an implementation will not include any UDP candidates, only TCP one, then it shall use TCP.

We should have defined ICE/DTLS/RTP/SAVPF to avoid this issue.

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: Eric Rescorla <[email-masked]>
Date: Thu, 22 Dec 2016 09:30:48 -0800

On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund <
[email-masked]> wrote:

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

-Ekr

If you have no implementation for TCP candidates then you clearly offers
> UDP/…. If the implementations intention is to offer both if they are
> determined, then one has a choice. In the context of WebRTC to WebRTC this
> does would not matter, as long as the counter part has the rule to accept
> either. However if you support both, if one you uses UDP, then it also
> doesn’t matter for implementations supporting only UDP, they will accept
> it. If the incoming offer is TCP/… then with the clarifications you propose
> below a non TCP candidate supporting implementations answering can’t fail
> immediately. It will have to wait to see if there if there ever shows up
> any UDP candidates.
>
>
>
> Gateways to legacy devices will independently have issues, as what they
> need to use will depend on the far sides capabilities and the actual set of
> candidates.
>
>
>
> >
>
> So, if I interpret the above, I would say: Set the PROTO to UDP/… and on
> reception ignore the TCP/UDP part of the PROTO string, only looking at
> candidates. That is very close to my amended suggestion. The only addition
> I have, is that if an implementation will not include any UDP candidates,
> only TCP one, then it shall use TCP.
>
>
>
>
>
> <+46%2010%20714%2082%2087>
>
> <+46%2073%20094%2090%2079>
>