Subject: [Slim] Notes from lunch?

From: Eric Burger <[email-masked]>
Date: Tue, 21 Jul 2015 13:44:50 -0400

Inquiring minds want to know...

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Jul 2015 09:46:54 +0200

I can give you the bottom line, which is really a summary of what transpired in ecrit and in the meeting at lunch:

We’re going to do negotiation of media (“labeling”) first, and recharter for signaling, with discussion of signaling allowed now.
We’ll pull all the routing text out of the real-time draft.
We will explicitly limit to the 80% cases, and we will document use cases in a work group wiki.  We’re not going to try to cover corner cases.

Brian

> On Jul 21, 2015, at 7:44 PM, Eric Burger <[email-masked]> wrote:
> 
> Inquiring minds want to know..._______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2015 04:03:54 -0400

> We will explicitly limit to the 80% cases, and we will document use cases in a work group wiki.  We’re not going to try to cover corner cases.

What does that mean? What is and isn't a corner case?

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Jul 2015 10:22:28 +0200

Two examples:
PSAPs engaging a French language translation service - in scope

I prefer ASL video, with english text, I could handle spanish text (only), but if all you can handle is French text + audio, then I need ASL to english audio translated to French, plus French text - corner case.

I assume work group consensus would determine if a given proposed use case is a corner case or not.

Brian

> On Jul 22, 2015, at 10:03 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jul 2015 04:24:30 -0400

We talked about some examples of cases as being "center" and "corner":

(1) "center": customer trying to indicate that they prefer to speak Spanish
when contacting call center;
caller indicating preference for ASL when calling an emergency number

(2) "corner": simultaneous interpretation case where somebody wants to
receive both Spanish and English; complex ordering of preferences ("I am a
native speaker of English; fluent in Spanish and can read a menu in
Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate my
preference for English, Spanish and Swedish as 9, 7 and 3.5")

There's obviously no problem if the corner case happens to work, but no
extra effort (syntax, complexity) will be expended to make them work. The
center-corner cut-off may also differ for routing and intra-UAS (SDP) cases
since it seems reasonable to assume that routing is more coarse-grained and
has less information about the current (right now), precise capabilities of
the end point.

Henning

On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat <[email-masked]> wrote:

>  We will explicitly limit to the 80% cases, and we will document use cases
>> in a work group wiki.  We’re not going to try to cover corner cases.
>>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Jul 2015 10:52:23 +0200

Can we agree to include this proposed requirements chapter and from this 
proposal identify what should be added or deleted to get the center 
cases included and the corner cases either excluded or just enabled by 
chance? ( a few excluded corner cases are listed in the last subsection.)
I have not changed the chapter after the discussion about coordination 
of languages and modalities in different streams that Paul introduced. I 
am not sure about if that discussion belongs here or not.

-----------------------------------

X. Requirements.
------------------------
The system for indication of preferences and capabilities shall meet the 
following requirements:

It shall enable negotiation of media, modalities and languages for a SIP 
session.

It shall be possible to use it during initiation and modification of a 
session.

The system shall consist of a set of indications and usage rules 
specified in this specification and other specifications.

The system shall enable a caller to indicate the media, modalities, 
languages and assisting services that the caller prefers to use during a 
real-time session that is about to be established or modified.

Entities involved in selecting callees and callees shall be enabled to 
view the caller preferences in order to select a callee of many, or 
adjust the set of media, modalities, languages and services provided in 
the session.

The caller shall be provided with indication of the resulting media, 
modalities, languages and services enabled during the session.

X.1 General
------------
It shall be possible to express capabilities and preferences with its 
transmission direction, for transmission or reception or bidirectional 
from the viewpoint of the entity sending the indication.

The indications shall be suitable for setting in personal profiles, in 
service profiles, or in terminal settings, and possible to adjust at 
session initiation time.

It shall be possible to present the outcome of exchange of the 
indications to users in the session.

X.2 Media indications.
-------------------------

It shall be possible to use the indications for audio, video and 
real-time text media.  ( and text messages????)

X.3 Modality indications.
----------------------------
It shall be possible to use indications for speech and hearing in audio 
media.

It shall be possible to use indications for transmitting text and 
receiving text in real-time text media.

( ???  It shall be possible to use indications for transmitting text 
messages and receiving text messages in text messaging media. ???)

It shall be possible to use indications for expressing sign language and 
perceiving sign language in video media.

It shall be possible to use indications for showing a speaker and for 
seeing a speaker in video media.

X.4 Service indications.
--------------------------
It shall be possible to use indications of type of and address of and 
state of invocation of an assisting service available for supporting the 
communication.

X.5 Language indications.
-----------------------------
It shall be possible to indicate ability to express language in a number 
of languages from the ones listed in the language tags of RFC 5646.

It shall be possible to indicate ability to perceive language in a 
number of languages from the ones listed in the language tags of RFC 5646.

The language indication shall be associated with a specific media, 
modality and direction.

It shall be possible to indicate ability to express language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate ability to perceive language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate use of media without any specific 
intention to use the medium for language communication.

X.6 Indication of level of preference or capability
--------------------------------------------------------
It shall be possible to indicate an absolute level of preference or 
capability to use a language, modality, media and direction combination 
with a coarse grading.
For preference, the grading shall at least be able to indicate strong 
preference vs can use vs possible fall back usage.
For capability, the grading shall at least be able to indicate good 
capability vs some capability vs limited capability.
Capability and preference shall use the same coding, the difference is 
only in the role of the entity providing the indication. Call parties 
express preferences, service providers express capabilities.

More than one direction/media/modality/language preference or capability 
can be expressed per level.

It shall be possible for a caller to express if the session should be 
set up or not if no matching direction/media/modality/language 
indications are found.

X.7 Type and quality indications
-------------------------------------
It shall be possible to indicate preference and capability of different 
types of real-time text production: conversational type versus 
captioning type. Conversational type is generated by the transmitting 
party in the session, or by a communications agent with moderate 
requirements on delay. Captioning type is generated as captions to 
another modality in the same session with low delay from the expression 
in the other modality. The original modality for captions can be speech 
or sign language.

It shall be possible to indicate with language indications if it is 
original or interpreted or artificially created contents.

In order to enable communication with persons who have speech that is 
weak or hard to understand, the following quality indications can be used:
     -It shall be possible to indicate that the quality of the expressed 
speech makes it hard to understand.
     -It shall be possible to indicate a capability to undertand speech 
that is weak or hard to understand.

In order to enable communication with persons who need cognitive support 
in the form of reminders or notetaking, the following quality 
indications can be used:
     -It shall be possible to indicate need of reminders or notetaking 
during a session.
     -It shall be possible to indicate a capability to provide reminders 
or take notes during a session.

X.8 Details of service indications
----------------------------------------
The user expressing the indications may be a frequent user of an 
assisting service, that supports the commuication in some often 
occurring need for modality or language translation. By indicating this 
service, a receiver of the indication can judge if invocation of that 
service will support matching of preferences and capabilities. Common 
assiting service types are relay service and language translation service.

The services are specified with service type, service address, 
invocation state and languages.
Possible service types are:
     Spoken language translation service translating between different 
spoken languages.
     Video relay service translating between sign language in video and 
speech in audio.
     Text relay service translating between text in real-time text and 
speech in audio.  ( even between text messages and audio exist )
     Captioned telephony adding real-time text in one direction to speech.
     Speech-to-speech adding clear speech when needed to speech that is 
weak or hard to understand
     Cognitive support adding reminders or memory notes to speech 
conversation ususlly in combination with the speech-to-speech service.

Service address shall be a URI where the service can be reached with one 
session for provision of the service within the media of that session.
(note that this is different from how most current relay services today 
work. They often have two call legs, one with an audio call and one with 
a multimedia call. )

Invocation state shall indicate if the service is already included in 
the call, and if so, the media/modality/language indications show the 
joint capabilities.
Invocation state can also contain a request to the other party to invoke 
the service if needed to complement the capabilities to achieve a 
functioning communication. This indication can be provided either by the 
offering or answering party.

Languages shall be media/modality/language indications in pairs showing 
the capabilities of the service.

X.9 Use in session establishment and modification
-------------------------------------------------------------
The indications shall be included in session offer / answer exchange.

Already specified ways to express media/modality/language shall be 
possible to use to the extent that they are usable.
That includes media and language tags on SIP level and media 
specifications and language tags on SDP level. For cases when these 
existing means imply limitations, these limitations shall be explained.

The method for identification of language preferences and capabilities 
in this specification is intended mainly for rapid ad-hoc session 
establishment and not intended to have the same ambitions as CLUE has 
for planned telepresence sessions.

The indications included in the offer shall represent the preferences 
and capabilities of the offering party.

The indications included in the answer shall represent the preferences 
and capabilities of the answering party actually planned to be used in 
the session.

X.10 Security
-----------
It shall be possible to hide the preference and capability indications 
from unintended inspection.

X.11 Not covered characteristics
------------------------------------
Many aspects of a conversation are not covered by the indications 
specified here.
Examples are:
     Gender
     Expertize area

--------------------------------------

/Gunnar

Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
> (1) "center": customer trying to indicate that they prefer to speak 
> Spanish when contacting call center;
> receive both Spanish and English; complex ordering of preferences ("I 
> am a native speaker of English; fluent in Spanish and can read a menu 
> in Swedish"; "I can understand (orally) Latin, but not speak it"; "I 
> rate my preference for English, Spanish and Swedish as 9, 7 and 3.5")
>
> There's obviously no problem if the corner case happens to work, but 
> no extra effort (syntax, complexity) will be expended to make them 
> work. The center-corner cut-off may also differ for routing and 
> intra-UAS (SDP) cases since it seems reasonable to assume that routing 
> is more coarse-grained and has less information about the current 
> (right now), precise capabilities of the end point.
>
> Henning
>
> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         We will explicitly limit to the 80% cases, and we will
>         document use cases in a work group wiki.  We’re not going to
>         try to cover corner cases.
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Jul 2015 10:59:03 +0200

I’m not in favor of this.

I think it’s too complex; way, way too complex.

Brian

> On Jul 22, 2015, at 10:52 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Can we agree to include this proposed requirements chapter and from this proposal identify what should be added or deleted to get the center cases included and the corner cases either excluded or just enabled by chance? ( a few excluded corner cases are listed in the last subsection.)
> I have not changed the chapter after the discussion about coordination of languages and modalities in different streams that Paul introduced. I am not sure about if that discussion belongs here or not. 
> 
> The system for indication of preferences and capabilities shall meet the following requirements: 
> 
> It shall enable negotiation of media, modalities and languages for a SIP session. 
> 
> It shall be possible to use it during initiation and modification of a session. 
> 
> The system shall consist of a set of indications and usage rules specified in this specification and other specifications. 
> 
> The system shall enable a caller to indicate the media, modalities, languages and assisting services that the caller prefers to use during a real-time session that is about to be established or modified. 
> 
> Entities involved in selecting callees and callees shall be enabled to view the caller preferences in order to select a callee of many, or adjust the set of media, modalities, languages and services provided in the session. 
> 
> The caller shall be provided with indication of the resulting media, modalities, languages and services enabled during the session. 
> 
> X.1 General 
> ------------ 
> It shall be possible to express capabilities and preferences with its transmission direction, for transmission or reception or bidirectional from the viewpoint of the entity sending the indication. 
> 
> The indications shall be suitable for setting in personal profiles, in service profiles, or in terminal settings, and possible to adjust at session initiation time. 
> 
> It shall be possible to present the outcome of exchange of the indications to users in the session. 
> 
> X.2 Media indications. 
> It shall be possible to use the indications for audio, video and real-time text media.  ( and text messages????) 
> 
> It shall be possible to use indications for speech and hearing in audio media. 
> 
> It shall be possible to use indications for transmitting text and receiving text in real-time text media. 
> 
> ( ???  It shall be possible to use indications for transmitting text messages and receiving text messages in text messaging media. ???) 
> 
> It shall be possible to use indications for expressing sign language and perceiving sign language in video media. 
> 
> It shall be possible to use indications for showing a speaker and for seeing a speaker in video media. 
> 
> X.4 Service indications. 
> It shall be possible to use indications of type of and address of and state of invocation of an assisting service available for supporting the communication. 
> 
> It shall be possible to indicate ability to express language in a number of languages from the ones listed in the language tags of RFC 5646. 
> 
> It shall be possible to indicate ability to perceive language in a number of languages from the ones listed in the language tags of RFC 5646. 
> 
> The language indication shall be associated with a specific media, modality and direction. 
> 
> It shall be possible to indicate ability to express language in an unspecified language, meaning a default for a region in the associated modality. 
> 
> It shall be possible to indicate ability to perceive language in an unspecified language, meaning a default for a region in the associated modality. 
> 
> It shall be possible to indicate use of media without any specific intention to use the medium for language communication. 
> 
> It shall be possible to indicate an absolute level of preference or capability to use a language, modality, media and direction combination with a coarse grading. 
> For preference, the grading shall at least be able to indicate strong preference vs can use vs possible fall back usage. 
> For capability, the grading shall at least be able to indicate good capability vs some capability vs limited capability. 
> Capability and preference shall use the same coding, the difference is only in the role of the entity providing the indication. Call parties express preferences, service providers express capabilities.     
> 
> More than one direction/media/modality/language preference or capability can be expressed per level. 
> 
> It shall be possible for a caller to express if the session should be set up or not if no matching direction/media/modality/language indications are found. 
> 
> It shall be possible to indicate preference and capability of different types of real-time text production: conversational type versus captioning type. Conversational type is generated by the transmitting party in the session, or by a communications agent with moderate requirements on delay. Captioning type is generated as captions to another modality in the same session with low delay from the expression in the other modality. The original modality for captions can be speech or sign language. 
> 
> It shall be possible to indicate with language indications if it is original or interpreted or artificially created contents. 
> 
> In order to enable communication with persons who have speech that is weak or hard to understand, the following quality indications can be used: 
>     -It shall be possible to indicate that the quality of the expressed speech makes it hard to understand. 
>     -It shall be possible to indicate a capability to undertand speech that is weak or hard to understand. 
> 
> In order to enable communication with persons who need cognitive support in the form of reminders or notetaking, the following quality indications can be used: 
>     -It shall be possible to indicate need of reminders or notetaking during a session. 
>     -It shall be possible to indicate a capability to provide reminders or take notes during a session. 
> 
> 
> The user expressing the indications may be a frequent user of an assisting service, that supports the commuication in some often occurring need for modality or language translation. By indicating this service, a receiver of the indication can judge if invocation of that service will support matching of preferences and capabilities. Common assiting service types are relay service and     language translation service. 
> 
> The services are specified with service type, service address, invocation state and languages. 
>     Spoken language translation service translating between different spoken languages. 
>     Video relay service translating between sign language in video and speech in audio. 
>     Text relay service translating between text in real-time text and speech in audio.  ( even between text messages and audio exist ) 
>     Speech-to-speech adding clear speech when needed to speech that is weak or hard to understand 
>     Cognitive support adding reminders or memory notes to speech conversation ususlly in combination with the speech-to-speech service. 
> 
> Service address shall be a URI where the service can be reached with one session for provision of the service within the media of that session. 
> (note that this is different from how most current relay services today work. They often have two call legs, one with an audio call and one with a multimedia call. ) 
> 
> Invocation state shall indicate if the service is already included in the call, and if so, the media/modality/language indications show the joint capabilities. 
> Invocation state can also contain a request to the other party to invoke the service if needed to complement the capabilities to achieve a functioning communication. This indication can be provided either by the offering or answering party. 
> 
> Languages shall be media/modality/language indications in pairs showing the capabilities of the service. 
> 
> 
> Already specified ways to express media/modality/language shall be possible to use to the extent that they are usable. 
> That includes media and language tags on SIP level and media specifications and language tags on SDP level. For cases when these existing means imply limitations, these limitations shall be explained. 
> 
> The method for identification of language preferences and capabilities in this specification is intended mainly for rapid ad-hoc session establishment and not intended to have the same ambitions as CLUE has for planned telepresence sessions. 
> 
> The indications included in the offer shall represent the preferences and capabilities of the offering party. 
> 
> The indications included in the answer shall represent the preferences and capabilities of the answering party actually planned to be used in the session. 
> 
> 
> 
> X.10 Security 
> ----------- 
> It shall be possible to hide the preference and capability indications from unintended inspection. 
> 
> Many aspects of a conversation are not covered by the indications specified here. 
> Examples are: 
>     Gender 
>     Expertize area 
> 
>> (1) "center": customer trying to indicate that they prefer to speak Spanish when contacting call center;
>> (2) "corner": simultaneous interpretation case where somebody wants to receive both Spanish and English; complex ordering of preferences ("I am a native speaker of English; fluent in Spanish and can read a menu in Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate my preference for English, Spanish and Swedish as 9, 7 and 3.5")
>> 
>> There's obviously no problem if the corner case happens to work, but no extra effort (syntax, complexity) will be expended to make them work. The center-corner cut-off may also differ for routing and intra-UAS (SDP) cases since it seems reasonable to assume that routing is more coarse-grained and has less information about the current (right now), precise capabilities of the end point.
>> 
>> Henning
>> 
>> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jul 2015 05:32:54 -0400

I agree; I think this is too prescriptive. The goal is much simpler: Allow
the caller to provide enough information so that proxy/UA/SBC/PSAP etc. can
make good decisions on what to do. Generally, attempts to tell these
entities *how* to do things or exactly what to do is both likely to be
ignored and generate unbounded complexity. We went a small distance down
that path before, in caller preferences, and the result was not pretty.
That effort actually tried to come up with a formal logic, rather than a
compilation of ad-hoc cases, but even that led to too many cases to make
them practical to implement. Been there, done that, have the T-shirt.

We generally don't need to do this - we don't have generic components in
most of the cases of the interest (PSAP, call center, conferencing systems,
etc.), but components that, by their nature, have a fair amount of
domain-specific knowledge, such as policies about how to handle ASL calls,
when and how to bridge in interpreters, who gets what kind of language
assistance, etc.  (To be sure, the physical components such as SIP proxies
may be generic, but they have been programmed to operate in a specific
policy environment, i.e., they turn into an ESRP or PBX/ACD.)

These entities essentially need to know "which of my well-known
customer/caller classes is this" and then trigger one of a very small
number of behaviors that are programmed ahead of time. This is, among other
reasons, the only way that you can test systems. And all of our target
systems are high-reliability, can't-fail systems, even if they are not
life-safety systems.

Also, in many cases, they may define profiles for users out-of-band. For
example, they are likely to define special roles for call takers, language
interpreters, managers (who need to monitor calls for quality assurance),
loggers, etc. These roles trigger behavior, not the signaling or SDP.

We are not specifying a programming language here.

Henning

On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen <[email-masked]> wrote:

> proposal identify what should be added or deleted to get the center cases
> included and the corner cases either excluded or just enabled by chance? (
> a few excluded corner cases are listed in the last subsection.)
> I have not changed the chapter after the discussion about coordination of
> languages and modalities in different streams that Paul introduced. I am
> not sure about if that discussion belongs here or not.
>
> The system shall consist of a set of indications and usage rules specified
> in this specification and other specifications.
>
> view the caller preferences in order to select a callee of many, or adjust
> the set of media, modalities, languages and services provided in the
> session.
>
> transmission direction, for transmission or reception or bidirectional from
> the viewpoint of the entity sending the indication.
>
> It shall be possible to indicate ability to perceive language in a number
> It shall be possible for a caller to express if the session should be set
> up or not if no matching direction/media/modality/language indications are
> found.
>
> types of real-time text production: conversational type versus captioning
> type. Conversational type is generated by the transmitting party in the
> session, or by a communications agent with moderate requirements on delay.
> Captioning type is generated as captions to another modality in the same
> session with low delay from the expression in the other modality. The
> original modality for captions can be speech or sign language.
>
> In order to enable communication with persons who have speech that is weak
> or hard to understand, the following quality indications can be used:
> in the form of reminders or notetaking, the following quality indications
> can be used:
> The user expressing the indications may be a frequent user of an assisting
> service, that supports the commuication in some often occurring need for
> modality or language translation. By indicating this service, a receiver of
> the indication can judge if invocation of that service will support
> matching of preferences and capabilities. Common assiting service types are
> relay service and language translation service.
>
> work. They often have two call legs, one with an audio call and one with a
> multimedia call. )
>
> Invocation state shall indicate if the service is already included in the
> call, and if so, the media/modality/language indications show the joint
> capabilities.
> The method for identification of language preferences and capabilities in
> this specification is intended mainly for rapid ad-hoc session
> establishment and not intended to have the same ambitions as CLUE has for
> planned telepresence sessions.
>
> The indications included in the answer shall represent the preferences and
> capabilities of the answering party actually planned to be used in the
> session.
>
>
>
> X.10 Security
> -----------
>>  We will explicitly limit to the 80% cases, and we will document use
>>> cases in a work group wiki.  We’re not going to try to cover corner cases.
>>>
>>
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Jul 2015 21:46:42 +0200

If the requirements I proposed were too complex, can we then get 
proposals for what to delete from them.

Compared to the current real-time SLIM draft, I can see the following 
differences:

X.4 Service indications is added. I did that because of two issues: 1. 
the problem of describing a couple of types of relay service users in 
language and modality preference terms, and therefore instead providing 
the opportunity to tell what kind of relay service the user is a regular 
user of. 2. The problem in a multi-national, multi-language situation 
for an answering part to know how to find a suitable assisting service 
to invoke, and therefore introducing a service hint in the coding.

X.6 Priority. I suggest another priority indication than the current 
draft. The current draft has just priority within each medium, while I 
see a need for priority levels between media. Instead I suggest only 
three priority levels instead of the draft now specifying an unlimited 
positional order of priority within each medium.

X.7 The type and quality indications were added, inspired by the 
discussion mainly from the e-mail draft discussion.

X.8 is details of the service indications, briefly introduced in X.4.

The requirements aim at allowing quite general terminals, e.g. using 
IMS, call services that may be located in other countries having no 
previous business agreement, such as an IMS user from one country 
visiting another country and calling emergency services there.

Is that to hope too much? Do you suggest that persons with specific 
other modality needs than two-way speech will always need to be 
registered with service providers who are devoted to their needs?

Or can you propose a subset of the requirements that correspond to the 
central cases?

Gunnar

Den 2015-07-22 kl. 11:32, skrev Henning Schulzrinne:
> I agree; I think this is too prescriptive. The goal is much simpler: 
> Allow the caller to provide enough information so that 
> proxy/UA/SBC/PSAP etc. can make good decisions on what to do. 
> Generally, attempts to tell these entities *how* to do things or 
> exactly what to do is both likely to be ignored and generate unbounded 
> complexity. We went a small distance down that path before, in caller 
> preferences, and the result was not pretty. That effort actually tried 
> to come up with a formal logic, rather than a compilation of ad-hoc 
> cases, but even that led to too many cases to make them practical to 
> implement. Been there, done that, have the T-shirt.
>
> We generally don't need to do this - we don't have generic components 
> in most of the cases of the interest (PSAP, call center, conferencing 
> systems, etc.), but components that, by their nature, have a fair 
> amount of domain-specific knowledge, such as policies about how to 
> handle ASL calls, when and how to bridge in interpreters, who gets 
> what kind of language assistance, etc.  (To be sure, the physical 
> components such as SIP proxies may be generic, but they have been 
> programmed to operate in a specific policy environment, i.e., they 
> turn into an ESRP or PBX/ACD.)
>
> number of behaviors that are programmed ahead of time. This is, among 
> other reasons, the only way that you can test systems. And all of our 
> target systems are high-reliability, can't-fail systems, even if they 
> are not life-safety systems.
>
> Also, in many cases, they may define profiles for users out-of-band. 
> For example, they are likely to define special roles for call takers, 
> language interpreters, managers (who need to monitor calls for quality 
> assurance), loggers, etc. These roles trigger behavior, not the 
> signaling or SDP.
>
> On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     On Jul 22, 2015, at 10:52 AM, Gunnar Hellström
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Can we agree to include this proposed requirements chapter and
>>     from this proposal identify what should be added or deleted to
>>     get the center cases included and the corner cases either
>>     excluded or just enabled by chance? ( a few excluded corner cases
>>     are listed in the last subsection.)
>>     I have not changed the chapter after the discussion about
>>     coordination of languages and modalities in different streams
>>     that Paul introduced. I am not sure about if that discussion
>>     belongs here or not.
>>
>>     The system shall enable a caller to indicate the media,
>>     modalities, languages and assisting services that the caller
>>     prefers to use during a real-time session that is about to be
>>     established or modified.
>>
>>     Entities involved in selecting callees and callees shall be
>>     enabled to view the caller preferences in order to select a
>>     callee of many, or adjust the set of media, modalities, languages
>>     and services provided in the session.
>>
>>     The caller shall be provided with indication of the resulting
>>     media, modalities, languages and services enabled during the
>>     session.
>>
>>     X.1 General
>>     ------------
>>     It shall be possible to express capabilities and preferences with
>>     its transmission direction, for transmission or reception or
>>     bidirectional from the viewpoint of the entity sending the
>>     indication.
>>
>>     The indications shall be suitable for setting in personal
>>     profiles, in service profiles, or in terminal settings, and
>>     possible to adjust at session initiation time.
>>
>>     ( ???  It shall be possible to use indications for transmitting
>>     text messages and receiving text messages in text messaging
>>     media. ???)
>>
>>     It shall be possible to use indications for expressing sign
>>     language and perceiving sign language in video media.
>>
>>     It shall be possible to use indications of type of and address of
>>     and state of invocation of an assisting service available for
>>     supporting the communication.
>>
>>     It shall be possible to indicate ability to express language in a
>>     It shall be possible to indicate ability to perceive language in
>>     a number of languages from the ones listed in the language tags
>>     of RFC 5646.
>>
>>     It shall be possible to indicate ability to express language in
>>     an unspecified language, meaning a default for a region in the
>>     associated modality.
>>
>>     It shall be possible to indicate ability to perceive language in
>>     an unspecified language, meaning a default for a region in the
>>     associated modality.
>>
>>     It shall be possible to indicate use of media without any
>>     specific intention to use the medium for language communication.
>>
>>     It shall be possible to indicate an absolute level of preference
>>     or capability to use a language, modality, media and direction
>>     combination with a coarse grading.
>>     For preference, the grading shall at least be able to indicate
>>     strong preference vs can use vs possible fall back usage.
>>     For capability, the grading shall at least be able to indicate
>>     good capability vs some capability vs limited capability.
>>     Capability and preference shall use the same coding, the
>>     difference is only in the role of the entity providing the
>>     indication. Call parties express preferences, service providers
>>     express capabilities.
>>
>>     It shall be possible for a caller to express if the session
>>     should be set up or not if no matching
>>     direction/media/modality/language indications are found.
>>
>>     It shall be possible to indicate preference and capability of
>>     different types of real-time text production: conversational type
>>     versus captioning type. Conversational type is generated by the
>>     transmitting party in the session, or by a communications agent
>>     with moderate requirements on delay. Captioning type is generated
>>     as captions to another modality in the same session with low
>>     delay from the expression in the other modality. The original
>>     modality for captions can be speech or sign language.
>>
>>     It shall be possible to indicate with language indications if it
>>     is original or interpreted or artificially created contents.
>>
>>     In order to enable communication with persons who have speech
>>     that is weak or hard to understand, the following quality
>>     indications can be used:
>>         -It shall be possible to indicate that the quality of the
>>     expressed speech makes it hard to understand.
>>         -It shall be possible to indicate a capability to undertand
>>     speech that is weak or hard to understand.
>>
>>     In order to enable communication with persons who need cognitive
>>     support in the form of reminders or notetaking, the following
>>     quality indications can be used:
>>         -It shall be possible to indicate a capability to provide
>>     reminders or take notes during a session.
>>
>>
>>     occurring need for modality or language translation. By
>>     indicating this service, a receiver of the indication can judge
>>     if invocation of that service will support matching of
>>     preferences and capabilities. Common assiting service types are
>>         Text relay service translating between text in real-time text
>>     and speech in audio.  ( even between text messages and audio exist )
>>     Service address shall be a URI where the service can be reached
>>     with one session for provision of the service within the media of
>>     that session.
>>     (note that this is different from how most current relay services
>>     today work. They often have two call legs, one with an audio call
>>     and one with a multimedia call. )
>>
>>     Invocation state shall indicate if the service is already
>>     included in the call, and if so, the media/modality/language
>>     indications show the joint capabilities.
>>     Invocation state can also contain a request to the other party to
>>     invoke the service if needed to complement the capabilities to
>>     achieve a functioning communication. This indication can be
>>     provided either by the offering or answering party.
>>
>>     Already specified ways to express media/modality/language shall
>>     be possible to use to the extent that they are usable.
>>     specifications and language tags on SDP level. For cases when
>>     these existing means imply limitations, these limitations shall
>>     be explained.
>>
>>     The method for identification of language preferences and
>>     capabilities in this specification is intended mainly for rapid
>>     ad-hoc session establishment and not intended to have the same
>>     ambitions as CLUE has for planned telepresence sessions.
>>
>>     The indications included in the offer shall represent the
>>     preferences and capabilities of the offering party.
>>
>>     The indications included in the answer shall represent the
>>     preferences and capabilities of the answering party actually
>>     planned to be used in the session.
>>
>>
>>
>>     X.10 Security
>>     -----------
>>>     (1) "center": customer trying to indicate that they prefer to
>>>     speak Spanish when contacting call center;
>>>     (2) "corner": simultaneous interpretation case where somebody
>>>     wants to receive both Spanish and English; complex ordering of
>>>     preferences ("I am a native speaker of English; fluent in
>>>     Spanish and can read a menu in Swedish"; "I can understand
>>>     (orally) Latin, but not speak it"; "I rate my preference for
>>>     English, Spanish and Swedish as 9, 7 and 3.5")
>>>
>>>     There's obviously no problem if the corner case happens to work,
>>>     but no extra effort (syntax, complexity) will be expended to
>>>     make them work. The center-corner cut-off may also differ for
>>>     routing and intra-UAS (SDP) cases since it seems reasonable to
>>>     assume that routing is more coarse-grained and has less
>>>     information about the current (right now), precise capabilities
>>>     of the end point.
>>>
>>>     Henning
>>>
>>>     On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             document use cases in a work group wiki.  We’re not
>>>             going to try to cover corner cases.
>>>
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jul 2015 16:26:07 -0400

The problem is not a list of requirements, it's the overall model. Your
model, if I understand this correctly, is that the signaling (in SDP, but
the same would apply in SIP) explicitly provides a list of options for the
receiver to choose from, with preferences. However, that's not how real
systems work - they are not Turing machines where you feed them inputs and
they produce predictable outputs, across a nearly infinite set of
behaviors. (They do, at the low level of SIP exchanges and some SDP
matching, but those behaviors are tightly constrained by the state machine
and "dumb". Even those cause a fair amount of interoperability problems if
implementations start exploring the corners of legal, but uncommon,
behavior.)

Generally, these systems have a very small set of operations ("invoke
LanguageLine", "bridge supervisor") that are invoked based on some small
number of triggers. These behaviors differs based on which system you are
reaching - an ACD for a bank will have a different set than a PSAP, even
though they are roughly similar (in the voice world, both are often based
on the same commercial ACD implementations), and a dial-in conferencing
system will have a rather different set.

Assume a PSAP expects three kinds of callers:
(1) voice callers, possibly with different spoken languages

(2) ASL-only caller (where the behavior depends on whether the PSAP has an
ASL call taker and the country/region-specific handling of relay)

(3) ASL+text caller, where local policy allows text-only

The PSAP just needs to know which of these cases it is dealing with, and it
will invoke a standard operating procedure for one of these. Any other
combinations will simply be "converted" into the least common denominator
(For example, ASL + Russian text may not be handled at all since it is so
uncommon, likely being treated as "ASL-only" or the language being ignored.
It won't magically invoke a text translator unless it has one for other
purposes.)

Within these categories, there might be variations. For example, (1) may
allow for multimedia, adding either text and/or video in addition to audio,
but that's low-level behavior in the UAs and standard SDP behavior that we
don't need to modify.

Complexity starts to creep when you are trying to do one of the following:

(1) Have cross-media dependencies ("only do X for media M1 if Y for media
M2")

(2) Preference orderings that are more than just plain "I like A best and
then B, C or D" (e.g., complex preferences like "I like A and B equally,
and then like C and D a little less, but barely put up with E")

(3) Telling the receiver of the call precisely what to do ("I want human
translation", "I want the PSAP, not the relay service, to invoke relay", "I
don't want to talk to you unless you can do at least 93.5% of what I asked
for")

Thus, I'd start the other way: For SDP, the draft, if I understand this
correctly, proposes starting with a simple language description for each
media (separate for each direction).

I will likely propose something simple like the following for SIP call
routing:

Call-Routing: text=en; video=ase

or

Call-Routing: en,fr (if the caller has a single set of language across all
language-dependent media; this example might be for a Canadian living in
Toronto)

[I may re-use a subset of caller preferences if that's easy, so ignore the
strawman syntax.]

If we start there, are there practical use cases where a receiving PSAP or
call center wouldn't know what to do and which kind of actually-existing
human they are communicating with (and thus invoke the appropriate
functionality)? If so, we should identify these cases and see whether they
can be addressed by minor extensions of the idea or fall in the "let's see
if we can solve this some other way" category.

Henning

On Wed, Jul 22, 2015 at 3:46 PM, Gunnar Hellström <
[email-masked]> wrote:

> X.4 Service indications is added. I did that because of two issues: 1. the
> problem of describing a couple of types of relay service users in language
> and modality preference terms, and therefore instead providing the
> opportunity to tell what kind of relay service the user is a regular user
> of. 2. The problem in a multi-national, multi-language situation for an
> answering part to know how to find a suitable assisting service to invoke,
> and therefore introducing a service hint in the coding.
>
> draft. The current draft has just priority within each medium, while I see
> a need for priority levels between media. Instead I suggest only three
> priority levels instead of the draft now specifying an unlimited positional
> order of priority within each medium.
>
> The requirements aim at allowing quite general terminals, e.g. using IMS,
> call services that may be located in other countries having no previous
> business agreement, such as an IMS user from one country visiting another
> country and calling emergency services there.
>
> Is that to hope too much? Do you suggest that persons with specific other
> modality needs than two-way speech will always need to be registered with
> service providers who are devoted to their needs?
>
>>  Can we agree to include this proposed requirements chapter and from
>> this proposal identify what should be added or deleted to get the center
>> assisting service, that supports the commuication in some often occurring
>> need for modality or language translation. By indicating this service, a
>> receiver of the indication can judge if invocation of that service will
>> support matching of preferences and capabilities. Common assiting service
>> types are relay service and language translation service.
>>
>> and capabilities of the answering party actually planned to be used in the
>> session.
>>
>>
>>
>> X.10 Security
>> -----------

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Jul 2015 22:33:39 +0200

First of all, I don’t think we need requirements for our original task.

We agreed we would develop use cases, which we would document in the work group wiki to guide our work.

Inline for some comments, but I don’t think we’re negotiating requirements.

> On Jul 22, 2015, at 9:46 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> If the requirements I proposed were too complex, can we then get proposals for what to delete from them.
> 
> Compared to the current real-time SLIM draft, I can see the following differences:
> 
> X.4 Service indications is added. I did that because of two issues: 1. the problem of describing a couple of types of relay service users in language and modality preference terms, and therefore instead providing the opportunity to tell what kind of relay service the user is a regular user of. 2. The problem in a multi-national, multi-language situation for an answering part to know how to find a suitable assisting service to invoke, and therefore introducing a service hint in the coding. 
I don’t think we need complex relay service indications.  I think just specifying the languages desired for each modality, in order, is sufficient.  If you say “ASL video”, english audio and french text, you are weird, but we know how to handle you.  I think we will have to augment the IANA registry of language tags to add the other assistive modalities needed, just as we have “ASL”.  I think you “request" captioned english, just like you request american sign language , but with a different tag, and on a different media stream.  

> 
> X.6 Priority. I suggest another priority indication than the current draft. The current draft has just priority within each medium, while I see a need for priority levels between media. Instead I suggest     only three priority levels instead of the draft now specifying an unlimited positional order of priority within each medium.  
I don’t see a need to have priority between media. I think those are corner cases.  i think the current proposal of an ordered list is simple, and unambiguous.

> 
> X.7 The type and quality indications were added, inspired by the discussion mainly from the e-mail draft discussion.
I probably wasn’t paying attention to those threads, so I can’t comment
> The requirements aim at allowing quite general terminals, e.g. using IMS, call services that may be located in other countries having no previous business agreement, such as an IMS user from one country visiting another country and calling emergency services there.
I think routing will have to handle roaming scenarios. I’m willing to discuss how we do that.  I’m not at all ready to decide on mechanisms yet.

> 
> Is that to hope too much? Do you suggest that persons with specific other modality needs than two-way speech will always need to be registered with service providers who are devoted to their needs?
No.  First of all, this is a routing issue, and thus is not in scope for the first document set.  I think we have to handle cases where the origination end chooses “transcoding” services and when the termination end chooses them.  The SDP offer/answer should work after the routing is completed sucessfully.

Brian

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Jul 2015 23:30:19 +0200

> First of all, I don’t think we need requirements for our original task.
I think we do. I noticed that our target drifted during the discussions, 
and the use cases were too few and coarse to really indicate what we 
needed.

I see that you propose that we could propose new subtags or other coding 
options to be added to the language tag registry. I think that can be a 
fruitful way to solve some of the needs, so let us keep that in mind.

/Gunnar
> I don’t think we need complex relay service indications.  I think just specifying the languages desired for each modality, in order, is sufficient.  If you say “ASL video”, english audio and french…
That would be to fulfill the requirements for type of service in the 
text media stream. So your example indicate that parts of the 
requirements chapter are suitable.

> I don’t see a need to have priority between media. I think those are corner cases.  i think the current proposal of an ordered list is simple, and unambiguous.
Right. I tried to express a first preference and a second. Then it is 
essential to be able to indicate either priority on 2-3 explicit levels, 
or a priority relation between media. That would enable coding for: I 
prefer to use ASL but can accept to use English real-time text. If we 
drop this possibility to have indications of acceptable fall back 
situations, we can probably simplify the requirements a bit.

> I probably wasn’t paying attention to those threads, so I can’t comment
You proposed type=captioned English above.
And I picked up the discussion on indicating if a medium had original or 
human or automatic translation, and saw some use of it also for the 
real-time case. But that can be dropped as well.
/Gunnar