Re: [MMUSIC] Notes from Orlando human language draft discussion

Hadriel Kaplan <HKaplan@acmepacket.com> Sat, 16 March 2013 19:54 UTC

Return-Path: <btv1==78736fa84fe==HKaplan@acmepacket.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 9531921F888B for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 12:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0x4nM+2U7dc for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 12:54:47 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9273521F8788 for <mmusic@ietf.org>; Sat, 16 Mar 2013 12:54:47 -0700 (PDT)
X-ASG-Debug-ID: 1363463686-03fc2172601023790001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id fcTS2B8ngK3igch9 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 15:54:46 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sat, 16 Mar 2013 15:54:46 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Randall Gellens <randy@qti.qualcomm.com>
Thread-Topic: [MMUSIC] Notes from Orlando human language draft discussion
X-ASG-Orig-Subj: Re: [MMUSIC] Notes from Orlando human language draft discussion
Thread-Index: AQHOIoAbfdhuHviRWEioUUIhgvdWNQ==
Date: Sat, 16 Mar 2013 19:54:44 +0000
Message-ID: <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com>
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org>
In-Reply-To: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1B28935EFCE0CD48A06CB7264CA434C8@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363463686
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125382 Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Cc: "<ietf-languages-bounces@alvestrand.no>" <ietf-languages-bounces@alvestrand.no>, "<mmusic@ietf.org>" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 16 Mar 2013 19:55:08 -0000

On Mar 15, 2013, at 2:49 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

> SDP or SIP:
> - Use SDP for actual negotiation, but use SIP header to provide a hint
> - Emergency services use case can use SDP for policy routing/handling decisions
> - Other use cases may or may not have ability/desire to use SDP for this and can use the SIP header hint

Another reason not to only put it in SDP is the delayed-offer scenario.


> Directionality of SDP attributes:
> - Define two new SDP media-level attributes: 'send-lang' and 'recv-lang'.  In an offer, send-lang is a list in preference order of the languages the offerer wishes to send and recv-lang is a list in preference order of the languages the offerer wishes to receive.  In most cases these are expected to have the same value, because otherwise it is harder to match desired resources.  In an answer, send-lang is the accepted language the answerer will send (which in most cases should be one of the languages in the offer's recv-lang) and recv-lang is the accepted language the answerer expects to receive (which in most cases should be one of the languages in the offer's send-lang).

What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.


> Advisory vs Required:
> - Does call fail if no common language?

I haven't thought about this draft's scenarios much, but think we need to think about this very carefully.  Otherwise the outcome would be SBCs would strip it from the INVITE, just to avoid failing the call.  I don't think anyone would actually want such calls to truly fail for the end user - not just for Emergency calls, but for any calls - people can always hang up if they don't like what they hear/see.  ISTM that there's a high likelihood of this language value actually being *wrong* in either the sender or receiver or both, so I think failing the call because of a mismatch would be really bad.

At first glance, I can see one and only one reason failing it would make sense: for a serial-forking proxy/B2BUA/UA to be able to recurse to alternate targets if the first one didn't support the language(s).  But it has a very negative drawback: if there are no more targets it can recurse to, or if there were no such forking to begin with, the call fails.  Then we're back to square one above, and the thing gets removed from all calls by middleboxes, just to avoid such cases.

-hadriel
p.s. was this presented in MMUSIC this past week?  For some reason this topic was neither on the MMUSIC agenda pages (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in the meeting materials (https://datatracker.ietf.org/meeting/86/materials.html), nor is the draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  I only mention this because I was looking for the slides and draft today and didn't find them.