IETF Logo Mail Archive

Re: [AVTCORE] Alexey Melnikov's No Objection on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT)

Roni Even <roni.even@huawei.com> Thu, 22 June 2017 08:32 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6AD128AB0; Thu, 22 Jun 2017 01:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 Srh8sPn3WqCO; Thu, 22 Jun 2017 01:32:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579F11242F7; Thu, 22 Jun 2017 01:32:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIZ39066; Thu, 22 Jun 2017 08:32:00 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 09:30:17 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 22 Jun 2017 16:30:03 +0800
From: Roni Even <roni.even@huawei.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, "singer@apple.com" <singer@apple.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-avtcore-rfc5285-bis@ietf.org" <draft-ietf-avtcore-rfc5285-bis@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT)
Thread-Index: AQHS6m6omU7jd1k9E0Ce9+tqopQFt6IwiNLA
Date: Thu, 22 Jun 2017 08:30:01 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7DBA42@DGGEMM506-MBX.china.huawei.com>
References: <149797808384.24922.16736269841062630572.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7DB466@DGGEMM506-MBX.china.huawei.com> <246EEFE0-D1E4-45A2-A455-58599FDA68DA@fastmail.fm>
In-Reply-To: <246EEFE0-D1E4-45A2-A455-58599FDA68DA@fastmail.fm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.594B8081.0082, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e83ab901c8f96386c4aa102347e9ee3f
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/h86MK-3sZ9pasaDM4MdTyynsMSY>
Subject: Re: [AVTCORE] Alexey Melnikov's No Objection on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jun 2017 08:32:08 -0000

Hi Alexey ,
Just answering with the open issue from section 7


Reading these two paragraphs I can see the cases for not removing,  I think that the logic is not complete and suggest the following
 
If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.   An answerer MAY want to respond that he supports the extension and may use it in the future will mark the extension as "inactive"

To clarify: If the answerer is able to send this extension if and when the current offerer change his directionality

  
 If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer. An answerer may want to respond that he support this extension and may send in the future or will be able to receive by marking the extension as "inactive"

Roni

v2.23.0 | Report a Bug | By Email