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

Bernard Aboba <> Mon, 13 May 2013 21:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F25EA21F8EB1 for <>; Mon, 13 May 2013 14:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.377
X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cDxFUZFOJzYZ for <>; Mon, 13 May 2013 14:09:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BCCD121F8EA4 for <>; Mon, 13 May 2013 14:09:35 -0700 (PDT)
Received: from BLU169-W46 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 14:09:29 -0700
X-EIP: [nEh+6yKqkQTrrXxT2GAbQ68OcNHa4LMeJPP3kU3D0ns=]
X-Originating-Email: []
Message-ID: <BLU169-W469334EFE43AA7CAAA91FD93A00@phx.gbl>
Content-Type: multipart/alternative; boundary="_6737340a-f5db-486e-9dc7-e284a4fac5f8_"
From: Bernard Aboba <>
To: Gunnar Hellstrom <>, "" <>
Date: Mon, 13 May 2013 14:09:28 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 13 May 2013 21:09:29.0011 (UTC) FILETIME=[27F7B830:01CE501E]
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 21:09:42 -0000

Gunnar said: 
> This could first lead to an effort to route the call to an endpoint that 
> has declared more suitable language and modality preferences and 
> capabilities.
[BA] The call routing aspect is probably best handled via SIP headers, just as in RFC 6442 we define the Geolocation and Geolocation-Routing Headers.   
> Secondly it can lead to addition of a relay service or translation 
> service if one of the parties has access to such services. It can be 
> added in a three-party call fashion, translating languages or modalities 
> as needed.
[BA] The SIP headers might lead to the call being routed to an endpoint that supports the desired servicesnatively, or it might not.  The O/A exchange will disclose whether the desired services are available, or not. It could be that an entity indicating a language capability in its Answer might have them available on site, ormight have to call out to obtain them, but that doesn't matter to the Offerer as long as they can be deliveredby the Answerer.  On the other hand, if the Answerer doesn't have the required services, the Offerer mightdecide to add them on its own, by making another call to a relay or translation service, possibly joining thatcall to the initial one. 
> If the one who is not using the mechanism is declaring audio and text 
> media capabilities, it will be harder to select what to do.
> The one supporting the mechanism may prefer to use sign language. Having 
> no indication why the other party declares video capability, it may be 
> risky to just connect them.
[BA] I agree. Just because a party declares capabilities doesn't necessarily mean that they are able to use them in the manner that is needed.  Just from an indication of the supported media (e.g. video, text, audio) you won't know if the Answerer supports ASL interpretation, or whether they're trained and willing to transcribe audio to text and back. So it's probably best if support for these services is made explicit. 
>    So, yes, there are many use case variations that need to be captured 
> and best approach described.

[BA] It seems to me that what is needed is a set of tools that can be combined in different ways to address the different use cases.  The tools can include SIP headers, SDP negotiation, and call control functionality.  Once you have the tools, you can describe how different use cases can be addressed using them.