Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11

Christian Groves <Christian.Groves@nteczone.com> Fri, 20 January 2017 07:16 UTC

Return-Path: <Christian.Groves@nteczone.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 93FB0129A26 for <mmusic@ietfa.amsl.com>; Thu, 19 Jan 2017 23:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 5AuKfyzs1p8Z for <mmusic@ietfa.amsl.com>; Thu, 19 Jan 2017 23:16:59 -0800 (PST)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 E6C6E12995F for <mmusic@ietf.org>; Thu, 19 Jan 2017 23:16:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TtJp2rzESGP8ZtPjimEu8T9YKO1JUB39StKjF9O0jjU=; b=dzyhfjfer6FhTZld9jWnOXuIWm VFO38UJ+Ty0N0ZgEIqxUlPMeXjaYt3M2u+dr1/9miQfJVFKR5ADAMX/F2D5i5yD4SIIRyxz/6C4L5 Gs2ahyMGQoU1ABC3/E+cyYTbTwq/vrGLS0N7XL6mLmj4XiXVT2KlU94n/hbbVcBT61xhZ2OyHQ4x4 YNtOalxiwLNqZGHTzBTdGUZ3dAMWsHOmic4I8j0zKaAwmJa3y2tjEQoFe90N91fSUxPZzmPXr1nkv t8J2OyqEKpwQSpkGpfXBOJfY1kYVbTtRqwvprG8HZjqnfUc0LmLqYaRhFRACEQxLfiOO7bjOUGyck TWWjyjiQ==;
Received: from ppp118-209-171-56.lns20.mel8.internode.on.net ([118.209.171.56]:50647 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <Christian.Groves@nteczone.com>) id 1cUTRQ-001EoD-RR for mmusic@ietf.org; Fri, 20 Jan 2017 18:16:56 +1100
To: mmusic@ietf.org
References: <AM5PR0701MB2577808960A0AE88E584E3AB8D7D0@AM5PR0701MB2577.eurprd07.prod.outlook.com> <b7ca7074-e20c-e85d-d1bb-62c51c2a7c75@comcast.net>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com>
Date: Fri, 20 Jan 2017 18:16:49 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <b7ca7074-e20c-e85d-d1bb-62c51c2a7c75@comcast.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/-rzebkDdweyJ0JQbRpPL-w0Q000>
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11
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, 20 Jan 2017 07:16:59 -0000

Hello Paul,

Please see below.

Regards, Christian

On 17/01/2017 6:56 AM, Paul Kyzivat wrote:
> I've followed this document closely throughout its development.
> In preparation for this message I reviewed the document again. I found 
> some things that need to be addressed:
>
> 1) MAJOR: Section 5.1.1.3 and various other places:
>
> I can find nothing here or elsewhere in the document that says whether 
> the the stream id in an offer is the id on which the offerer will 
> receive, or the ID on which it will send. Of course this is irrelevant 
> if both ends agree to use the same id, but that isn't required.
>
> For this to interact properly with attributes for individual streams 
> (in dcsa) I think it will be necessary for this to be consistent with 
> the say SDP negotiates media sections - namely that the SDP in an 
> offer identifies where the offerer wants to *receive* the media.
>
> It will probably require changes in a variety of places to get this 
> sorted out.

[CNG] There is some guidance in clause 5.2.1 around managing stream 
identifiers. Utilising the same Stream ID is required when supporting 
WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). 
Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that the 
opposite datachannels have the same set of attributes. SCTP stream 
identifier being one of those.

>
> 2) MINOR: Section 5.1.1 says:
>
>    The intention in exchanging these attributes is to create, on two
>    peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched
>    pairs of oppositely directed data channels having the same set of
>    attributes.  It is assumed that the data channel properties
>    (reliable/partially reliable, ordered/unordered) are suitable per the
>    subprotocol transport requirements.
>
> In this, "matched pairs of oppositely directed data channels" is 
> improper terminology. Each channel *is* a matched pair, of oppositely 
> directed SCTP streams.
[CNG] Yes I agree.
> ..snip..