Re: [MMUSIC] draft-gellens-negotiating-human-language-02

[Randall Gellens <[e-mail]>]

At 9:56 AM -0400 3/14/13, Flemming Andreasen wrote:

>  On 3/11/13 5:44 PM, Gunnar Hellstrom wrote:
>
>>  Before this discussion got its home in mmusic, 
>> we discussed quite similar topics as you, Dale 
>> brought up now.
>>
>>  It was about what was needed to be expressed 
>> by the parameters and if SDP or SIP was the 
>> right place. And in the case of SIP, if RFC 
>> 3840 / 3841 could be a suitable mechanism for 
>> routing and decisions on the parameters.
>>
>  I agree more discussion is needed on this. 
> There seems to be two problems considered in 
> the draft:
>  1) Routing of a request to an answerer that has 
> the language capabilities the caller desires.
>  2) Negotiation of the language properties to 
> use on a per-stream basis once the call has 
> been routed to a particular answerer.
>
>  Problem 1 seems to fall in the RFC 3840/3841 
> space, whereas problem 2 is more of an SDP 
> issue.
>
>  -- Flemming

Language and media both need to be considered 
together when choosing how to process the call. 
For example, a call with a request for video with 
ASL, or text in English, may be handled 
differently than a call that requests only voice 
with English.


>>  Here is part of that discussion that we need to capture.
>>
>>
>>  I see some complication that might be needed 
>> in order to reflect reality. At least they 
>> should be discussed.
>>
>>  And I am also seeing some different ways to specify it.
>>
>>  The complications to discuss are:
>>
>>  1. Level of preference.
>>
>>  There may be a need for specifying levels of 
>> preference for languages.  I might strongly 
>> prefer to talk English, but have some useful 
>> capability in French. I want to display that 
>> preference and that capability with that 
>> difference, so that I get English whenever 
>> possible, but get the call connected even if 
>> English is not available at all but French is.
>>
>>  I would assume that two levels are sufficient, 
>> but that can be discussed:  Preferred and 
>> capable.
>>
>>>
>>>  The draft already proposes that languages be 
>>> listed in order of preference, which should 
>>> handle the example you mention: you list 
>>> English first and French second.  The called 
>>> party selects English if it is capable and 
>>> falls back to French if English is not and 
>>> French is.  This seems much simpler and is a 
>>> common way of handling situations where there 
>>> is a preference.  It would be good to keep 
>>> the mechanism as simple as possible.
>>>
>>>  Yes, I am afraid of complicating this beyond 
>>> the point when users do not manage to get 
>>> their settings right.
>>>
>>>  Still, I do not think that the order is 
>>> sufficient as level of preference indicator. 
>>> You may want to indicate capability for one 
>>> modality but preference for another. ( as my 
>>> example, capability for ASL, but preference 
>>> for talking and reading )
>>>
>>
>>  If you have a capability for ASL but 
>> preference for talking and reading, you could 
>> initially offer two media streams: a voice 
>> with English and a text with English.  If 
>> accepted, you have your preferred 
>> communications.  If those are rejected you 
>> could then offer video with ASL.  Would that 
>> handle the case?
>>  No, video is still very valuable for judging 
>> the emergency case. Or seeing a friend. So, if 
>> you support it you want to offer it. But the 
>> decision on languages and modalities may end 
>> up in video being not important for language 
>> communication.
>>
>>>
>>>
>>>>>>  2. Directionality
>>>>>>  There is a need for a direction of the 
>>>>>> language preference. "Transmit, receive or 
>>>>>> both". or   "Produce, perceive or both". 
>>>>>> That is easy to understand for the relay 
>>>>>> service examples.
>>>>>>  A hard-of-hearing user may declare:
>>>>>>
>>>>>>  Text, capable, produce, English
>>>>>>  Text, prefer, perceive, English
>>>>>>  Audio, prefer, produce, English
>>>>>>  Audio, capable, perceive, English    ( 
>>>>>> tricky, a typical hard-of-hearing user may 
>>>>>> have benefit of receiving audio, while it 
>>>>>> is not usable enough for reliable 
>>>>>> perception. I do not want to see this 
>>>>>> eternally complex, but I see a need for 
>>>>>> refined expressions here)
>>>>>>  video, capable, both, ASL 
>>>>>>
>>>>>>  This should be understood as that the user 
>>>>>> prefers to speak and get text back, and 
>>>>>> has benefit of getting voice in parallel 
>>>>>> with text.  ASL signing can be an 
>>>>>> alternative if the other party has 
>>>>>> corresponding capability or preference.
>>>>>>
>>>>>>
>>>>>
>>>>>  The draft does support this (and even 
>>>>> mentions some of these specific uses) 
>>>>> because it proposes an SDP media attribute, 
>>>>> and media can be specified to be send, 
>>>>> receive, or both.
>>>>>
>>>>  No, that is not the same. You want the media 
>>>> to flow, but by the parameter you want to 
>>>> indicate your preference for how to use it. 
>>>> You do not want to turn off incoming audio 
>>>> just because you prefer to talk but read 
>>>> text.
>>>>
>>>
>>>  Yes, I see, thanks for the clarification. 
>>> Does this need to be part of the session 
>>> setup?  If you establish all media streams 
>>> that you wish to use, can you then just use 
>>> them as you prefer?  I will consult with the 
>>> NENA accessibility committee on this.
>>>
>>  No, there are specific services providing 
>> service with one direction but not the other. 
>> The information is needed for decision on what 
>> assisting service to invoke. One such service 
>> is the captioned telephony, that adds rapidly 
>> created speech-to-text in parallel with the 
>> voice. They provide just that. A user will 
>> have a very strong preference for getting just 
>> that service, but could accept with much lower 
>> preference to get a direct conversation with 
>> the far end in combined text and voice.
>>
>>>
>>>
>>>>>>  I think it would be useful  to move most 
>>>>>> of the introduction to a structured use 
>>>>>> case chapter and express the different 
>>>>>> cases according to a template. Thast can 
>>>>>> then be used to test if proposed 
>>>>>> approaches will work.
>>>>>>
>>>>>
>>>>>  I'm not sure I fully understand what you 
>>>>> mean by "structured" in "structured use 
>>>>> case" or "template."  Can you be more 
>>>>> specific?
>>>>>
>>>>  I mean just a simple template for how the 
>>>> use case descriptions are written.
>>>>
>>>>  E.g.
>>>>  A title indicating what case we have.
>>>>  Description of the calling user and its capabilities and preferences.
>>>>  Description of the answering user and its capabilities and preferences
>>>>  Description of a possible assisting service 
>>>> and its capabilities and preferences
>>>>  Description of the calling user's indications.
>>>>  Description of the answering user's indications.
>>>>  The resulting decision and outcome
>>>>
>>>>>
>>>>>
>>>>>>  3.  Specify language and modality at SIP Media tag level instead.
>>>>>>  There could be some benfits to declare 
>>>>>> these parameters at the SIP media tag 
>>>>>> level instead of SDP level.
>>>>>>  A call center can then register with their 
>>>>>> capabilities already at the SIP REGISTER 
>>>>>> time, and the caller preferences / callee 
>>>>>> capabilities mechanism from RFC 3840/ 3841 
>>>>>> can be used to select modalities and 
>>>>>> languages and route the call to the best 
>>>>>> capable person or combination of person 
>>>>>> and assisting interpreting.
>>>>>>
>>>>>
>>>>>  Maybe, but one advantage of using SDP is 
>>>>> that the ESInet can take language and media 
>>>>> needs into account during policy-based 
>>>>> routing.  For example, in some European 
>>>>> countries emergency calls placed by a 
>>>>> speaker of language x in country y may be 
>>>>> routed to a PSAP in a country where x is 
>>>>> the native language.  Or, there might be 
>>>>> regional or national text relay or sign 
>>>>> language interpreter services as opposed to 
>>>>> PSAP-level capabilities.
>>>>>
>>>>  Is there a complete specification for how 
>>>> policy based routing is thought to work? 
>>>> Where?
>>>>  Does it not use RFC 3840/3841?
>>>>  That procedure is already supported by SIP 
>>>> servers. Using SDP requires new SIP server 
>>>> programming.
>>>>
>>>
>>>  NENA has a document under development.  I 
>>> thought it was able to take SDP into account 
>>> but I'll look into it, and I'm sure Brian 
>>> will have something to say.
>>>
>>  Yes, I think I have seen that. But it needs to 
>> come into IETF to be possible to refer to.
>>
>>>
>>>
>>>>>>  But, on the other hand, then we need a 
>>>>>> separate specification of what modality 
>>>>>> the parameters indicate, because the 
>>>>>> language tags only distinguish between 
>>>>>> signed and other languages, and "other" 
>>>>>> seems to mean either spoken or written 
>>>>>> without any difference.
>>>>>>
>>>>>>
>>>>>
>>>>>  The SDP media already indicates the type (audio, video, text).
>>>>>
>>>>  Yes, convenient. But there is no knowledge 
>>>> about the parameters until at call time. It 
>>>> could be better to know the callee 
>>>> capabilities in advance if available. Then 
>>>> middle boxes can do the routing instead of 
>>>> the far end. There may be many terminals 
>>>> competing for the call and the comparison 
>>>> about who to get it should be done by a sip 
>>>> server instead of an endpoint.
>>>>
>>>
>>>  I think call time is the right time.  For 
>>> emergency calls, it isolates the decision 
>>> making about how to process calls requiring 
>>> text, sign language, foreign language, etc. 
>>> to the ESInet and PSAPs, which is I think the 
>>> right place.  The processing rules in the 
>>> ESInet can then be changed without involving 
>>> any carrier.  The capabilities of an entity 
>>> may vary based on dynamic factors (time of 
>>> day, load, etc.) so the decision as to how to 
>>> support a need may be best made by the ESInet 
>>> or PSAP in the case of an emergency call, or 
>>> called party for non-emergency calls.  For 
>>> example, at some times or under some loads, 
>>> emergency calls may be routed to a specific 
>>> PSAP that is not the geographically indicated 
>>> one.  Likewise, a non-emergency call to a 
>>> call center may be routed to a center in a 
>>> country that has support for the language or 
>>> media needed.
>>>
>>  The decision is of course made at call time. 
>> With the RFC 3840/3841 method, the different 
>> agents and services available register their 
>> availability and capabilities when they go on 
>> duty, and unregister when they stop, so that 
>> their information is available at call time.
>>
>>
>>>
>>>  Further, it is often the case that the cost 
>>> of relay, interpretation, or translation 
>>> services is affected by which entity invokes 
>>> the service.
>>>
>>  Yes, that is a complicating policy issue.
>>
>>>
>>>
>>>>>>  4. Problem that 3GPP specifies that it is 
>>>>>> the UAs only who specify and act on these 
>>>>>> parameters.
>>>>>>  I think it is a problem that 3GPP inserted 
>>>>>> the restriction that the language and 
>>>>>> modality negotiation shall only bother the 
>>>>>> involved UAs.
>>>>>>  It would be more natural that it is a 
>>>>>> service provider between them who detect 
>>>>>> the differences and make the decision to 
>>>>>> invoke a relay service for the relay case.
>>>>>>  How do you propose to solve that? Let the 
>>>>>> service provider behave as a B2BUA, who 
>>>>>> then can behave as both a UA and a service 
>>>>>> provider?
>>>>>>
>>>>>
>>>>>  What do you mean by "service provider?"  In 
>>>>> the case of a voice service provider such 
>>>>> as a cellular carrier or a VoIP provider, I 
>>>>> think this should be entirely transparent. 
>>>>> The voice service provider knows it is an 
>>>>> emergency call and routes to an ESInet.  It 
>>>>> is then up to the ESInet and the PSAPs to 
>>>>> handle the call as they wish.
>>>>>
>>>>  It can be a service provider for just the 
>>>> function to make advanced call invocation 
>>>> based on language preferences. The same type 
>>>> of decisions, call connections and assisting 
>>>> service invocation are needed in everyday 
>>>> calls as in emergency calls. But it can also 
>>>> be a service provider for emergency services 
>>>> and the user is registered by that service 
>>>> provider. They can make decisions on the 
>>>> call. E.g. detect that it is an emergency 
>>>> call requiring interpreter, and therefore 
>>>> connect to both the PSAP and interpreter at 
>>>> the same time to save time.
>>>>
>>>
>>>  I think it's best to make these decisions at 
>>> the end, not the middle.  In the case of 
>>> emergency calls, the ESInet can route to a 
>>> particular PSAP, the PSAP may bridge in 
>>> translation or interpretation services, etc. 
>>> In the case of non-emergency calls, the call 
>>> center may support some capabilities locally 
>>> at some hours but route to a different call 
>>> center at other times.
>>>
>>  The end is not decided until you have 
>> evaluated the alternative possible ends and 
>> decided who has the right capability and 
>> preference.
>>
>>
>>
>>  There is another issue with using sdp for 
>> decisions. SIP Message is included in the set 
>> of methods to handle in emergency calls in RFC 
>> 6443. It can be used within sessions to carry 
>> text messages if other media are used as well. 
>> It is no favored way to have text 
>> communication, but possible. SIP message has 
>> no sdp.  I know that the 3GPP sections  about 
>> emergency calling in TS 22.101 points towards 
>> using MSRP for text messaging, so it should 
>> not be an issue for 3GPP. Can we neglect SIP 
>> Message from the discussion and aim at solving 
>> it only for real-time conversational media?  I 
>> do not urge for solving it for SIP Message, I 
>> just wanted to point out that result by basing 
>> the mechanism on SDP.
>>
>>
>>
>>
>>
>>
>>  Will there be a possibility for remote 
>> participation on Thursday. I am sorry I am not 
>> there, but would like to participate if 
>> possible.
>>  /Gunnar
>>
>>
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>  On 2013-03-11 16:57, Randall Gellens wrote:
>>
>>>  [[[ resending without Cc list ]]]
>>>
>>>  Hi Dale,
>>>
>>>  At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:
>>>
>>>>   (It's not clear to me what the proper mailing list is to discuss this
>>>>   draft.  From the headers of the messages, it appears that the primary
>>>>   list is 
>>>> <mailto:[e-mail]>[e-mail], but the 
>>>> first message in this thread about that
>>>>   draft already has a "Re:" in the subject line, so the discussion
>>>>   started somewhere else.)
>>>>
>>>
>>>  There has been some discussion among those 
>>> listed in the CC header of this message.  I 
>>> think the mmusic list is probably the right 
>>> place to continue the discussion and was 
>>> planning on doing so more formally with the 
>>> next revision of the draft.
>>>
>>>  By the way, the draft was updated and is now 
>>> at -02: 
>>> <http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt>http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt
>>>
>>>  There is a face-to-face discussion Thursday 
>>> 11:30-1:00 at The Tropicale (the cafe in the 
>>> Caribe Royal).  Please let me know if you can 
>>> make it.
>>>
>>>>   (Also, it's not clear why Randall's messages are coming through in
>>>>   HTML.)
>>>>
>>>
>>>  My apologies; I have gotten in the habit when 
>>> replying to messages that have style to allow 
>>> Eudora to send my reply styled as well.
>>>
>>>>   But onward to questions of substance:
>>>>
>>>>   - Why SDP and not SIP?
>>>>
>>>>   I'd like to see a more thorough exploration of why language
>>>>   negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
>>>>   uses the Content-Language header to specify languages.)  In principle,
>>>>   specifying data that may be used in call-routing should be done in the
>>>>   SIP layer, but it's well-accepted in the SIP world that call routing
>>>>   may be affected by the SDP content as well (e.g., media types).
>>>>
>>>
>>>  I think it fits more naturally in SDP since 
>>> the language is related to the media, e.g., 
>>> English for audio and ASL for video.
>>>
>>>>   And some discussion and comparison should be done with the SIP/HTTP
>>>>   Content-Language header (used to specify the language of the
>>>>   communications) and the SIP Accept-Language header (used to specify
>>>>   the language of text components of SIP messages), particularly given
>>>>   that Accept-Language has different set of language specifiers and a
>>>>   richer syntax for specifying preferences.  In any case, preference
>>>>   should be given to reusing one of the existing syntaxes for specifying
>>>>   language preferences.
>>>>
>>>
>>>  I think the semantics of Content-Language and 
>>> Accept-Language are different from the 
>>> semantics here, especially when setting up a 
>>> session with, as an example, an audio stream 
>>> using English and a video stream using ASL. 
>>> (But I can see clients using a default value 
>>> to set both the SDP language attribute and 
>>> the HTTP Content-Language, unless configured 
>>> differently.)
>>>
>>>  As for reusing existing mechanisms, the draft 
>>> does contain two alternative proposals, one 
>>> to re-use the existing 'language' SDP 
>>> attribute, and one to define a new attribute.
>>>
>>>>   - Dependency between media descriptions?
>>>>
>>>>      Another example would be a user who is able to speak but is deaf or
>>>>      hard-of-hearing and requires a voice stream plus a text stream
>>>>      (known as voice carry over).  Making language a media attribute
>>>>      allows the standard session negotiation mechanism to handle this by
>>>>      providing the information and mechanism for the endpoints to make
>>>>      appropriate decisions.
>>>>
>>>>   This scenario suggests that there might be dependency or interaction
>>>>   between language specifications for different media descriptions.
>>>>   Whether this is needed should be determined and documented.
>>>>
>>>>   - Specifying preference levels?
>>>>
>>>>      For example, some users may be able to speak several languages, but
>>>>      have a preference.
>>>>
>>>>   This might argue for describing degrees of preference using "q"
>>>>   parameters (as in the SIP Accept-Language header).
>>>>
>>>>   - Expressing multiple languages in answers
>>>>
>>>>      (While it is true that a conversation among multilingual people
>>>>      often involves multiple languages, it does not seem useful enough
>>>>      as a general facility to warrant complicating the desired semantics
>>>>      of the SDP attribute to allow negotiation of multiple simultaneous
>>>>      languages within an interactive media stream.)
>>>>
>>>>   Why shouldn't an answer be able to indicate multiple languages?  At
>>>>   the least, this might provide the offerer with useful information.
>>>>
>>>
>>>  You raise good questions that I think need 
>>> more discussion.  I am hoping to keep the 
>>> work as simple as possible and not add 
>>> additional complexity, which argues for not 
>>> solving every aspect of the problem, but only 
>>> those that must be solved immediately.
>>>
>>>>
>>>>   - Reusing a=lang
>>>>
>>>>   Searching, I can only find these descriptions of the use of
>>>>   "a=lang:...":
>>>>
>>>>       RFC 4566
>>>>       draft-saintandre-sip-xmpp-chat
>>>>       draft-gellens-negotiating-human-language
>>>>
>>>>   So it looks like "a=lang:..." is entirely unused at the present and is
>>>>   safe to be redefined.
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>  _______________________________________________
>>  mmusic mailing list
>>  <mailto:[e-mail]>[e-mail]
>> 
>> <https://www.ietf.org/mailman/listinfo/mmusic>https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
>  _______________________________________________
>  mmusic mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/mmusic


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A diva who specializes in risque arias is an off-coloratura soprano...