Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

Roman Shpount <roman@telurix.com> Fri, 17 February 2017 18:26 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 95D68129B10 for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 10:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] 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 PrIud2NamyIZ for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 10:26:50 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D5CD4129686 for <mmusic@ietf.org>; Fri, 17 Feb 2017 10:26:49 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id g67so24020416itb.1 for <mmusic@ietf.org>; Fri, 17 Feb 2017 10:26:49 -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=lxcT2mCIZOMj5QSi8bw5WtgrcHbasyZGchEZLbOv4j0=; b=MamI6m++tt/VEtNE+lTL+sVCS4RfNFzHcteZsu+Gld4Q4rt4T4YegHizrfQrIYG8uT /8GjIpSC8htb9APaqWnqXLm9wIa9ihyeoGCgUNnJtTGtWBjLEFHUUJrrHMS96Bvlv2B9 b8XehGPFDJaudTvIDu0maofghIz1TlmVKYc39OVlqMFNNvD4NkfcLFB9ruzB0il1K70G eoFqhv5ePUDfzBJ6MYM9KWqhHoFbBY996Zgvo167qWmw4HJJKCkEivgkijQ+IQWXVBDW jGrgCzwQUhXc/XHs8gCzhSHJx/YVgimPPh1UcbVKqiWxx8g81v+DRnt+8PhDuu6Lf2V2 uWcQ==
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=lxcT2mCIZOMj5QSi8bw5WtgrcHbasyZGchEZLbOv4j0=; b=hSAbgtaaqpLxt7oV0LXh5HrtZLBZ1nnpcQzGbrWtRJQdbyt0RNsw7SgtsLEUbLsDD7 H6Wlotd5QSOxvgZLctteuUzsdr2N3qGXVVntBcMR9vsONhcuBh/nwp357IJFP9sVQ5j1 23VX9vJWQaA8ha2eRKVSX/8IJ78ONw0c0atlgyv65oYjqa6T2TqF3qcmTZ4Oy5+WJeoE FBVFNZQpuNIxt2bJh8XPXyTt2Y08iJVked9BuxoY/tH6zOgk/3VWs2xxJqRV28+WJGq9 0hUD3bntwBBq6XZs90Ldfj/Wi4DsdL64kwG5gk90fHSYpDbAN0YxNKwt6EcK6DzEX4La 8s1A==
X-Gm-Message-State: AMke39kcPTzxfXDgm/bSnV9Haxe54w5BkTfXO5YSI1xYplJ1NOJ3C33db85T29Z+CE8cTw==
X-Received: by 10.107.57.198 with SMTP id g189mr3326477ioa.123.1487356009029; Fri, 17 Feb 2017 10:26:49 -0800 (PST)
Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id j4sm875573ita.29.2017.02.17.10.26.48 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:26:48 -0800 (PST)
Received: by mail-it0-f53.google.com with SMTP id h10so28993196ith.1 for <mmusic@ietf.org>; Fri, 17 Feb 2017 10:26:48 -0800 (PST)
X-Received: by 10.107.46.231 with SMTP id u100mr8868394iou.8.1487356007752; Fri, 17 Feb 2017 10:26:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.233.3 with HTTP; Fri, 17 Feb 2017 10:26:47 -0800 (PST)
In-Reply-To: <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com>
References: <CABcZeBOK0T5WbMLi=AS3WOAjDt_D8e8JSTp2czSYdhHv8Xcgtw@mail.gmail.com> <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <CAD5OKxt4mBZ=RaLheOuZCp2TZuhiNZ1E9a86NL8TQ1U2kGsZeQ@mail.gmail.com> <CABcZeBOSt9B43BbNFw29fLOOwvvTTR18eK_ELmF5-carG=ouuA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <CAD5OKxvZ7xwQ6eXEFy0p-SPezaVM2XK=K5rThv1w+1Xc511FkA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se> <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 17 Feb 2017 13:26:47 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt_HNOTEWN_62u_7JoR=pyUW6H6v-oBTcimoOJz36LbRg@mail.gmail.com>
Message-ID: <CAD5OKxt_HNOTEWN_62u_7JoR=pyUW6H6v-oBTcimoOJz36LbRg@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary="001a113524927f5a7d0548be0eb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/r0rYPRj1OeemoxdfyftAsBJD-Qk>
Cc: mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
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: Fri, 17 Feb 2017 18:26:51 -0000

On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell <ben@nostrum.com> wrote:

> While it's the chairs' prerogative to judge consensus, it seems to me that
> the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and
> "we might need it". Since the draft has already been approved by the IESG,
> we shouldn't make a material change unless we have a really good reason. I
> propose leaving it in.
>

As you have probably noticed I am strongly for leaving TCP/DTLS/SCTP in the
draft, since things will break otherwise and draft will require substantial
editing to recover.


> On 16 Feb 2017, at 11:54, Christer Holmberg wrote:
>
> Once nomination process is completed, it should be the selected, not the
>>> default >candidate.
>>>
>>> When session is established or during ICE restart, multiple candidates
>>> are sent >in offer/answer and DEFAULT candidate must be used in the m= line.
>>>
>>> Once nomination process is completed, only the currently selected
>>> candidate is >sent in offer/answer and this would be the candidate in the
>>> m= line. Resources >associated with other candidates, such as network ports
>>> or TURN allocations, >are typically released at that point, so there is no
>>> point to include them any >more.
>>>
>>
>> Well, then we need to clarify the text (or remove the text completely,
>> and simply refer to the ICE spec), because the ICE considerations section
>> talks about offers and answers in general.
>>
>
> To be clear, are you talking about clarifying text in _this_ draft, or
> elsewhere?
>
>
Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp.
As the language stands right now, it is not incorrect, but is slightly
confusing, since it is talking about default candidates for all ICE related
offer/answer exchanges.  After ICE nomination process is completed, there
is only one candidate left, so there is no default. In session descriptions
that describe the session after ICE nomination is complete only one
candidate is present, so there is typically no confusion about what goes
into the m= line, but this is not spelled out in the draft. I will submit
the PR and Christer can merge and resubmit the draft when he is back.

Regards,
_____________
Roman Shpount