IETF Logo Mail Archive

[Slim] SDP limitations

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sat, 03 October 2015 10:05 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 2DF9D1ACEB1 for <slim@ietfa.amsl.com>; Sat, 3 Oct 2015 03:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 rK2-3dTGqW6c for <slim@ietfa.amsl.com>; Sat, 3 Oct 2015 03:05:40 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C2C1ACEB0 for <slim@ietf.org>; Sat, 3 Oct 2015 03:05:39 -0700 (PDT)
X-Halon-ID: 4ae518a9-69b6-11e5-b53c-005056916f53
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <slim@ietf.org>; Sat, 3 Oct 2015 12:05:36 +0200 (CEST)
To: "slim@ietf.org" <slim@ietf.org>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <560FA86D.8080201@omnitor.se>
Date: Sat, 03 Oct 2015 12:05:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/slim/1GnwsuV6Zdm0LPzga9--J_MNNFc>
Subject: [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: Sat, 03 Oct 2015 10:05:42 -0000

The limitations of having the language indications in SDP is eternally 
popping up as a problem when planning its use.
I know that this has been discussed a lot in the past and that we have 
agreed to go the SDP path.

But I want to question it again.
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.
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.
A tempting alternative is to move the whole language indication to an 
XML block carried in a defined place, so that it can be reused in 
different environments.

Gunnar

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

v2.23.0 | Report a Bug | By Email