[MMUSIC] Open source SIP/WebRTC real-time text integration
Lorenzo Miniero <lorenzo@meetecho.com> Wed, 18 December 2019 11:05 UTC
Return-Path: <lorenzo@meetecho.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 A462912013C for <mmusic@ietfa.amsl.com>; Wed, 18 Dec 2019 03:05:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
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 LUC_Cq97yUd7 for <mmusic@ietfa.amsl.com>; Wed, 18 Dec 2019 03:05:00 -0800 (PST)
Received: from smtpcmd0641.aruba.it (smtpcmd0641.aruba.it [62.149.156.41]) by ietfa.amsl.com (Postfix) with ESMTP id 44A24120898 for <mmusic@ietf.org>; Wed, 18 Dec 2019 03:05:00 -0800 (PST)
Received: from lminiero ([93.44.36.221]) by smtpcmd06.ad.aruba.it with bizsmtp id fP4s2101P4mGZ9p01P4ssM; Wed, 18 Dec 2019 12:04:55 +0100
Date: Wed, 18 Dec 2019 12:04:51 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: mmusic@ietf.org
Message-ID: <20191218120451.7dd7093b@lminiero>
Organization: Meetecho
X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1576667095; bh=8AL6qdPLgZ2xbr485SpAcnRxBt5n3JY5t1cD6PcyanE=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=A8l0tN79rkRO8LXj3TBxVF7nCpzrGLWv1VvuKogB4iQaJIyYk2iolUP/0FHEX/Jtr RzbGAmrC47RODfQDx/tzICBNwzAIyC3cTn5W/G186OXe00ibDnEC3WSGKr9c1O7u3S fGLekpfr7Nk5b63eQDYV8k5ajQ8vT08zJF/3SMxHS1MZVVpAHzXMzmR8do3yadpltK wkuCacw4e9LpDr8JHWBRitiLWwbMLaNibBl6Fr3eNAVRt6441I/ZogDCGcmPZ4LgkA SHWAeh0FEMFf/zAcGySXOKaS0bWMWpCtOhAp4RAJmHShAZNppiRwbWDnGH+StzeOVJ ZauXQPJJDMERA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IgYUYcAZKeNLoKIJR0lU9k8J2RA>
Subject: [MMUSIC] Open source SIP/WebRTC real-time text integration
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: Wed, 18 Dec 2019 11:05:04 -0000
Hi all, as I anticipated in another post, I've recently started working with real-time text: mostly for fun (I've always been intrigued by the protocol), but also because I wanted to get it working with WebRTC, especially in light of its importance for the upcoming NG emergency services. Considering Christer's recent efforts on standardizing how to use RTT on WebRTC, I thought I'd share this here, so that it can hopefully provide a testing framework: it is not complete, and doesn't adhere 100% to the specification yet (more on that in a minute), but I think it might be helpful as a running code reference anyway. Specifically, I've integrated support for real-time text in our open source Janus WebRTC server. Janus is a modular component, and one of the plugins implements a SIP gateway: this is where I implemented support for T.140 and red. The way it works is "straightforward": 1. Any time we get an incoming SIP call on the SIP side with an m=text m-line, we translate that to an m=application, so that we can negotiate data channels on the WebRTC side. 2. At the same time, if the WebRTC peer negotiates an m=application line, we turn that into an m=text section to negotiate real-time text on the SIP side. 3. Then, if we receive T.140 packets from SIP, we relay them via data channels using binary data (we use an Uint8Array in the web application); if we receive RED packets, we parse it in order to get the T.140 blocks we need, and relay those via data channels (since the draft explains redundancy is not needed, thanks to SCTP). 4. When we get T.140 blocks via data channels (which again the web application sends as an Uint8Array), we either send them as they are in RTP packets (if RED was not negotiated), or we create a RED RTP packet with redundant info on previously sent packets (if RED was negotiated instead). This is the effort in a nutshell, and from my simple tests it seems to be working as expected so far. You can find a more comprehensive description of the whole effort in this blog post: https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/ The Janus branch supporting real-time text, instead, is here: https://github.com/meetecho/janus-gateway/pull/1898 As explained in the blog post, the effort is not complete, and there are some things that are either missing, or need to be improved, namely: 1. We're not using the dcmap and dcsa attributes on the WebRTC side yet: the reason is that browsers don't support them, at the moment, and so putting them there may result in the SDP being rejected and the session broken. This means that, currently, we use a default label for exchanging T.140 blocks with the server. 2. While we support RED, we're not using the redundant info for packets we receive yet, and we're not properly handling packet loss or out of order packets yet either. This is something we plan to work on in the future, as I was more interested in getting the specification in general to work first. 3. On the client side in WebRTC, we're not doing any buffering, meaning we send every character as soon as we type it, which is clearly suboptimal. Again, something we plan to fix later on, either in the web application (buffer there), or on the server side (buffer incoming T.140 blocks there, before crafting RTP packets). I hope this will be considered useful, and I'm looking forward to keep on working on this as the specifications moves forward. If you have any questions or doubts, please don't hesitate to ask; besides, I'll be in Vancouver for the next IETF, so in case you want to talk about it in person there, see a demo, or make some interoperability tests, I'll be glad to do that as well. Thanks, Lorenzo -- I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero
- [MMUSIC] Open source SIP/WebRTC real-time text in… Lorenzo Miniero
- Re: [MMUSIC] Open source SIP/WebRTC real-time tex… Christer Holmberg
- Re: [MMUSIC] Open source SIP/WebRTC real-time tex… Lorenzo Miniero
- Re: [MMUSIC] Open source SIP/WebRTC real-time tex… Christer Holmberg