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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 July 2013 18:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 A51D221F9D9D for <mmusic@ietfa.amsl.com>; Thu, 11 Jul 2013 11:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.147
X-Spam-Level:
X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 MiR7OI5ILj8p for <mmusic@ietfa.amsl.com>; Thu, 11 Jul 2013 11:36:20 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id D5D7F21F9D39 for <mmusic@ietf.org>; Thu, 11 Jul 2013 11:36:19 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id z2w81l0090vyq2s5E6cJRb; Thu, 11 Jul 2013 18:36:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id z6cJ1l00q3ZTu2S3R6cJYp; Thu, 11 Jul 2013 18:36:18 +0000
Message-ID: <51DEFB22.4090802@alum.mit.edu>
Date: Thu, 11 Jul 2013 14:36:18 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: mmusic@ietf.org
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com> <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <p06240615cdfea836f364@[99.111.97.136]> <51DBB813.4060607@nteczone.com> <p0624060ece02360a322d@[99.111.97.136]> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51DE43FC.6080508@omnitor.se>
In-Reply-To: <51DE43FC.6080508@omnitor.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373567779; bh=Vm8pLnqqAhFQro5zj2xehagtAMOKFDnvOvbHOsisk5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QNe+ruI/CpxTY8iCFmBWTSwBEEwtVurvNWa13O3cRE2XpNxgzjx3GD5OQqQJZjh75 XUqL0A0ZLeqD5J1ZDXqNttWLdQ4e7Alafz9XYud9u3yIJykHSWVBoVfjGfbWqEzC0r J1AxSuTUWhyLkqwWAObECDEBgUe85zusEoHTh1PFSvZW8sf9cznd3ddV172+Dd9MbI Bn8N08xAKTpqyxo/64ukgxCsSfEO8qLomKXi4wWnGOBYc1NYq+G0AqwaRenvOiPmZ/ odeTrVD1VoELZG8Z713JFWg5kmWHqW3HJiHAG3SLkaerzsjReGgxZABsyRCz4qsywT YQPlQ797Br0RA==
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: Thu, 11 Jul 2013 18:36:24 -0000

On 7/11/13 1:34 AM, Gunnar Hellstrom wrote:
> On 2013-07-10 06:49, Christian Groves wrote:
>> I wouldn't have thought that it would be use case specific... i.e. i'd
>> only include my language when I called an emergency service. I would
>> think an endpoint would be configured with the information and then
>> provide it whenever I made a call. Is that the intent?
>>
>> Christian
> Yes, that is the intent.
>
> And for both relay service invocation and any other assisting service
> invocation, it is best for the user to dial the destination, and get the
> assisting service invoked by an indication like this in the call, rather
> than being forced to first call an assisting service and with them
> discuss who is the final destination of the call.

Viewed this way, it is similar to recognizing the need for, and 
recruiting, a transcoder. (See RFCs 5369 & 5370.)

	Thanks,
	Paul

> The other party in the call may be another user, a call center, an
> emergency service or a conference bridge.
>
> Gunnar
>
>>
>> On 10/07/2013 9:23 AM, Gunnar Hellstrom wrote:
>>> On 2013-07-09 23:58, Randall Gellens wrote:
>>>> This is a different, and more complex, scenario than what this
>>>> proposal is trying to solve.  This proposal is focused on simpler
>>>> cases where someone places an emergency call or calls a corporate
>>>> call center.  Possibly this can be just a simple case of the more
>>>> complex cases?
>>> My view is that it is intended to also cover user-to-user cases,
>>> where preferences are compared and a relay service (or language
>>> interpreter) can be invoked to bridge language gaps.
>>>
>>> Gunnar
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>