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

Roman Shpount <roman@telurix.com> Tue, 10 January 2017 20:35 UTC

Return-Path: <roman@telurix.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 A3A7B12954F for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 12:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 ndkA_KMwwnFJ for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 12:35:15 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E197A1294B8 for <mmusic@ietf.org>; Tue, 10 Jan 2017 12:35:14 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id x49so110901069qtc.2 for <mmusic@ietf.org>; Tue, 10 Jan 2017 12:35:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hp4zqVqxIHGig+cDYqOF6/nI4NyENmxGYIc1gVZSguk=; b=sLG/Y3c/OsDbfVv9ut+ZrqDsrNECNjH1SZgvOB3zN2ELmpSvAjgr8B4Gq1LY0gZdbk s6lBfZIC05vHHTAs9upTPhOKo/BwpYqkTeynJPXameshRYrPJURv+6pQFUsg/ZXbbrtD Y1i7Hmx8zjWhXmhx+G3F1akKwx+u3H1kADq1Eil49dMdx1rt899bZOJHiFiwykDYRSn/ PERtWZTC/jyIW51wSm/oXrppLOZIWxc6MzqdNnv6S5z6caTiYcDovo0D9bT5nMMCiFuc kRqsvK9ZuH/Nq0nLNN/RPFkLgo1rhHDWvrbxLXIWSUmYE2gB1DBJBnbw9xdes/0sSkAQ 2otw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hp4zqVqxIHGig+cDYqOF6/nI4NyENmxGYIc1gVZSguk=; b=TpEQ9DwWzwl8sffyNjDk7Qi59i4iV3g4i0sGLbLQoKS8diOhy9+FZdaRkmTM0Ows/J 1APWpN57vQao742uRc4AUTw4vUewfXUGsHRvlJBuXysOVRaWUVBx3/xox2JGazexhLlM XCiczb6eNpc1kKOBH7fKgU9SD4C0FAtsSrYfmcHoTEykREecPeW2FPA8DQVRogf5rX7d Zn1Q78DYluCRhuUXiG4jnybGdT7rq3krLJ6JUCkxjFK9vzgQ309mFE9NhFQ37iPaDGbc E6tk/tAe8fpdymV73gfCtv3XK4ZzyB9GZ+UHq3MwLcM2eCP8h3t1BuNr/KGKmohy9NyR mCqg==
X-Gm-Message-State: AIkVDXKXDadwuPJltwVPuwsAvUdq3GrTRbHPlwWsaVKEc2bhIL/NY4X3H8YzrFf/GXPprw==
X-Received: by 10.200.51.26 with SMTP id t26mr5158320qta.106.1484080513802; Tue, 10 Jan 2017 12:35:13 -0800 (PST)
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com. [209.85.220.181]) by smtp.gmail.com with ESMTPSA id j9sm2296845qtc.23.2017.01.10.12.35.13 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 12:35:13 -0800 (PST)
Received: by mail-qk0-f181.google.com with SMTP id 11so88971779qkl.3 for <mmusic@ietf.org>; Tue, 10 Jan 2017 12:35:13 -0800 (PST)
X-Received: by 10.55.161.212 with SMTP id k203mr5315286qke.234.1484080512974; Tue, 10 Jan 2017 12:35:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.79 with HTTP; Tue, 10 Jan 2017 12:35:12 -0800 (PST)
In-Reply-To: <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net>
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>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 10 Jan 2017 15:35:12 -0500
X-Gmail-Original-Message-ID: <CAD5OKxs5NK8cshdeJRrPD2fj30AwBwLeNpqE_EAPaAZ-rzv6iw@mail.gmail.com>
Message-ID: <CAD5OKxs5NK8cshdeJRrPD2fj30AwBwLeNpqE_EAPaAZ-rzv6iw@mail.gmail.com>
To: Paul Kyzivat <paul.kyzivat@comcast.net>
Content-Type: multipart/alternative; boundary="94eb2c06e794cb4a530545c36bee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/He-LXdAFcUgcyg02WwYjU7jokJ0>
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 20:35:16 -0000

On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <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.

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.

Regards,
_____________
Roman Shpount