IETF Logo Mail Archive

Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Ben Campbell <ben@nostrum.com> Mon, 20 February 2017 09:49 UTC

Return-Path: <ben@nostrum.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 38CB812960C; Mon, 20 Feb 2017 01:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 YkAlpEm-5o9J; Mon, 20 Feb 2017 01:49:17 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EDE81128B38; Mon, 20 Feb 2017 01:49:16 -0800 (PST)
Received: from [192.168.111.218] ([88.190.148.61]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1K9n6wt042820 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Feb 2017 03:49:09 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [88.190.148.61] claimed to be [192.168.111.218]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Ben Campbell <ben@nostrum.com>
X-Mailer: iPad Mail (14D27)
In-Reply-To: <CAD5OKxu7DJ5sMW0G_SvzyKiYVeyGxFVSub-aiT2u8kXCfqCF+g@mail.gmail.com>
Date: Mon, 20 Feb 2017 10:49:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com>
References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <CABcZeBPPFUe-ZtW9Lt636OhoMH8ws2oVi94YQJeUQKXteC-XRg@mail.gmail.com> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <CAD5OKxu7DJ5sMW0G_SvzyKiYVeyGxFVSub-aiT2u8kXCfqCF+g@mail.gmail.com>
To: Roman Shpount <rshpount@turbobridge.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/NQsSTEwG93eP0qTfk1h-XULqFOs>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>
Subject: Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)
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: Mon, 20 Feb 2017 09:49:18 -0000

> 
> On Feb 19, 2017, at 5:46 PM, Roman Shpount <rshpount@turbobridge.com> wrote:
> 

[...]

> We are happy to add any informational content to describe the implications of running SCTP on top of TCP, but we would prefer not to redefine how ICE operates (including framing used for ICE TCP) in this draft. I think, generic ICE procedures belong in ICE related drafts.

I agree in principle; this draft is about signaling, not the media stream itself. But Mirja's comments suggest that the referenced specs may not fully describe how the stream works. Is there anything else we could reference (e.g.  RTCWEB data-channel or transports drafts) that would help clarify?  (Please feel free to argue that the referenced docs do in fact describe things sufficiently for the purposes of this draft, if you believe that to be true :-) )


Thanks,

Ben.

v2.23.0 | Report a Bug | By Email