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

Paul Kyzivat <paul.kyzivat@comcast.net> Tue, 10 January 2017 19:27 UTC

Return-Path: <paul.kyzivat@comcast.net>
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 0CF661297E8 for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 11:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 8h4D0PvUzyv3 for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 11:27:57 -0800 (PST)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 52F7C1297ED for <mmusic@ietf.org>; Tue, 10 Jan 2017 11:27:57 -0800 (PST)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-02v.sys.comcast.net with SMTP id R25Mcg6yg9XRkR25McyEmO; Tue, 10 Jan 2017 19:27:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484076476; bh=Fs7luZtmLSrv3qKK9nWCUwYWSFl2kErDvG9pVjCD79c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=a8dI8LVTFHHmWTnNLNbUq/wwMcGJyF/DyfpAjvyZganjHcQjEP4t9F6J8lX6MZM1G b9XPZlhHLGHaiBdjGwZzhjAPbT+U+tcqvuThd8UsrQZFTIrdNtra1nbpzsjNnHUpqz QOZd4+7bI01/D4/Zk10aFfuDk9GJuI+D7AK0pSkd46hyP+lXN/yT8mG58sqYlUq0Ax NSQqJC777kxYWvTxltktEp5wGnlOYw9TC7lU/nYgK/Mkyzgl9BfaXe1TQ5mejhDjNq 8I86V1EKl8c0RsjGrGD+64fgnz3ekfQsGsSxVRaLQO4PHASwIcodiKa6lHxmlnFc1T AEFE98qtEXHxQ==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-03v.sys.comcast.net with SMTP id R25LcKCf2OblgR25MchlyT; Tue, 10 Jan 2017 19:27:56 +0000
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>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net>
Date: Tue, 10 Jan 2017 14:27:55 -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: <CAD5OKxvtRxajLddLQjTMMiLYqE6-Z=msX29NM2O532ydmZbSAQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfELgr0ClBTk45LmbVIefwtVGI8gEFLEZG0UkoiytEhDdCG1bv/APYa1PPhks+8t/fXDgHF9q6hvyEM4ygxYJF9WP6T72u1WLslTYwAk28pT2EJW+DGs8 oyOyOD2Xm1nVleKH+c1WISnp5KOKM6pM5cQAg0MqTs+uYhNnHNTcoYiDmfSvYSIXfClLsTsagtWCRIpHwsnjuxMNJ/GrtM4E5Us=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/LXgKG9wMic6huqJy4RaQ7JwTuhE>
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 19:27:59 -0000

On 1/10/17 1:08 PM, Roman Shpount wrote:
> 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

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 -

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

	Thanks,
	Paul