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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 10 January 2017 22:18 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 1BBE412A05E for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 14:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.4
X-Spam-Level:
X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 DMYeYsBAUlhK for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 14:18:01 -0800 (PST)
Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A212A05A for <mmusic@ietf.org>; Tue, 10 Jan 2017 14:18:01 -0800 (PST)
X-AuditID: 1207440d-97fff70000000a35-f3-58755d97c442
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 54.81.02613.79D55785; Tue, 10 Jan 2017 17:18:00 -0500 (EST)
Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0AMHwwm020566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 17:17:59 -0500
To: Roman Shpount <roman@telurix.com>
References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> <CAD5OKxvtRxajLddLQjTMMiLYqE6-Z=msX29NM2O532ydmZbSAQ@mail.gmail.com> <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net> <CAD5OKxs5NK8cshdeJRrPD2fj30AwBwLeNpqE_EAPaAZ-rzv6iw@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <01f63c15-f006-3b3e-59e1-d9bc2c568b43@alum.mit.edu>
Date: Tue, 10 Jan 2017 17:17:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxs5NK8cshdeJRrPD2fj30AwBwLeNpqE_EAPaAZ-rzv6iw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixO6iqDsjtjTC4NdXdoupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZay9NImx4IVoxcYVM9gaGB/xdzFyckgImEhc nLGQsYuRi0NI4DKjROfG2VDOdSaJjkf/WUCqhAUcJI7tXAtmiwioSvz9PpkJougns8TBtl9g CWYBdYmJc28wgdhsAloScw5BNPMK2EvcWriGDcRmAWpec2IbI4gtKpAm8eDkVkaIGkGJkzOf gNVzCgRKLFr8GWqmmcS8zQ+ZIWx5ie1v5zBPYOSfhaRlFpKyWUjKFjAyr2KUS8wpzdXNTczM KU5N1i1OTszLSy3SNdLLzSzRS00p3cQICUneHYz/18kcYhTgYFTi4X3woiRCiDWxrLgy9xCj JAeTkiivlW1phBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3gMRQDnelMTKqtSifJiUNAeLkjiv 2hJ1PyGB9MSS1OzU1ILUIpisDAeHkgRvbAxQo2BRanpqRVpmTglCmomDE2Q4D9DwoyA1vMUF ibnFmekQ+VOMuhy3ji95yiTEkpeflyolztsMUiQAUpRRmgc3B5ZKXjGKA70lzDsVpIoHmIbg Jr0CWsIEtCTSrhhkSUkiQkqqgdH/eoTapNQfpqcCFn3ZcfMRk4KYkqUG99Hj7jH/Hx+58PjA to0nOiZf0OWpUxcW1XV9/lJu9VP7v8oSspxXJE5v3XP32i3/lp3P3l+41s2y+JzSwejXKpcE 9N42ynfEByqffCf9ViByNvszrvIwRjefxsJ/LiUnHH7yOn2+HS175qfjhsx2xkYlluKMREMt 5qLiRACpItEmAAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/kVz9ZvbEsk9kXTKTWyK_tK3CH7A>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Tue, 10 Jan 2017 22:18:03 -0000

On 1/10/17 3:35 PM, Roman Shpount wrote:
> On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <paul.kyzivat@comcast.net
> <mailto:paul.kyzivat@comcast.net>> wrote:
>
>     On 1/10/17 1:08 PM, Roman Shpount wrote:
>
>         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 -
>
>
> It is cleaner, but this needs to be defined somewhere. Current JSEP uses
> "IN IP4 0.0.0.0" and port 9.

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

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

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