Subject: [Slim] Use cases - Multinational company with interpreter service

From: Gunnar Hellström <[email-masked]>
Date: Fri, 10 Jul 2015 10:12:39 +0200

This is resending of a use case proposed earlier. The intention of 
increasing the use case collection was to show or test where the 
borderlines for realistic use of the language/modality indications are, 
and make sure that we produce coding that covers the cases we want to cover.

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

4.x Multinational company with interpreter service

A person in an international company, has set the phone for indicating 
only spoken Spanish in the audio path and is calling a colleague who 
only talks Vietnamese, having the phone set to only spoken Vietnamese in 
the audio path.
The company has an interpreting service, but does not want that service 
to be engaged in waiting for calls that are not answered. Therefore the 
phones are set to compare the languages of incoming calls with its own 
language settings. In this case, the answering phone detects the 
discrepancy, and calls the interpreting service for a third leg with 
both spoken Spanish and spoken Vietnamese on high priority. The call 
center ACD looks at the language combination and finds the best match 
among the profiles of the logged in interpreters. The selected 
interpreter also gets the language combination displayed on the phone. 
The interpreter is connected and can start the interpretation in the 
expected languages. Before that moment, the Spanish caller has got a 
spoken message in the call, telling that the interpreting service is on 
its way to enter the call.

Note that in this example, the answering phone makes the decision on 
languages, so that the mechanism shall be possible to implement without 
collection of user profiles.  Another way to do this, would be to let 
the call be answered by the phone with the Vietnamese indication, and 
the SIP server connecting the call has extra functionality for detection 
of language mismatch in the established call, and doing the 
rearrangement of the established call into a three-party call with the 
interpreter service on the third leg.

/Gunnar

>     Thanks,
>     Paul
>
> On 3/7/15 5:50 PM, Gunnar Hellström wrote:
>> Let us continue to add to the use cases:
>>
>> A person in Spain with hearing loss who prefers to get both rapid text
>> and speech in the calls to combine to best perception declares strong
>> preference for speaking Spanish, and strong preference for hearing
>> Spanish and strong preference for reading Spanish text.
>> She is calling another person in Spain with hearing loss and the same
>> declaration of preferences:  strong preference for speaking Spanish, and
>> strong preference for hearing Spanish and strong preference for reading
>> Spanish text.
>> They have not indicated any capability for typing Spanish text.
>>
>> The evaluation needs to have the capabilities of both parties available
>> for assessment. The result will be that the calling party gets a
>> Captioned telephony service included in the call, that answers with
>> adding the written Spanish text capability towards the caller, and let
>> the called party's spoken Spanish capability indication pass on to the
>> caller.
>> On the route towards the called party, there is also a need to add rapid
>> typed Spanish text, so another captioned telephony service is added to
>> the call, adding Spanish Typed text capability to the indications,
>> together with the spoken Spanish indication from the caller, so that the
>> callee can be assured to be served well in the call.
>>
>> A problem for this case is how to indicate that both rapid typed Spanish
>> text is needed and also spoken Spanish, so they are not alternatives.
>> Another problem is what Paul brought up: The need to evaluate the
>> combination of preferences from the caller and callee, before the callee
>> is called.
>>
>>
>> Gunnar
>>
>> Gunnar Hellström skrev den 2015-03-05 23:39:
>>> Paul,
>>>
>>> Paul Kyzivat skrev den 2015-03-05 23:16:
>>>> The use case below is a good start.
>>>>
>>>> Are use cases for non-emergency real time communications also in
>>>> scope?
>>> Yes.
>>>>
>>>> I'll also observe that there is major interaction between the way the
>>>> language and media preferences are signaled and the architecture of
>>>> the systems that ensure there is a match of capabilities. Some of
>>>> today's relay services depend on being able to know the preferences
>>>> of the callee before communications are established to the callee.
>>>> They do this in order to queue the call until relay services are
>>>> available before contacting the callee. That is in conflict to
>>>> allowing the called device to signal its preferences without
>>>> pre-arrangement.
>>> Right.
>>> This is a problem with SDP-based preferences.
>>> We have discussed SIP Media tag based preferences. They can be
>>> conveyed at Register time and stored in SIP servers, and then compared
>>> for routing decisions with what the caller has.
>>> That approach is described in the draft Appendix A.
>>> I think the main problem with that approach was what we thought was a
>>> lack of way to describe spoken versus written language ( that we have
>>> learned a way around today ), and that the already specified ways for
>>> decision maing with RFC 3840 - 3841 did not seem to fit totally.
>>>
>>> A way in a closed environment would be to require support for OPTIONS,
>>> to get a preview of the SDP.  And in this case you might be able to
>>> require OPTIONS support if you want to have your calls properly
>>> routed,  and an assumption that if there is no resonse on OPTIONS,
>>> then that user is supposed to be a speech user with the default
>>> language of the area.
>>>
>>>
>>>
>>>>
>>>> In the use case below, the emergency operator takes the call before
>>>> the relay is included. This works out because there is *some* medium
>>>> in common that can be used before relaying comes online. There would
>>>> be a problem if the emergency operator only supported audio - the
>>>> call would be established but there would initially be no useful
>>>> media. That would be distressing for the caller. In emergency cases
>>>> it is plausible to expect the emergency operators to have extra
>>>> technology to help with these cases. But in non-emergency cases that
>>>> isn't necessarily true.
>>> Yes, I agree completely that answering a call and finding that you
>>> have no common language is distressing. The 2 minute wait for
>>> interpreter should of course also be avoided. But exsists in reality.
>>>>
>>>> My point is simply that the architecture(s) required to support these
>>>> features should be considered as part of the work. (This may not lead
>>>> to any normative requirements. It might only be examples or use
>>>> cases.)
>>> Yes.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 3/5/15 4:49 PM, Gunnar Hellström wrote:
>>>>> In order to decide on what to support, I think we should now
>>>>> collect a
>>>>> long list of use cases and then decide which ones to support and
>>>>> which
>>>>> ones to not support.
>>>>>
>>>>> I can imagine two kinds of use cases:
>>>>> 1.  architectural cases outlining callers, callees and call
>>>>> distribution
>>>>> and routing functions and additional services.
>>>>> 2. call cases: callers with language and media preferences called
>>>>> parties with media and language capabilities and additional services
>>>>> with language capabilities.
>>>>>
>>>>> So, here is a use case:
>>>>>
>>>>> Emergency call from an Australian Sign language user
>>>>>
>>>>> A deaf person in Australia has prepared her phone with the following
>>>>> preferences:
>>>>> Prefer to use Australian Sign Language for both signing and
>>>>> perceiving
>>>>> sign in video.
>>>>> Can with less but fair preference do International Sign in both
>>>>> directions in video.
>>>>> Can but do not prefer to use real-time text in English in the text
>>>>> channel.
>>>>> Has a terminal with audio function both ways but has no interest
>>>>> to use
>>>>> that for language communication.
>>>>> She has an emergency in Australia and calls the Australian emergency
>>>>> number.
>>>>> The emergency service has no own sign language capability, but has a
>>>>> few
>>>>> terminals and operators who handle video, audio and real-time text
>>>>> (total conversation). They have an agreement to call for
>>>>> interpretation
>>>>> between Australian Sign Laguage and Spoken English, but that
>>>>> service is
>>>>> allowed to have up to two minutes answering time.
>>>>> The call is analyzed for language and media contents and the ACD
>>>>> offers
>>>>> it to the group of operators with total conversation terminals
>>>>> with an
>>>>> indication that the two sign languages are preferred but that English
>>>>> text is possible.
>>>>> The analysis also causes an outgoing call in all media to the sign
>>>>> language interpreting service because no operator in the emergency
>>>>> service know sign language.
>>>>> The emergency operator takes the call and establish all media, and
>>>>> see
>>>>> from the declaration that it is possible to start asking about the
>>>>> emergency by text. The deaf caller see all media being established
>>>>> but
>>>>> also see that at the moment the only common language is typed
>>>>> English.
>>>>> A minute later the sign  laguage interpreter answers. The call is
>>>>> modified to a three-party call, the capability indication changes so
>>>>> that it is evident to the caller that Australian sign language can be
>>>>> used now.
>>>>> The call can continue in convenient sign with the calling user and
>>>>> speech between the interpreter and the emergency operator. If
>>>>> anything
>>>>> needs exact spelling or remembered, then the text channel is still
>>>>> there
>>>>> for occasional use.
>>>>>
>>>>>
>>>>> Gunnar
>>>>>
>>>>>
>>>>>
>>>>> Randall Gellens skrev den 2015-03-05 21:10:
>>>>>> Hi Gunnar,
>>>>>>
>>>>>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote:
>>>>>>
>>>>>>>  I also view the charter to be good and want to see the work
>>>>>>> started.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>>
>>>>>>>  There are drafts to start with:
>>>>>>>  https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00
>>>>>>>
>>>>>>>
>>>>>>>  Answering Christians question about what extensions might be
>>>>>>> needed,
>>>>>>> I want to answer relative towhat is in the realtime draft now.
>>>>>>>
>>>>>>>  I see some topics that may need discussion:
>>>>>>
>>>>>> The point of the group is to have discussion on what we need. One
>>>>>> thing that has been beaten into me by painful experience over many
>>>>>> years is that it's best to start with the simplest possible solution
>>>>>> that meets enough of the use cases to be useful, and build on that
>>>>>> after gaining experience.  I've seen this approach work, whereas
>>>>>> creating a more complex solution that tries to meet all or most
>>>>>> anticipated use cases often fails due to being too difficult to
>>>>>> implement.
>>>>>>
>>>>>>>
>>>>>>>  1. Coding of unspecified language but specific mode.
>>>>>>>  I expect that in many cases it is merely the modality that is of
>>>>>>> interest to negotiate, rather than the exact language. There is
>>>>>>> often
>>>>>>> a default language in a specific area, and as long as you use that,
>>>>>>> you will feel that it is a burden to specify that exactly, but
>>>>>>> rather
>>>>>>> indicate in what medium you want the language exchange. You may
>>>>>>> want
>>>>>>> to use text for language exchange and audio to convey the sound
>>>>>>> from
>>>>>>> a location.
>>>>>>>  So, you would like to specify your preference for spoken,
>>>>>>> listened,
>>>>>>> written, read, visualized and seen.  And for signed and perceiving
>>>>>>> sign languages. Regardless of exact language.
>>>>>>>  So, some codes to use in place of specific languages for these
>>>>>>> kinds
>>>>>>> of general modalities could be needed.
>>>>>>
>>>>>> We can discuss this in the group.  We already have the ability to
>>>>>> negotiate media with no language expression, which might be
>>>>>> sufficient
>>>>>> for the basic use cases.  Adding a new tag for the default language
>>>>>> wouldn't be a huge burden, but I'd like to see discussion on why
>>>>>> it's
>>>>>> needed before proceeding.
>>>>>>
>>>>>>>
>>>>>>>  2. Relative preference between media.
>>>>>>>  I think it can be important to have a coding for preference
>>>>>>> between
>>>>>>> media, to express for example if I prefer to speak but can
>>>>>>> accept to
>>>>>>> type.
>>>>>>>  We have an order of preference indication between languages in the
>>>>>>> same medium in the draft, but not between media.
>>>>>>
>>>>>> This would be worth discussing in the group as well.  My question
>>>>>> would be if the incremental value of being able to specify this
>>>>>> would
>>>>>> result in any real-world benefit, that is, would it change the
>>>>>> result
>>>>>> of the negotiation over what we have now?
>>>>>>
>>>>>>>
>>>>>>>  3. Absolute versus relative preference between languages.
>>>>>>>  We have a relative order of preference indication between
>>>>>>> languages
>>>>>>> in the same medium in the draft.
>>>>>>>  I can see cases when it is instead an absolute preference that
>>>>>>> would
>>>>>>> be of importance.
>>>>>>>  E.g. I am equally happy to get spoken German or spoken French in
>>>>>>> this call, but may as the last resort do with spoken English.
>>>>>>>  Or, same thing between media:
>>>>>>>  One case can be:  I strongly prefer to use spoken French, but
>>>>>>> can as
>>>>>>> the last resort accept to use written French.
>>>>>>>  Another can be: I must receive both spoken French and French text.
>>>>>>
>>>>>> I would expect that the called party would have a set of language
>>>>>> and
>>>>>> media capabilities (either in-house or by bridging in translation,
>>>>>> relay, or interpreter services) and would want to support the
>>>>>> caller's
>>>>>> needs.  I doubt that getting fancy with preferences would change the
>>>>>> result very much.
>>>>>>
>>>>>>>
>>>>>>>  4. Same media conveyed under different media types
>>>>>>>  The current draft specifies SDP as the base for the language
>>>>>>> declarations. How do we resolve the cases when the same language
>>>>>>> modality can be conveyed under different media types?
>>>>>>>  Text is conveyed in real time under the media type text. But it is
>>>>>>> possible to have some near real-time exchange of text under media
>>>>>>> type message (MSRP). How do we express that these might be
>>>>>>> alternatives for carrying the same written language?
>>>>>>>  That question also surfaces the problem that in the language
>>>>>>> register there are no good way to express if it is a spoken use of
>>>>>>> the language or a written use of the language we want to specify.
>>>>>>> There are separate language tags for sign languages but not for
>>>>>>> spoken varsus written. (there are some sub-tags for scripts, but
>>>>>>> they
>>>>>>> should only be used when it is important to select between script
>>>>>>> variants )(There is even an SDP-less way to carry text, in the SIP
>>>>>>> MESSAGE method. There will be no way to express that as an
>>>>>>> alternative way to convey language when we base the method on SDP.)
>>>>>>
>>>>>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have
>>>>>> the SDP-and-SIP one done. Since emergency calling is based on SDP
>>>>>> and
>>>>>> SIP, I think we need to start there.
>>>>>>
>>>>>>>
>>>>>>>  3. Slow start of SIP.
>>>>>>>  We can in SIP have INVITE without SDP offer, and let the
>>>>>>> responding
>>>>>>> party send the offer with SDP.
>>>>>>>  With the negotiation mechanism based on SDP, does this slow start
>>>>>>> cause any restrictions for us regarding the possiblilities to
>>>>>>> express
>>>>>>> and negotiate language?
>>>>>>
>>>>>> I think we need to focus initially on what's needed for emergency
>>>>>> calling and similar use cases.  We can expand after we get something
>>>>>> done.
>>>>>>
>>>>>>>
>>>>>>>  I do not want to cause eternal discussions about border cases,
>>>>>>> and I
>>>>>>> do not want to extend the method into unmanageable complexity. I
>>>>>>> just
>>>>>>> want us to take good decisions on the mechanism so that it
>>>>>>> covers the
>>>>>>> cases we want it to cover with a method that is not too complex.
>>>>>>
>>>>>> Thank you, that's good to hear.
>>>>>>
>>>>>>>
>>>>>>>  Christian, maybe in your question was also how the intended work
>>>>>>> differs from language negotiation methods already available in
>>>>>>> RFC:s?
>>>>>>>  The current draft, section 6 has a discussion about that. One
>>>>>>> difference is that there is today no way to indicate order of
>>>>>>> preference between languages.  Another is the one I described
>>>>>>> above;
>>>>>>> the Language tag as such does not indicate the difference between
>>>>>>> spoken and written.
>>>>>>>
>>>>>>>  /Gunnar
>>>>>>>
>>>>>>>
>>>>>>>  Christian Groves skrev den 2015-03-05 01:49:
>>>>>>>>  Hello Randall,
>>>>>>>>
>>>>>>>>  I agree with Paul that it does seem optimistic.
>>>>>>>>
>>>>>>>>  In the question text its mentions the caller's "media needs". I'm
>>>>>>>> pretty sure I under the scope of "language needs" but "media
>>>>>>>> needs"
>>>>>>>> could be a little open ended. What sort of enhancements do you see
>>>>>>>> to the existing negotiation methods?
>>>>>>>>
>>>>>>>>  Regards, Christian
>>>>>>>>
>>>>>>>>  On 5/03/2015 9:00 AM, Paul Kyzivat wrote:
>>>>>>>>>  I support this.
>>>>>>>>>
>>>>>>>>>  But I find the schedule vastly overoptimistic, especially for
>>>>>>>>> real-time. Add a year or two.
>>>>>>>>>
>>>>>>>>>      Thanks,
>>>>>>>>>      Paul
>>>>>>>>>
>>>>>>>>>  On 3/3/15 6:33 PM, Randall Gellens wrote:
>>>>>>>>>>  Hi SLIM people,
>>>>>>>>>>
>>>>>>>>>>  Here is a revised proposed charter.  The intent is to focus on
>>>>>>>>>> the two
>>>>>>>>>>  current drafts and get those completed.
>>>>>>>>>>
>>>>>>>>>>  ----------
>>>>>>>>>>
>>>>>>>>>>  SLIM: Selection of Language for Internet Media
>>>>>>>>>>
>>>>>>>>>>  Description of Working Group:
>>>>>>>>>>
>>>>>>>>>>  A mutually comprehensible language is helpful for human
>>>>>>>>>> communication.
>>>>>>>>>>  This is true across a range of circumstances and
>>>>>>>>>> environments. In
>>>>>>>>>>  general, the problem is most acute in situations where there is
>>>>>>>>>> not a
>>>>>>>>>>  clear choice for a single language, such as environments
>>>>>>>>>> lacking
>>>>>>>>>>  contextual or out-of-band information regarding the identity
>>>>>>>>>> of the
>>>>>>>>>>  parties and the language to be used.
>>>>>>>>>>
>>>>>>>>>>  The group will address two specific cases that most urgently
>>>>>>>>>> need a
>>>>>>>>>>  technical solution: One problem space is non-real-time
>>>>>>>>>> communication,
>>>>>>>>>>  specifically email for one-to-many or where the set of
>>>>>>>>>> recipients is
>>>>>>>>>>  dynamic or different recipients require different languages;
>>>>>>>>>> the
>>>>>>>>>> other
>>>>>>>>>>  is real-time communication, specifically emergency calling,
>>>>>>>>>> preferably
>>>>>>>>>>  also useful for other cases where the parties may not know each
>>>>>>>>>> other
>>>>>>>>>>  personally or where one party wishes to accommodate people with
>>>>>>>>>> varying
>>>>>>>>>>  language and media needs.
>>>>>>>>>>
>>>>>>>>>>  In the real-time communication case, language and media are
>>>>>>>>>>  intrinsically linked, for example, signed languages require a
>>>>>>>>>> video media.
>>>>>>>>>>
>>>>>>>>>>  While the two use cases are in different contexts (real time
>>>>>>>>>> and
>>>>>>>>>>  non-real-time), the fundamental goal is the same: to enable
>>>>>>>>>> selection of
>>>>>>>>>>  the best-fit language(s) for a specific situation. Some of the
>>>>>>>>>> details
>>>>>>>>>>  will also be in common across the cases. Having a single WG
>>>>>>>>>> address
>>>>>>>>>>  both cases makes it clear that these are two aspects of the
>>>>>>>>>> same
>>>>>>>>>> basic
>>>>>>>>>>  problem.  A single WG also makes it easier to maximize
>>>>>>>>>> similarities and
>>>>>>>>>>  avoid unnecessary fragmentation of the solutions.
>>>>>>>>>>
>>>>>>>>>>  The group will produce two documents, one for email, and one
>>>>>>>>>> for
>>>>>>>>>>  real-time communications.
>>>>>>>>>>
>>>>>>>>>>  In the email case, the group will produce a MIME content type
>>>>>>>>>>  specification that enables a single email message to contain
>>>>>>>>>> multiple
>>>>>>>>>>  language versions of the content, with provisions to help
>>>>>>>>>> clients
>>>>>>>>>> select
>>>>>>>>>>  a best fit version.
>>>>>>>>>>
>>>>>>>>>>  In the real-time communication case, the group will produce a
>>>>>>>>>>  specification enabling negotiation of a human language per
>>>>>>>>>> media
>>>>>>>>>>  stream.  The specification must be suitable for use in
>>>>>>>>>> emergency
>>>>>>>>>>  communications as specified in RFC 6443 and RFC 6881; it is
>>>>>>>>>> desirable to
>>>>>>>>>>  also be suitable for use in non-emergency real-time
>>>>>>>>>> communications that
>>>>>>>>>>  share the same call set-up and media negotiation protocols. The
>>>>>>>>>>  mechanism will permit the caller's media and language needs and
>>>>>>>>>>  preferences to be matched against what the called party is
>>>>>>>>>> able to
>>>>>>>>>>  provide.  The mechanism will permit resources (e.g.,
>>>>>>>>>> translation,
>>>>>>>>>> relay,
>>>>>>>>>>  media) to be allocated or engaged as early as possible in the
>>>>>>>>>> call
>>>>>>>>>>  set-up or for the call to be routed or handled specially (e.g.,
>>>>>>>>>> routed
>>>>>>>>>>  to a resource able to provide a needed language and/or media).
>>>>>>>>>>
>>>>>>>>>>  Goals and Milestones:
>>>>>>>>>>
>>>>>>>>>>  June 2015 -- Submit "Multiple Language Content Type" to the
>>>>>>>>>> IESG for
>>>>>>>>>>  consideration as a Standards Track RFC
>>>>>>>>>>  June 2015 -- Submit "Negotiating Human Language in Real-Time
>>>>>>>>>>  Communications" to the IESG for consideration as a Standards
>>>>>>>>>> Track RFC
>>>>>>>>>>
>>>>>>>>>>  ----------
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>>>  SLIM mailing list
>>>>>>>>>  [email-masked]
>>>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>>>  SLIM mailing list
>>>>>>>>  [email-masked]
>>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>>  --
>>>>>>>  -----------------------------------------
>>>>>>>  Gunnar Hellström
>>>>>>>  Omnitor
>>>>>>>  [email-masked]
>>>>>>>  +46 708 204 288
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  [email-masked]
>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 10 Jul 2015 10:17:06 +0200

This is another use case sent earlier. We need to decide if we can 
extend the coding to express the need of simultaneous speech and 
texting, or if we need to divert this need to indicate a service request 
instead of a modality need.

4.x Captioned telephony user calling another captioned telephony user

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 10 Jul 2015 10:26:43 +0200

Here is the use case that might seem to have too many details. So if 
that is so, let us reduce it, or separate it in more but less complex ones.
It tries to show the need for priority among the indications, and the 
priority between different media.

We do not have any requirement chapter.

---------
4.x Emergency call from an Australian Sign language user

A deaf person in Australia has prepared her phone with the following 
preferences:
Prefer to use Australian Sign Language for both signing and perceiving 
sign in video.
Can with less but fair preference do International Sign  in both 
directions in video.
Can but do not prefer to use real-time text in English in the text channel.
Has a terminal with audio function both ways but has no interest to use 
that for language communication.
She has an emergency in Australia and calls the Australian emergency number.
The emergency service has no own sign language capability, but has a few 
terminals and operators who handle video, audio and real-time text 
(total conversation). They have an agreement to call for interpretation 
between Australian Sign Laguage and Spoken English, but that service is 
allowed to have up to two minutes answering time.
The call is analyzed for language and media contents and the ACD offers 
it to the group of operators with total conversation terminals with an 
indication that the two sign languages are preferred but that English 
text is possible.
The analysis also causes an outgoing call in all media to the sign 
language interpreting service because no operator in the emergency 
service know sign language.
The emergency operator takes the call and establish all media, and see 
from the declaration that it is possible to start asking about the 
emergency by text. The deaf caller see all media being established but 
also see that at the moment the only common language is typed English.
A minute later the sign  laguage interpreter answers. The call is 
modified to a three-party call, the capability indication changes so 
that it is evident to the caller that Australian sign language can be 
used now.
The call can continue in convenient sign with the calling user and 
speech between the interpreter and the emergency operator. If anything 
needs exact spelling or remembered, then the text channel is still there 
for occasional use.

Gunnar