Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel

Christer Holmberg <> Thu, 22 August 2019 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03C27120C28 for <>; Thu, 22 Aug 2019 13:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mNLy0nAIpjfW for <>; Thu, 22 Aug 2019 13:55:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4887D1209D8 for <>; Thu, 22 Aug 2019 13:55:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=GJbLIBkzHsYQs9lMR0RfhrUsCIa2dFktLffi8qbYTQ/LBHI/NxNTbjBiu4hfX6JhAbVKJByCv+iFXj8KJhZ2PYTEJwtuFG5lUM/p7hyVmHbjSYV0PwUbabajhRMgidYpU4oFmKrJ80ExXVVUx3H44+CJmaJZiLSB9foXDQ6OydriTUVfrRoN8cIpQS0Mqrveb3tZRTig5LdUtEf2sGKA6Mqw1SSa6Xfddg57ATy8JEyUnw5E8Z8+sfyXltFToY6ZRaViHf+K4CUefZe6I6djtEz+ZKjcho3OMNyyGt6++SCKF1ntyyfRp5s2PtkpAsWHMCGmVk6BzE3bFq9GDwTv+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h+R4xzj85j+CcIBOVJNn/g41zmAqleu0J9eTG/Ty5GU=; b=LzuR6TWCV7/BOrr1L6nSF8FwWmd6DvUbmbW5p9utg4bP7BwPnL+PMNTwcO3pSAqusdhJZFBVmpGVLm+++jtPyq0lSeNfEwWgFkyogZQUeHVNgZgokIbMylocOx7cSMFWhKdCzH6Q+WFDGZHGt2R3dSeFzNBeaPKs2/a2msGNK1qPIF49Nq2bruc7A9QEIbkLS0QWEdYOgPi/VcNqp4vnFVvOcr4UwhBxYSZmWnh15BMB4O2zPyFV3p3XXzKqBbssLoLaWDhcwohnBCZCSPfy4nWyCj9rP0FM3KuA872Rm8RhVTtNA5eY3hRDhuOl+g56vJfg3SKnV7/D90mWOgONUQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h+R4xzj85j+CcIBOVJNn/g41zmAqleu0J9eTG/Ty5GU=; b=hK4Tm0Vf6AWk0wTCwxrf+IqenpdTEe+ajAlzejjzPHHRphyU6Bd6Tr8qyqRDFWXqAV++UWnDOps1dOg1BXHTpHexeSWjgMrxX8BdM3PP2rsRloUksarM9Y/OKRlu8Ya/kjMLZ79dPm3q5iNB+zv1TH0hg/0z+gtB2HHuByRd6/U=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.12; Thu, 22 Aug 2019 20:55:08 +0000
Received: from ([fe80::d031:8cb6:bfb:dc3]) by ([fe80::d031:8cb6:bfb:dc3%3]) with mapi id 15.20.2199.011; Thu, 22 Aug 2019 20:55:08 +0000
From: Christer Holmberg <>
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <>, Bernard Aboba <>
CC: "" <>
Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
Thread-Index: AQHVTtmu0b05snoDfkq4tQT6JA1d/ab+b6CAgAB3E5CABz7XAIABGpmAgABASoCAADPOAIAABFXg
Date: Thu, 22 Aug 2019 20:55:08 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c147b4b9-5806-4b68-45e9-08d72743047c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB3085;
x-ms-traffictypediagnostic: VI1PR07MB3085:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 01371B902F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(396003)(346002)(199004)(189003)(316002)(53936002)(8676002)(52536014)(66946007)(14444005)(81156014)(256004)(5660300002)(66556008)(66476007)(14454004)(8936002)(186003)(55016002)(6506007)(3846002)(6116002)(81166006)(64756008)(76116006)(2906002)(9686003)(6306002)(99286004)(305945005)(7736002)(7696005)(11346002)(446003)(71190400001)(71200400001)(486006)(76176011)(66574012)(66446008)(44832011)(4326008)(25786009)(66066001)(86362001)(110136005)(476003)(102836004)(33656002)(6436002)(966005)(26005)(74316002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3085;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: x1xuxwYGLdYBlaWUs7eK5IRKWDKXh4VqHVSGZto9O5+/vgB8U25A948NY79Ybx5ZNbrDg3nOASxU8Q12h5GOZG/JrlNfq0jgGSAZ3fkbmLOBhuJ2C/lXXnnxBRwu9oqzC92eiDS6MblrpNv2vhPcU4eM9Gl++8R8w5E//yJtq+UeKh3krsqfrzBD6G8gLCetxccgyOaAp+L6D1qNFeUmQh9LfYPqJeqd5BvgjtsbCc++uSn1KG/hbuz4sf6w1zEzhdUINcI1qZTr4/dFYcMOzSKCQ0CmRpJrBU9PlVz8dpV+olGVAHhKQlH7m15ZVX0JJ87oDR2Dw8GFbrZRQPy1pwsdRHsR4YrYwUvs4Hw8VVoCgMDVeguc0G8KsFDXsvAFowcYwMYXehOdNLQ5oYKD91lEwRbyE1UPF89wvHwIaN8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c147b4b9-5806-4b68-45e9-08d72743047c
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 20:55:08.6720 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zL1zJx7AD+aHik5pCcb4dKp4ZZCFXkfI1TqrImhdAjyKIZakdtR+d6yhUf13Dpf40VIUZnefRKEc1XdRTFeCtT/tUY52j/z1ncs298GyTMc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3085
Archived-At: <>
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2019 20:55:15 -0000


>I want to add one issue for the security section: Can we specify a way to achieve end-to-end encryption of T.140 >data between a WebRTC endpoint and a traditional SIP/RFC 4103 endpoint through a gateway? I know that that is a >desired feature.

How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so doesn't the gateway have to decrypt/encrypt the T.140 traffic?



Den 2019-08-22 kl. 16:28, skrev Christer Holmberg:
> I have created a pull request, which will be used for the changes based on Gunnar's comments:
> bf25-4deb49c05b8a2375&q=1&
> atachannel-t140%2Fpull%2F5
> Regards,
> Christer
> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" < on behalf of>; wrote:
>      Hi Gunnar,
>      Thanks you for your support (I assume :) and comments on the draft!
>      See inline.
>      >A couple of comments:
>      >1) In 3.2, the attribute "cps" is misspelled "cpc" once.
>      Will fix.
>      ---
>      >2) Section 5 has some historical references to real-time text transports that may not be of much interest anymore
>      >and instead confuse the reader, while some other more relevant transports may be added.
>      I took these from the schwarz draft. You probably know better 
> than me which ones are relevant, so feel to suggest which one(s) 
> should be removed, and which one(s) should be be added :)
>      >I would also like to discuss if it could be possible to have a few general recommendations on the webrtc to sip/rfc4103 case without
>      >the problems you see with having a detailed gateway section.
>      The second last paragraph covers some things on the media plane (out of order and loss of RTP packets) that I think are worth mentioning.
>      As far as SDP interworking is concerned, this draft defines the m- line for T.140 data channel, and RFC 4103 defines the m- line for T.140 RTP, and the interworking should be very straight forwards. Do you have something specific in mind regarding general recommendations?
>      ---
>      > 3) Reliability. Section 3.1 implies that the channel is used in the reliable and ordered mode. We have been discussing back and forth
>      > if that is the right choice for real-time text. I tend to think it is, but it might be useful to discuss it once again. The traditional user
>      > requirement on real-time text is that produced characters shall be presented to the receiver within one second from their creation.
>      > Modern usage in speech-to-text applications may require more rapid transmission. As I understand it, the reliable mode of the
>      > data channel may imply long periods of choked transmission in case of network problems or by influence of heavy transmission
>      > in another channel. As long as this happens only in case of network problems, I now tend to think that that might be acceptable.
>      > The effects of being forced to use an unreliable channel are so far-going so I would like to avoid that.
>      > However, the word "reliable" is misleading. A "reliable" channel is not really reliable. It can break in case of problems.
>      True, but "reliable" is the terminology used in both RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel.
>      > I think some recommendations should be inserted in section 4 about what to do when a channel breaks. The natural action
>      > would be for both sides to try to figure out what was the last T.140 data that was transmitted and received, and then try to
>      > reconnect and resume transmission if successful. If any T.140 data was lost during the break, that state should be marked
>      > by inserting the "missing data" T.140 indicator in the received stream. There needs of course also be a recommended action
>      > if it turns out to be impossible to reconnect after a low number of retries.
>      I can for sure add some text about that. Are there generic T.140 recommendations for failure that we can reference, or do you think there is something T.140 data channel specific?
>      Regards,
>      Christer
>      _______________________________________________
>      mmusic mailing list
Gunnar Hellström
+46 708 204 288