Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 03 October 2019 13:40 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 730E01208FD for <mmusic@ietfa.amsl.com>; Thu, 3 Oct 2019 06:40:50 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=omnitorab.onmicrosoft.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 7BaEP8oQJgDZ for <mmusic@ietfa.amsl.com>; Thu, 3 Oct 2019 06:40:45 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130125.outbound.protection.outlook.com [40.107.13.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474A41208F3 for <mmusic@ietf.org>; Thu, 3 Oct 2019 06:40:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ad7fzbKACS1yZPPBeJh+AWgkWCjXLlzSgH77Wob0s561+VMsT5M78DUXbzeisePDw1Ewmv5LsDeWlTu3uvXRoS57NZsbk7hrlX6m45EKM28ZHNeQfNTfwR+OIJbcdLSoE64OhPM3TM/4Ew/YDj4k6Yg+tmYqE/2nL0XCMDQZxYbQPwD6g569yJyEDeCo4bJOSY9V/5hKG7wpnmfdFy5mMLC6tL+5azPySXziMtQCVNM9DazL83vsLzac3kXcSMQJUddWjpW5xHO420WA2jo0WIryIQ06Q5TmCTHzlESa9Z8e/J2t0c50JCT0RXmr8fe1dlWuRGeUJtZg2QhnKzSuew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=17qR05Sj3sJvk0I2o22yiralWdL91VR5mBnt/XQXwR0=; b=a8G07638wnEMQ/jURDOd30TyO30n+5LHbutldEkP+gDpZ95gKJKA+LYExWAza00JwvLGLpxYVloCYCkpv+ibqhaHEsfNAr/WTO6T9Sk7zEQ5lE0YIlv6CazS5yaPldC14xnl7a/SqYea5ftiQsysjo4DFeIuOmoULIHWmxIC5LmmVD3nBEnsCKAyaMf4gW6H2EwMy7yW99xbOYeIvJXPnbgT83o+EizGaVjns5Zq3VJDUDrqzugni72kCfpU5dF0xLyXrKvzxT+npihtCjspjha2YdgpyPVicQvjh2GC+HWIDbK/DNllOzA6cYlfCsFfDgA4nyjyUoA5Xs+P5kdclw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=17qR05Sj3sJvk0I2o22yiralWdL91VR5mBnt/XQXwR0=; b=I2w2kJ/ifRQf2koTb5QZwIwi8HlC8iL3l5OVncvrIVY3PwjL3WYZ64xgcvPCNeDM5bvg0X5WnachXZuL3ho72rvQpl9WkTETa2lypdmaVYWmvycdBXbyoiFCOvQrWT852o3GdTn8xromuxyTLHYy+jFuZ9YU+nZpRlTXjNujbwc=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0703.EURP193.PROD.OUTLOOK.COM (10.186.178.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 13:40:41 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::ec96:d49e:287d:6c1]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::ec96:d49e:287d:6c1%3]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 13:40:41 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06
Thread-Index: AdV5JBu3/7R1eFiwT0+abl8CWK3iFAArTgsAAAir1ID//98TgIAAGS4A
Date: Thu, 03 Oct 2019 13:40:41 +0000
Message-ID: <ffdb4268-ddee-b5c9-c549-5bff86203283@omnitor.se>
References: <HE1PR07MB3259435390044A9DCE53123B8D9C0@HE1PR07MB3259.eurprd07.prod.outlook.com> <b4f3e9ca-ca62-c822-6991-87835c4cb6be@omnitor.se> <57665CB6-6668-4585-864D-16A02FBEF228@ericsson.com> <d54b7de0-e846-24e0-fd91-df085f683cc8@omnitor.se>
In-Reply-To: <d54b7de0-e846-24e0-fd91-df085f683cc8@omnitor.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: PR0P264CA0048.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::36) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [77.53.231.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 81e43bc6-99b9-456b-2737-08d74807487a
x-ms-traffictypediagnostic: VI1P193MB0703:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1P193MB07035E2993632746275D4478FB9F0@VI1P193MB0703.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01792087B6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(376002)(366004)(346002)(136003)(189003)(199004)(14454004)(8936002)(81166006)(81156014)(66574012)(66066001)(6246003)(36756003)(86362001)(508600001)(446003)(2616005)(11346002)(6486002)(6512007)(6436002)(6306002)(966005)(476003)(31696002)(31686004)(8676002)(7736002)(386003)(85202003)(186003)(561944003)(26005)(6506007)(102836004)(85182001)(25786009)(305945005)(99286004)(486006)(71190400001)(5660300002)(316002)(66476007)(66556008)(64756008)(66446008)(76176011)(14444005)(52116002)(71200400001)(110136005)(2906002)(229853002)(256004)(3846002)(6116002)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0703; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XexunZhctf9oDgyEUHHe95CAHCs1UOibFaFnmCiUD273ny6BhdzOGr5aJOTfjhnMDoR8xmuWuHFe5ev8vNstM68JU6jaioQXaW9q6S2hL/R7nvXRICmcUhwAeOhsOu5JplWGHBPbiuL9+zuspGmcO66ES8fd44ANOXheBXdSnbMzseFY+4wVEpa0YWpeR97/enp4yKAl4n5BEBVR6nTp2NrHDmMxd1YW8veff19SsWRAGHItq/Mnx8GBDr/sOIxBz9w1Pi7M2IRBuociL6UbIaK6IlIWLzV6opxx/TLS05yPrAWHA4q59O0gqQGG9q/ql484HMS0l2W2EVUHEdloFfjQnLREvB4uQ+/zylugXWTXSNoex/g9po0jR8GowaZsTjjnUPYWrQUm7x/ceKDxsASLxS3H3ZveOCI1HOvG0V3UTMUzr1sRvycz4DAsjaUBiayrC6vb8cxgBcGBK1eWxw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4540A4A735DED340B9EE450BAA38B96A@EURP193.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 81e43bc6-99b9-456b-2737-08d74807487a
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 13:40:41.6632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QybqBG6jxGXH6rY0Zx/svjFX0gFUA2kpObzJolMQMylnVc/uGLCRKQIsS9drRNAxpEJuFyGahHqTKHFsG3M5HHnhJyecAzV05RaT2Ui9F1Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0703
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5K48vp2_9RqpeGb0zXSvVldKv80>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06
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: Thu, 03 Oct 2019 13:40:51 -0000

I have now created GitHub pull requests for all accepted or still 
discussed points from the 17 point list below.

Regards

Gunnar

Den 2019-10-03 kl. 14:10, skrev Gunnar Hellström:
> Hi Christer, please see responses inline,
>
> Den 2019-10-03 kl. 13:08, skrev Christer Holmberg:
>> Hi Gunnar,
>>
>> Thank You for the review! Please see inline.
>>
>>> I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06 and 
>>> find it to be in good shape, important and sufficient for its 
>>> purpose. I see also that
>>> further separate work is desirable for the multi-party 
>>> considerations and the gateway considerations.
>>>
>>> I found some places where mainly editorial improvements can be made:
>>>
>>> 1. In 4.1, misspelling. "descripton" sb "description"
>> Will be fixed.
>>
>>> 2. In 4.1 Note, misspelling "negotied" sb "negotiated"
>> Will be fixed.
>>
>>> 3. In 1., line 4  the last informational reference in the paragraph 
>>> should be to RFC 3550 instead of RFC 4103
>> Will be fixed.
>>
>>> 4. In 3, delete "using the RTP timestamp". It is usually the 
>>> sequence number that helps finding where data is missing.
>> The sequence number is used to detect missing data, but the timestamp 
>> is used for data redundancy.
>>
>>     "The RTP header is followed by one or more redundant data block
>>     headers: one for each redundant data block to be included. Each of
>>     these headers provides the timestamp offset and length of the
>>     corresponding data block,"  (RFC 4103, Section 4.1)
> {GH] Well, that is the coding of the redundancy data block, but not 
> how loss is detected. I do not know any implementation that bothers 
> about details in the RTP timestamp for detecting loss. Instead, the 
> sequence numbers of the redundant parts can be evaluated by 
> subtraction from the current RTP sequence number and then it is easy 
> to detect if some data needs to be recovered from the redundant parts 
> or if there is a irrecoverable gap in received sequence numbers. So, I 
> sustain my proposal to delete "using the RTP timestamp".
>>> 5. In 4.2, first line: "an SDP 'dcsa' attribute" s.b. "one or more 
>>> SDP 'dcsa' attributes"
>> Will be fixed.
>>
>>> 6. At the end of 4.2, add "section 6.7" because it is hard to find 
>>> in sdpneg where it is specified how to handle unknown attributes 
>>> (and the wording in 6.7 is confusing, but that is another matter)
>> Will be fixed.
>>
>>> 7. In 4.2.3 delete the last sentence "An offerer and answerer MUST 
>>> mark the direction of the text by sending a direction attribute 
>>> inside 'dcsa' attribute."
>>> This is superfluous information, and it can be misunderstood that 
>>> the direction attribute always must be explicitly provided. (another 
>>> solution could be to
>>> improve the sentence by including when the direction must be included)
>> I suggest to delete the last sentence.
> [GH] good
>>> 8. In 4.2.3.1.1 "both send or receive" s.b. "both send and receive"
>> Will be fixed.
>>
>>> 9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last 
>>> paragraph of 4.2.3.1.1 says that the answerer might not support
>>> direction marking. It is then illogical to require that.
>>>
>>> 10. In 4.2.3.1.2 second paragraph. The wording about not indicating 
>>> 'sendrecv' means implicit marking as sendrecv is a bit confusing and 
>>> may
>>> cause implementers to believe that they must always provide explicit 
>>> marking of direction. A remedy might be to swap order between the two
>>> sentences in the second paragraph and insert "(implicitly or 
>>> explicitly)" after "sendrecv" to make the paragraph wording:
>>> "If the answerer does not explicitly mark the data channel, a 
>>> 'sendrecv' attribute inside a 'dcsa' attribute is implicitly 
>>> applied. If the offerer
>>> marked the data channel as sendrecv (implicitly or explicitly), the 
>>> answerer SHOULD mark the data channel as sendrecv(implicitly or 
>>> explicitly),
>>> sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 
>>> 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "
>> I don't like the SHOULD. We define the procedures for an answerer 
>> that do support the procedures.
>>
>> The last paragraph of Section 4.2.3.1.1 already points out that the 
>> answerer may not support setting the direction attribute, and how the 
>> offerer handles it.
>>
>> Other than that, I am fine with your suggestion to change the ordering.
>>
>> Or, we could make it even shorter:
>>
>>     "If the offerer marked the data channel as sendrecv (implicitly or
>>       explicitly), the answerer MUST mark the data channel as sendrecv
>>       sendrecv (implicitly or explicitly), sendonly, recvonly or 
>> inactive with
>>       a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' 
>> attribute inside
>>       a 'dcsa' attribute."
> [GH] accepted, ( but you have double sendrcv on lines 2-3 in your 
> proposal above)
>>
>>> 11. In 4.3 Examples, some values are unusual and should be selected 
>>> to be more natural:
>>> The stream-id in the offer is very often even because it is most 
>>> often the same party who takes the initiative to the SCTP association
>>> who also sends the initial offer. Thus, change all stream-id in the 
>>> examples from the odd 1 to e.g. the even 2
>> Will fix.
>>
>>> Use different udp port numbers in the m-lines in the offers and 
>>> corrsponding answers.
>> Will fix.
>>
>>> Use different sctp port numbers in offers and corresponding answers.
>> Will fix.
>>
>>> 12. In 5.2 Change the header to "5.2 Data Encoding, Sending and 
>>> Receiving"
>>> and insert last this important hint for interoperability.
>>> "The T.140 coding details contain information on optional control 
>>> codes intended for controlling the
>>> presentation that may not be supported by the presentation level of 
>>> the receiving application. The
>>> receiving application MUST handle reception of such T.140 control 
>>> codes properly (e.g. ignore them)
>>> even if their effect on presentation is not supported."
>> That is not data channel specific, is it? I assume it is already part 
>> of T.140, so we shall not specify new MUST requirements.
>>
>> With that, I suggest to not change the title.
> [GH] Right, but it is an important reminder for interoperability 
> between implementations. So, make it a NOTE instead and change the 
> MUST to something suitable (needs to ?).
>>> 13. In 6. Gateway considerations:
>>> At the end of bullet point 4 add "in reception"
>> I think "was lost in reception" sounds strange.  What about "was lost 
>> due to the data channel failure"?
> [GH] I wanted to point out in what direction it was lost. In T.140 
> data channels, the sender has in fact better opportunity than the 
> receiver to detect if something was lost. Bullet point 4 was intended 
> to tell about data received on the T.140 data channel to be sent on 
> the RTP stream. I want to insert a new bullet point (see 14) for when 
> the gateway detects loss in sending in the T.140 data channel. 
> Therefore it should be clear that bullet point 4 is for the reception 
> case. What about "was lost when receiving from the T.140 data channel 
> due to the data channel failure" ?
>>
>>> 14. In 6. Gateway considerations:
>>> After bullet point 4, add one more bullet point:
>>> "If the gateway detects that the T.140 data channel has failed and 
>>> got torn down, once the data channel has been reestablished the
>>> gateway SHOULD insert the T.140 missing text marker [T140ad1] in the 
>>> data sent on the outgoing T.140 data channel if it detects or
>>> suspects that data sent or to be sent on the T.140 data channel was 
>>> lost during the failure. Data that may have been correctly
>>> transmitted and received MUST not be repeated."
>> I don't think we need the last sentence, because it is confusing. It 
>> is enough to say that the procedure is done if the gateway detects or 
>> suspects that data was lost.
> [GH] Accepted
>>
>>> 15. In 6. Gateway considerations:
>>> In the last bullet point, change MUST to SHOULD, because we say 
>>> above that some implementations may not support
>>> the direction attributes.
>> We define the procedures for implementations that are compliant with 
>> the spec, and for such implementations it is a MUST.
>>
>> We can have text about implementations that don't support the 
>> procedures (as we have in section 4.2.3.1.1., when the answerer does 
>> not support the direction attributes), and how it impacts things, but 
>> we shall not modify the normative procedures because of that.
> [GH]Accepted. The language you ask for is kind of already there, so I 
> do not require anything more here.
>>
>>> 16. In 7 Update to RFC 8373
>>> Reference for RFC 8373 is missing
>> Will fix.
>>
>>> 17. In 11.2 Informational references:
>>> Add reference to RFC 3550 as indicated in point 3 above.
>> Will fix.
>>
>>> I intend to provide these comments also as change proposals in GitHub.
>> Ok.
>>
>> Regards,
>>
>> Christer
>
> Regards
>
> Gunnar
>
>>
>>
>>
>>
>>
>>
>>
>> Den 2019-10-02 kl. 15:25, skrev Bo Burman:
>> Greetings MMUSIC ,
>>
>> This is to announce a 2 week WGLC on the draft:
>>
>> https://protect2.fireeye.com/url?k=806502d9-dcecd8e4-80654242-0cc47ad93c0c-e10d1004cdda139e&q=1&u=https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt
>>
>> as Proposed Standard. Please review and provide any comments you may 
>> have on the document by Wednesday, October 16, 2019. Comments should 
>> be sent to the document authors and the MMUSIC WG list. If you review 
>> the document but do not have any comments, please send a note to that 
>> effect as well.
>>
>> Thanks,
>>
>> /Bo
>> (MMUSIC co-chair)
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mailto:mmusic@ietf.org
>> https://protect2.fireeye.com/url?k=a6662b9d-faeff1a0-a6666b06-0cc47ad93c0c-f61b6b0757d55756&q=1&u=https://www.ietf.org/mailman/listinfo/mmusic 
>>
>>
-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288