Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description

"Roni Even (A)" <roni.even@huawei.com> Tue, 19 February 2019 06:52 UTC

Return-Path: <roni.even@huawei.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 95B66130E82; Mon, 18 Feb 2019 22:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 1s0jFAZ78hhd; Mon, 18 Feb 2019 22:52:20 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A7591130E7E; Mon, 18 Feb 2019 22:52:20 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4B6D3C3C212A47C1E186; Tue, 19 Feb 2019 06:52:18 +0000 (GMT)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Feb 2019 06:52:17 +0000
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 19 Feb 2019 06:52:17 +0000
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Tue, 19 Feb 2019 06:52:17 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.222]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0415.000; Tue, 19 Feb 2019 14:52:11 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Ben Campbell <ben@nostrum.com>, "draft-ietf-mmusic-rfc4566bis.all@ietf.org" <draft-ietf-mmusic-rfc4566bis.all@ietf.org>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, mmusic WG <mmusic@ietf.org>, 'Colin Perkins' <csp@csperkins.org>
Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description
Thread-Index: AQHUx8fxbs918E2F1karkE7QXY8wS6XmrKuQ
Date: Tue, 19 Feb 2019 06:52:10 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CB5561@dggemm526-mbx.china.huawei.com>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <e7e0042a-8079-8c0e-0ddd-1ea330f08e7c@alum.mit.edu> <355f8125-87f8-6372-8289-126fa126ccb9@alum.mit.edu>
In-Reply-To: <355f8125-87f8-6372-8289-126fa126ccb9@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.80]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/339woA1OBvXe3hn6SLCFZ_HZTdY>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Feb 2019 06:52:23 -0000

Hi Paul,
I am not sure why we need to  change the definition.

A media description describes the media and it start with a m= line  ... (and so on)

If want to expand maybe say that it must start with an m= line and will include the sdp types as listed in section 5


Media description, if present
         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information -- optional if included at
              session level)
         b=* (zero or more bandwidth information lines)
         k=* (encryption key)
         a=* (zero or more media attribute lines)


Media description is not about RTP since the proto attribute in the m-line can define others see https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2  

for example in draft data-channel-sdpneg we have:  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel which is not RTP.


Roni Even

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Monday, February 18, 2019 10:24 PM
To: Ben Campbell; draft-ietf-mmusic-rfc4566bis.all@ietf.org
Cc: Magnus Westerlund; mmusic WG; 'Colin Perkins'
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Media Description



> On 2/11/19 10:45 PM, Ben Campbell wrote:

>> §2, “Media Description”: While true, the text here is not a 
>> definition of anything but syntax. Please add a sentence or two to 
>> say what the media description semantically represents.
I'm having trouble finding a suitable semantic definition of Media Description.

My first thought is that it provides the information necessary to establish a media session. But while *Multimedia Session* is described, media Session isn't defined in the document.

I looked at RFC7656 (Taxonomy) for a definition, but it doesn't have one either. It defines RTP Session, and Multimedia Session as one or more RTP Sessions. That is close, but in SDP media sessions need not be RTP.

Is there any suitable existing definition???

If not, then how about:

"A Media Description contains the information needed for one party to establish an application layer network protocol connection to another party." ???

OR

"A Media Description contains the information needed for one party to establish a Media Session with another party."

"A Media Session is an application layer network protocol connection between two parties."

It seems important to get this right! It is essentially a broadening of
RFC7656 beyond RTP.

	Thanks,
	Paul


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic