Subject: [Slim] Thoughts on negotiation for the real-time case

From: Gunnar Hellström <[email-masked]>
Date: Thu, 1 Jun 2017 17:07:28 +0200

While we are waiting on decisions on the outstanding issues, I think it 
can be fruitful to spend some thoughts about the negotiation for the 
real-time case.

( I am sorry if this investigation again surfaces the already known 
shortcomings, but please read it also for other observations.)

*Look at this use case*

Disregarding routing, we assume that a call from a caller reaches a 
callee UA and a callee.

The callee UA is provided with the language preferences of the callee by 
some settings.

The callee UA can either do the negotiation and compose an answer 
autonomously or interact with the user to compose an answer.

In both cases, the callee must be informed about which modalities and 
languages the callee is supposed to select from (or is supposed to use 
if only one alternative remains), for starting the conversation.

Knowing that, the callee answers and expresses a greeting in a selected 
language and modality.

The caller gets the answer and also needs to be informed about the 
outcome of the negotiation, so that the caller can start the 
conversation in an acceptable modality and language.

Section 3 in the draft indicates that we can have many languages per 
media stream in the offer, but only one language per media stream in the 
answer.  We can have many media streams in both the offer and answer.

Assume an offer containing spoken languages en, fr and written en,  all 
both ways

Assume a callee UA configured for spoken sp, fr, en and written en, all 
both ways

Assume that the callee UA autonomously takes the decision. It needs some 
algorithms. There is no guidance in the current draft about how to 
handle the two media. We have a match on written English both ways, but 
no way to decide if the callee shall start using spoken or written.  
That may be handled by a built-in algorithm saying "use spoken whenever 
available".  For slection among the matching spoken languages, in this 
case it can be either polite to the caller and select spoken 'en' both 
ways, or it can be convenient for the callee and select 'fr' both ways. 
Selecting different spoken languages in the different directions is not 
recommended according to the note at end of 5.5.

So, assuming we have the callee UA set to the polite algorithm, and to 
use spoken whenever there is a match, the  UA might answer spoken en 
both ways and written en both ways, and provide the information to the 
callee to SPEAK ENGLISH, and provide the matching languages as 
additional information.

The answer will be displayed to the caller and the caller can tune in to 
listen to English and talk English and know that the text stream can be 
used as occasional fall-back for written English.

Having a callee UA requiring interaction with the user to take the 
decisions results in very similar exchange. The user may have some 
out-of-band experience that tells that for this caller, it will be 
better to use written English, or spoken French. But the decision will 
be taken and likely one spoken language and written English will be 
included in the answer and the call starting in a similar way as in the 
autonomous case.

The negotiation supports the initial exchange in the call. It is the 
ambition that it shall be close to the most convenient choice for both 
parties, but they are free to change language and modality during the 
call if they find reasons to do so. It is inconvenient and time 
consuming to change language, so it is best if the initial selection is 
a good choice.

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

Can we learn something from this example and other thoughts about 
negotiation?

*1. The negotiation seems to work reasonably well for both the 
autonomous and interactive UA style in this case.*

*2. There are things we cannot express that may lead to a less optimized 
decisions:*

*2.1 Languages in the same modality are automatically assigned different 
preferences, even if the user want to rate them equal. *
A possibility to rate them equal would enable a better match for the 
case when one user has a preference and the other has not.

This shortcoming can lead to less optimized decisions on how to start 
the call, but there will seldomly be any major inconveniences.

*No change urgently needed*

*2.2 Preference between modalities cannot be expressed*

Languages in different modalities provide no guidance for which one to 
select if there is a match in more than one modality. Local algorithms 
or interaction with the user must be used to take the decision on how to 
start the call. An algorithm that says "use spoken whenever there is a 
match in spoken" may be useful in many cases, but very unfavourable for 
the calling user who strongly prefers written, but can just barely 
manage spoken. This is a severe shortcoming of the current draft. *A way 
to indicate most preferred modality or preference across all modalities 
is needed.*

*2.3 Requirement to only have one language per media in the answer. *
The requirement in section 3 and 5.2 to only have one language per media 
in the answer has both good and bad influence.

It is good that a consistent decision needs to be taken and the callee 
will get exact guidance for what language to use for each media and 
direction.

If the decision is made by the callee UA autonomously, the callee may by 
external information get the impression that the decision is not 
optimal, but the UA will require the user to start the call in one 
specific language and it would be confusing to deviate from that 
decision. The user will feel controlled by the device.

It may be less fortunate that the caller does not get the full picture 
about the callee language capabilities if the initially selection turns 
out to be inconvenient.

However, there is a limit for what information a user is able to take in 
during a call, so this limitation is not likely to have any severe 
influence on the user satisfaction. If the users feel a need to switch 
language during the call, they may figure out what is more suitable. The 
callee has the full information and can guide to a good switch.

*No change urgently needed.*

*3. No way to differentiate a need for two simultaneous media from a 
need for two alternative media.*

This shortcoming was not visible from the example above.

If for example the calling user requires to receive both spoken and 
written form of language simultaneously to grasp the contents, there is 
currently no way to indicate that need for simultaneous use of different 
media.

Both media can be included, and assigned language indications, but it 
will be interpreted as if it is alternatives to select from.

A way to indicate that one media is another representation of another 
media and that they are provided together is needed for these cases. The 
need exists in both the offer and the answer.

*An addition for expression of simultaneous modalities is needed.*

*4. Different preferences in different directions.*

The current draft can express different set of language capabilities in 
different directions.

The decision algorithm will be capable of deciding to use one media and 
language in one direction and one media and language in the other 
direction. Local algorithms may be needed for selecting the same 
language in both directions in most cases even if different media are used.

However, if the user has some, but much lower capabilities for a 
language in the opposite direction to a preferred language and 
direction, there is currently no way to express this difference in 
preference, and there is a huge risk for mistakes in decisions when 
capability in both directions of the same modality is indicated.

Conclusion: There is a possibility to express different capabilities in 
different directions, but there is a lack of possibilities to express 
differencies in preference between different modalities in the same 
direction.

*This is the same limitation as described in 2.2 above and requires the 
same extension.*

*Another use case put other light on the negotiation possibilities:*

A caller want to speak English and receive written English.

In some situations, the user may also be able to receive spoken English 
but want to have that as last resort.

The user is also able to send written text, but so slowly that the user 
really want to avoid that if possible.

The current draft only offers a possibility to send an offer with spoken 
English both ways and written English both ways. The huge difference in 
preference between the directions in each media is not possible to indicate.

The callee UA and callee is capable of spoken English both ways and 
written English both ways. The UA can only judge by what is specified 
and may go from the principle to use spoken whenever there is a match,
  so spoken English both ways will be selected, and the calling user 
will be dissatisfied and need to devote time to ask the callee to use 
text instead of talking.

*This example clearly requires a way to indicate differences in 
preference between different modalities in the same direction. *

Regards

Gunnar

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