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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 22 December 2016 15:16 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511FC12955B; Thu, 22 Dec 2016 07:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb7QmGQD7QkT; Thu, 22 Dec 2016 07:16:33 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CA512943B; Thu, 22 Dec 2016 07:16:32 -0800 (PST)
X-AuditID: c1b4fb3a-45bff70000005d1c-c8-585bee4dd501
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id FF.A8.23836.D4EEB585; Thu, 22 Dec 2016 16:16:30 +0100 (CET)
Received: from ESESSMB309.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Thu, 22 Dec 2016 16:15:28 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic WG" <mmusic@ietf.org>
Thread-Topic: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
Thread-Index: AdJcYFcrE3U1P1RsTNSE+iTBQB43vA==
Date: Thu, 22 Dec 2016 15:15:53 +0000
Message-ID: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_52E4A8FC978E0241AE652516E24CAF001E483F95ESESSMB309erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7tK7fu+gIg+5eXYsVr8+xW0xd/pjF Yu2/dnYHZo8lS34yeUx+3MYcwBTFZZOSmpNZllqkb5fAlfFt/U+mglstjBX3u46yNDA+Kupi 5OSQEDCR+Ns+kRXEFhJYxyjxZwE3hL2EUWLOCj4Qm03AQuLmj0a2LkYODhGBNInrE21BwsIC DhLHdq5lgQi7SjyYwgkSFhHQk1h4+DgjiM0ioCrxaelJNhCbV8BX4vL5JUwgNqOArMT97/dY QGxmAXGJW0/mM0FcIyCxZM95ZghbVOLl43+sELaiRPvTBkaI+nyJpi29UDMFJU7OfMIygVFw FpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIERsXBLb+tdjAefO54iFGAg1GJh/fDjKgIIdbEsuLK3EOMEhzMSiK8L19F RwjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAWDp9Ae// NquCeb9lOLzm/glc+HYRw61WRY7ct8diejsdjvJv3qPsHBNbbekrO5s9lkHtW3GPUxuXcrez Rcb8jWFph13ZS87PDy9QO3POOa1QeemEPUfFb03i/Lzw6alThQxF/80/TnFmrbflrJmzbIZI SNG+59w/PGa+36J44sG3AuU62egaJZbijERDLeai4kQAaWbkWIYCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/g7GEbL-xW8WNG_bRovI7JzRFdJI>
Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 15:16:35 -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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------