Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-01

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Mar 2013 08:57:02 -0700

[[[ 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 [email-masked], 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

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.

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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 11 Mar 2013 22:44:47 +0100

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.

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
[email-masked]
+46708204288
On 2013-03-11 16:57, Randall Gellens wrote:
> 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.
>
>
> 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.)
>

---

From: Francois Audet <[email-masked]>
Date: Mon, 11 Mar 2013 22:23:50 +0000

I tought about this a while ago. I guess this is a contact center scenario.

While it would certainly be possible to express your caller pref using q-values, it seems the wrong way to approach the problem. Really, what you want is the caller resource to be of a specific language. Therefore, I think that rather, the URL itself should have the information to map it to the appropriate agent. Kind of similar to 1-800-help-product, 1800-aide-produit, but with a SIP URI. You could use a parameter sip:[email-masked]?lang=en or it could be in the URI itself, SIP:help?example.com/en or SIP:[email-masked].

The calling party would consult the directory and select the desired language. This approach also eliminates the confusing "feature" of having an answer in a different language than you expect...

My 2 cents.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Hellstrom
Sent: Monday, March 11, 2013 2:45 PM
To: [email-masked]
Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02

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 see some complication that might be needed in order to reflect reality. At least they should be discussed.

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:

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)

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.
Description of a possible assisting service and its capabilities and preferences

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
[email-masked]<mailto:[email-masked]>
+46708204288
On 2013-03-11 16:57, Randall Gellens wrote:
[[[ resending without Cc list ]]]

Hi Dale,

 (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 [email-masked]<mailto:[email-masked]>, 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

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.

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.

 - Why SDP and not SIP?

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.

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.

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

     RFC 4566

---

From: Randall Gellens <[email-masked]>
Date: Wed, 13 Mar 2013 19:10:15 -0700

At 10:44 PM +0100 3/11/13, Gunnar Hellstrom wrote:

Before this discussion got its home in
mmusic, we discussed quite similar topics as you, Dale brought up
now.

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.

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.

If you don't care about language for a media stream (e.g., the
video in your example) then simply leave off the language tag when
offering that media.

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.

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)

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 better to have a different mechanism for
requesting services (such as captioned telephony) rather than trying
to pack everything into language.

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.

Description of the calling user and its capabilities and
preferences.

Description of the answering user and its capabilities and
preferences

I agree that the Introduction needs to be made more clear as to
the purpose of the document and the problem it is solving, and the use
cases be more detailed and clear.  I don't know yet if a formal
template is needed or not, but more detailed use cases would be
helpful.

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?

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.

We don't need to refer to it in this document.  It would
refer to this document.

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.

Language and media go together; consider that in the example of
emergency services, not all PSAPs will be capable of accepting all
media.  Smaller PSAPs may have arrangements with larger ones to
handle some forms of media and some languages, or may bridge in third
parties to translate/interpret the media and/or language.  Hence
the use of SDP makes sense for both.

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.

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.

Neither the UE nor the carrier (service provider) should need to
be involved in this.  In the case of emergency services, let the
ESInet handle it; then there is a single entity that needs to be
updated.  In the case of a corporate call center, let the call
center's internal router handle it.  Internally, it may use the
SIP registration mechanism, but that's out of scope of this
document.

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.

I am sorry you won't be here.  There was not time to get
this on the mmusic agenda, so it is an informal lunch meeting on
Thursday at the hotel cafe, hence I do not think any remote
participation, unless one of the people present wants to set up a
laptop with a video call (I am planning to use pen and paper for my
notes).

On 2013-03-11 16:57, Randall Gellens
wrote:

Hi Dale,

(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 [email-masked], 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.

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

But onward to questions of
substance:

- Why SDP and not SIP?

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

And some discussion and comparison
should be done with the SIP/HTTP

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.

stream using ASL.  (But I can see clients using a default value

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

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"

(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

Why shouldn't an answer be able to indicate multiple languages?
At

the least, this might provide the offerer with useful
information.

- Reusing a=lang

"a=lang:...":

RFC 4566

So it looks like "a=lang:..." is entirely unused at
the present and is

safe to be redefined.

_______________________________________________

mmusic mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mmusic

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

We have met the enemy, and he is us.

--Walt Kelly

---

From: Randall Gellens <[email-masked]>
Date: Wed, 13 Mar 2013 19:13:04 -0700

Call centers and emergency services.

I think it would be difficult to get this into a URL parameter.
Also, there may be one language for a voice or text stream (e.g.,
English), and another language for a video stream (e.g., ASL).
Hence, a single parameter may not work because it needs to express
both desired media and desired language.

At 10:23 PM +0000 3/11/13, Francois Audet wrote:

Content-Language: en-US

Content-Type: multipart/alternative;

boundary="_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_"

I tought about this a while ago. I guess
this is a contact center scenario.

While it would certainly be possible to
express your caller pref using q-values, it seems the wrong way to
approach the problem. Really, what you want is the caller resource to
be of a specific language. Therefore, I think that rather, the URL
itself should have the information to map it to the appropriate agent.
Kind of similar to 1-800-help-product, 1800-aide-produit, but with a
SIP URI. You could use a parameter sip:[email-masked]?lang=en
or it could be in the URI itself, SIP:help?example.com/en or SIP:[email-masked].

The calling party would consult the
directory and select the desired language. This approach also
eliminates the confusing "feature" of having an answer in a
different language than you expectŠ

My 2 cents.

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Gunnar
Hellstrom

To: [email-masked]

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

1. Level of preference.

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 )

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

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.

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.

3.  Specify language and modality at SIP Media tag
level instead.

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?

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.

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.

Further, it is often the case that the cost of relay,
interpretation, or translation services is affected by which entity
invokes the service.

4. Problem that 3GPP specifies that it is the UAs only
who specify and act on these parameters.

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.

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.

/Gunnar

Gunnar Hellström

Omnitor

+46708204288

Hi Dale,

(It's not clear to me what the proper mailing list
is to discuss this

started somewhere else.)

(Also, it's not clear why Randall's messages are
coming through in

HTML.)

- Why SDP and not SIP?

And some discussion and comparison should be done
with the SIP/HTTP

language preferences.

hard-of-hearing and requires a voice
stream plus a text stream

appropriate decisions.

have a preference.

- Reusing a=lang

"a=lang:...":

RFC 4566

safe to be redefined.

mmusic mailing list

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

Computers are not intelligent.  They only think they are.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 09:56:53 -0400

> 3841 could be a suitable mechanism for routing and decisions on the 
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

> 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.
>
> 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 
>>>>> "Transmit, receive or both". or   "Produce, perceive or both". 
>>>>> That is easy to understand for the relay service examples.
>>>>> 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 
>>>> specific uses) because it proposes an SDP media attribute, and 
>>> You do not want to turn off incoming audio just because you prefer 
>>> to talk but read text.
>>
>> 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.
>>
>>
>>>>> according to a template. Thast can then be used to test if 
>>>>> proposed approaches will work.
>>>>
>>>>> *There could be some benfits to declare these parameters at the 
>>>>> SIP media tag level instead of SDP level.
>>>> 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.
>>> Yes, convenient. But there is no knowledge about the parameters 
>>> until at call time. It could be better to know the callee 
>>> 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 
> availability and capabilities when they go on duty, and unregister 
> when they stop, so that their information is available at call time.
>
>>
>>>>> *4. Problem that 3GPP specifies that it is the UAs only who 
>>>>> specify and act on these parameters.
>>>>> 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.
>>> service provider for emergency services and the user is registered 
>>> by that service provider. They can make decisions on the call. E.g. 
>> 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.
>
>
>
> 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.
>
>
>
>
>
>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 Mar 2013 07:41:37 -0700

At 9:56 AM -0400 3/14/13, Flemming Andreasen 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.

>>  I see some complication that might be needed 
>> in order to reflect reality. At least they 
>> should be discussed.
>>
>>  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.
>>>
>>> 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 )
>>>
>>
>> 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". 
>>>>>>  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)
>>>>>>  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 
>>>>> 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.
>>>
>> 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.
>>>>>>
>>>>>
>>>>> mean by "structured" in "structured use 
>>>>> case" or "template."  Can you be more 
>>>>> specific?
>>>>>
>>>>>>  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.
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>  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.
>>
>>>
>>>
>>>>>> separate specification of what modality 
>>>>>> the parameters indicate, because the 
>>>>>> language tags only distinguish between 
>>>>>> signed and other languages, and "other" 
>>>>  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.
>>>
>>>>>>  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?
>>>>>>
>>>>>
>>>>> 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 
>>>> 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.
>>>
>> evaluated the alternative possible ends and 
>> decided who has the right capability and 
>> preference.
>>
>>
>>
>> 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 
>> participation on Thursday. I am sorry I am not 
>> there, but would like to participate if 
>> possible.
>>  /Gunnar
>>
>>
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[email-masked]>[email-masked]
>>  +46708204288
>>
>>>>   list is 
>>>> <mailto:[email-masked]>[email-masked], but the 
>>>> first message in this thread about that
>>>  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.
>>>
>>> <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.
>>>
>>>  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.
>>>
>>>  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.
>>>
>>>  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 
>>>  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
>>>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/mmusic>https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>

-------------- Randomly selected tag: ---------------
A diva who specializes in risque arias is an off-coloratura soprano...