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

Randall Gellens <randy@qti.qualcomm.com> Sat, 16 March 2013 21:55 UTC

Return-Path: <randy@qti.qualcomm.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 6528821F867B for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 14:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level:
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 7XMxdiEY+xqe for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 14:55:17 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05A21F867A for <mmusic@ietf.org>; Sat, 16 Mar 2013 14:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1363470916; x=1395006916; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=+qDZf2m0Zc/bS0uythbbBuHeBWs+Vjfg3houmE9tdx8=; b=K/INVjN4YDujxz8TX2QJpf/fH4lrix6uLca9UMs48QgDF/M9gqv3uCbj /lmzE0TfR1L+5mxEzKjcaaLjyUhS82l0MVaTMsBCw1PsQHBasUPMCx0XY 6yFqhLySsGxaw+gRkFLlIYh7PxY4GIToyaPh0xyCic9DZydnHr2Zz776Q M=;
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="30336300"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 16 Mar 2013 14:55:16 -0700
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="506283920"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Mar 2013 14:55:16 -0700
Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 16 Mar 2013 14:55:15 -0700
Message-ID: <p06240603cd6a994b05ad@dhcp-42ec.meeting.ietf.org>
In-Reply-To: <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com>
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com>
X-Mailer: Eudora for Mac OS X
Date: Sat, 16 Mar 2013 14:54:46 -0700
To: Hadriel Kaplan <HKaplan@acmepacket.com>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
Cc: Randall Gellens <randy@qti.qualcomm.com>, "<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 21:55:18 -0000

At 7:54 PM +0000 3/16/13, Hadriel Kaplan wrote:

>  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.

I'll let Harald speak to this as he was pretty insistent that it was 
a misuse of SDP (if I understood him) to use the same attribute for 
sending and receiving.

>   > 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.

The result of the discussion is to add a token for the caller to 
indicate a preference for the language being mandatory or advisory, 
but the callee is not required to honor this preference.  I can 
imagine scenarios where failing the call might be preferred, such as 
a caller who will call an alternate party if the required language 
isn't supported.

>
>  -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.

No, this is my fault.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter