Re: [Slim] SDP limitations

Bernard Aboba <bernard.aboba@gmail.com> Sun, 04 October 2015 03:37 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD461B31D4 for <slim@ietfa.amsl.com>; Sat, 3 Oct 2015 20:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=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 cJ3_PIjrX0cm for <slim@ietfa.amsl.com>; Sat, 3 Oct 2015 20:37:05 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84B01B31D3 for <slim@ietf.org>; Sat, 3 Oct 2015 20:37:05 -0700 (PDT)
Received: by pacex6 with SMTP id ex6so142843485pac.0 for <slim@ietf.org>; Sat, 03 Oct 2015 20:37:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=VExJIAXSG5/zLpuzPpvjeBWlX5CEYKpMPR6wzQKl1AI=; b=0cvndvq1WOH+rdH8H8qvZEC8GxFTVwmOzHTzH7/wbTQbkgZmvGkLm70+7rtkdtt2Ru DcJjk/2bS3MliXd7UDon4Gmt1SRpWBLxZE/RfD88pZ/Kx8C2txTMaScfLiObDW3sXN/3 OoPgxHRs3Di82QDgssR7bw18WZLRoz+rsTudUiLkL2+qfKCHqmxd2ezmM5e97BZEq2EW s5bD8vEU5EiixsCE2dmmgm3i/NoAOdfLipGSYhp/G8wbr7nJGtREYWKgMOt6x2/d2UI0 L7eemULII7sJhX0tyX3J3kWZ6BEKhJlN+i8FdfIfJtyF1UTLAyxWrdcHI5Nylwbus0fs /Dbw==
X-Received: by 10.68.57.143 with SMTP id i15mr30859294pbq.104.1443929825323; Sat, 03 Oct 2015 20:37:05 -0700 (PDT)
Received: from [192.168.1.149] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id g5sm20075515pat.21.2015.10.03.20.37.03 for <slim@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 20:37:04 -0700 (PDT)
From: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <48F2AAB3-AD31-401F-92C7-572E49AD5819@gmail.com>
Date: Sat, 03 Oct 2015 20:37:02 -0700
References: <560FA86D.8080201@omnitor.se> <561021A1.4040408@alum.mit.edu>
In-Reply-To: <561021A1.4040408@alum.mit.edu>
To: slim@ietf.org
X-Mailer: iPad Mail (13A452)
Archived-At: <http://mailarchive.ietf.org/arch/msg/slim/h048IAOadbATx1dHQsVASonPrr0>
Subject: Re: [Slim] SDP limitations
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2015 03:37:07 -0000

>> I got a reminder from reviewing the latest specification of real-time
>> text in WebRTC.
>> https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02
>> 
>> There, the real-time text stream is a subchannel multiplexed in the
>> WebRTC data channel, with sdp-specification m=application.
>> So, there is no m=text to hook our humintlang attributes on.

>> It is quite likely that WebRTC terminals will be used in situations
>> where language negotiation is desirable.

[BA] If we are talking about a WEBRTC application talking over the data channel to a gateway that translates to RTT, the gateway can compose the m=text line to hang the humintlang attributes on.  The WEBRTC application need not speak SDP to the gateway to accomplish this, it just needs to provide the information the gateway needs to compose the m=text line and humintlang attributes. This could be in any desired format: JSON, XML, etc.

>> If we keep it under SDP, we would then need to define some mapping rules
>> between languages for media not appearing under their original m= names.

[BA] The gateway would need such a mapping, but it is not clear to me why this application-specific signaling would need to be standardized.