Subject: [Ecrit] Mechanisms for adding supporting services to emergency calls

From: Gunnar Hellström <[email-masked]>
Date: Sun, 11 Nov 2007 10:57:05 +0100

This is a proposal to add descriptions about relay service invocation in
emergency calls to the ecrit specification series.

In the discussion about change proposals to the phonebcp specification
copied further down in this mai, I proposed to add some words about the need
to add a relay service to some emergency calls. 
It has some common interest with other supporting services, such as language
interpretation, that may be invoked in a three-party call arrangement when
needed.

I suggest that the inclusion of relay services ( and possibly other
supporting services ) is taken a step forward in the ecrit collection of
specifications. We have observed in small trials, that it is important to
connect relay services in true three-party call fashion with the emergency
services, so that the PSAP can share as many media as possible with the
user, while getting support with language or mode translations from the
relay service.

This proposal connects to point 1.1 below about phonebcp section 9.2 point
15:
-----------------------------Copy from phonebcp
discussion-------------------------------
9.2 point 15 now reads:
" 15.  SIP Caller Preferences [RFC3841] MAY be used to signal how the
        PSAP should handle the call.  For example, a language preference
        expressed in an Accept-Language header may be used as a hint to
        cause the PSAP to route the call to a call taker who speaks the
        requested language. "

The Caller Preference [RFC 3841] may be used also for indicating the need to
connect a relay service, either simply by specifying a media preference for
text or a media preference for video with a language preference for a sign
language. 

++++I suggest to add last in this point. 
------------------------------------
"SIP Caller Preferences may also be used to indicate a need to invoke a
relay service for communication with people with disabilities in the call."

-----------------------------End of
copy------------------------------------------------------

Some more thoughts should be spent to this proposal, for deciding:

a. What new tags are needed for the Caller preference evaluation?

b. Will caller preference be the main mechanism for invoking relay services,
do we need to specify other ways as well for cases where Caller preferences
are not supported?

c. The need is very similar to the everyday need to invoke relay services in
some calls for these users. So, the discussion should partly be held in some
general group, e.g. sipping.

The kinds of relay services currently in use are:

1. sign language relay services (usually called "video relay") translating
between sign language in a video phone and voice in a voice phone.

2. Sign and text relay service translating between sign language from the
user and voice vs voice to real-time text to the user. ( used by signing
deaf-blind users )

3. text relay service translating between real-time text with the user and
voice with voice phone users. Voice may also be taken through in various
combinations, leaving text translation to be done in only one way.

4. captioned telephony. A variant of text relay. Real-time text translation
added as captions to the voice towards the user in a voice call between two
parties.

5. speech-to-speech relay services, for people who speak weak or distorded
to get expert support in clarifying parts that need clarification during a
voice call.

6. cognitive support relay services, adding support for memory and cognitive
related disorders.     

For all these services there is also a language dimension. You need to reach
a service that can handle your language in the mode that the relay service
handles. Example: American Sign Language relay service if you use American
Sign Language.

Thoughts in this direction is earlier documented in RFC 3351.

I suggest that we start defining and registering tags for these cases and
decide to what extent the mechanisms need to be described in the ecrit
documents.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Monday, October 29, 2007 12:17 PM
To: 'Hannes Tschofenig'
Cc: 'Ecrit@Ietf. Org'
Subject: RE: [Ecrit] Modification proposals for media supportin
draft-ietf-ecrit-phonebcp

Hi,
Thanks,
I have inline answers marked <GH> below.
Change proposals are marked ++++++++ 

Further comments:

1. Connection of relay services
--------------------------------
Recent experience with trials with emergency calls with people with
communication related disabilities have made me realize that there are
further procedures to define.

In order to handle these calls, it is often most efficient to set up a three
party multimedia call with the user, the PSAP and a suitable relay service.

The relay services support call handling by translating, e.g. between sign
language and voice, between real-time text and voice, by adding real-time
text as captions to voice or by supporting weak speech or speech that is
hard to understand with clear speech.

PSAPS may be able to handle real-time text themselves, but it was evident
from the trial that support from a full three-party connected text relay
service made it possible for the the PSAP to concentrate on their original
task. It is obvious for the other communication modes that relay services
need to be invoked in the calls.

Some signaling may be needed for invoking the most appropriate relay
services rapidly end efficiently in the call. 

There are two requirement points in the phonebcp draft that relate to this
need, and may be expanded a bit in order to include this need.

It is in 9.2, point 15 and in 11, point 1.

1.1 Use Caller preferences for connection of relay services.
-------------------------------------------------------------
9.2 point 15 now reads:
" 15.  SIP Caller Preferences [RFC3841] MAY be used to signal how the
        PSAP should handle the call.  For example, a language preference
        expressed in an Accept-Language header may be used as a hint to
        cause the PSAP to route the call to a call taker who speaks the
        requested language. "

The Caller Preference [RFC 3841] may be used also for indicating the need to
connect a relay service, either simply by specifying a media preference for
text or a media preference for video with a language preference for a sign
language. 

++++I suggest to add last in this point. 
------------------------------------
"SIP Caller Preferences may also be used to indicate a need to invoke a
relay service for communication with people with disabilities in the call."

1.2 Use of conference calls and REFER to invoke relay services
--------------------------------------------------------------
Section 11, point 1 now reads: 
" 11.  Mid-call behavior

   ED-61/SP-38 During the course of an emergency call, devices and
   proxies MUST support REFER transactions and the Referred-by: header
   [RFC3515] to:
   1.  Be REFERed to a conference bridge; PSAPs often include
       dispatchers, responders or specialists on a call."

A relay service can be seen as a specialist to be included in the call. 

++++It may be good to point that out specifically by adding the 
++++following
sentence last in Section 11, point 1.:
------------------------------
"Relay services for communication with people with disabilities may be
included in the call in this way."

2. There is a slight inconsistency around the use of G.711.
-----------------------------------------------------------
Requirement ED-60 in Appendix A, Point 12 says:
" 12.  A normal SDP offer SHOULD be included in the INVITE.  The offer
        MUST include the G.711 codec, see Section 14."

Requirement ED-71, in Appendix A, says:
" ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law
   in North America) encoded voice as described in [RFC3551]."

So, ED-60 gives the impression that voice support is mandatory, while ED-71
gives the impression that it is optional. There are current SIP terminals
with only real-time text support according to RFC 4103. The question is if
such designs shall be enabled to call emergency services, or if they need to
be complemented with a G.711 voice codec. Some text users are not interested
in using voice at all.

+++++Conclusion:
-----------
If there is any specific reason why voice is needed in the call, then I
think the words "supporting voice" should be deleted from ED-71. If not, the
last sentence in ED-60 Point 12 should read "If voice is supported, the
offer MUST include the G.711 codec, see Section 14.

3. Further points inline below.

Gunnar

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Sunday, October 28, 2007 1:40 PM
To: Gunnar Hellström
Cc: Ecrit@Ietf. Org
Subject: Re: [Ecrit] Modification proposals for media support in
draft-ietf-ecrit-phonebcp

Hi Gunnar,

I just found this mail and noticed that nobody responded to you.

Are these issues covered with the recent draft update?

Ciao
Hannes

Gunnar Hellström wrote:
> I want to propose a few small modifications to 
> draft-ietf-ecrit-phonebcp-00.txt
>
>
> 1. Editorial and explanation.
> ----------------------------------
> The last lines in section 2 reads:
>
>   “o  The proxy recognizes the call as an emergency call and routes the
>       call using normal SIP routing mechanisms
>    [RFC4504] details Best Current Practice for SIP user agents.  This
>    memo can be considered an addition to it for endpoints.”
>
> A full stop is missing after mechanisms, and it is unusual to start a 
> sentence with a reference. I also suggest to include a hint on what is 
> found in RFC 4504
>
> I suggest a slight change to:
>
> "  o  The proxy recognizes the call as an emergency call, routes the
>       call using normal SIP routing mechanisms.
>
> Best Current Practice for SIP user agents including handling of audio 
> and real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be
applied.
> This memo can be considered an addition to it for endpoints."

<GH>The text is rearranged and the new text mainly found in sections 9 ED-54
and repeated in A.1.  Some small adjustments are still needed.
It reads:

"   ED-54 Best Current Practice for SIP user agents including handling of
   audio, video and real-time text [RFC4103] SHOULD be applied.  This
   memo can be considered as an addition to it for endpoints."

I have a couple of comments still on it:

A. Originally, this sentence referred to RFC 4504 as a general Best Current
Practice for SIP endpoints, and especially the real-time text support. 
By eliminating RFC 4504, it is not clear what Best Current Practice it
refers to. It has instead a direct reference to RFC 4103 for real-time text,
and that is good and equally important as the G.711 reference for voice
elsewhere.

I do not know what reasoning there was behind removing the reference to RFC
4504. Not knowing the background, 

+++++I suggest to include the reference "[RFC 4504]" again after the 
+++++words
"SIP user agents" to read "SIP user agents [RFC 4504]". 

If there was a specific reason to omit the reference to RFC 4504, I think
ED-54 can be left without that reference. 

+++++B. It may be unclear what "it" in the last sentence refers to. I
suggest changing "it" to "such Best Current Practice".

>
> 2. Add a bullet point in the list in section 2.
> ------------------------------------------------
> I also suggest that the sequence of steps should end with media 
> establishment rather than just routing
>
> Insert as a new bullet point last in the list in section 2:
>
>    o  The call is established and common media streams opened.
>
<GH> This is now well covered in section 14.
>
> 3. More real-time text improvements
> ---------------------------------------
> Section 3 starts:
> " Although present PSAPs have only support for voice calls"
>
> That is not true. A reasonable part of the population has also support 
> for real-time text calls. So, the support for real-time text expected 
> from IP is to maintain and extend support rather than fulfilling new
expectations.
>
> I suggest rewording to:
>
> " Support for voice calls and real-time text calls placed through PSTN 
> facilities or systems connected to the PSTN is found in present PSAPs.
> Future PSAPs will however support Internet connectivity and a wider 
> range of media types and provide higher functionality."

<GH>This is well expressed in other ways now.

>
> 4. Handle unused references.
> ----------------------------
> In the current version, I have observed two unused references.
> [RFC 4103] and [draft-ietf-sipping-toip], both related to the 
> real-time text medium.
>
> Revival of reference [rfc 4103] is proposed in 3) above.
>
> In order to revive the use of [sipping-toip], I suggest adding this 
> line between the two paragraphs of section 3:
>
> "The expectations for emergency service support for the real-time text 
> medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be 
> fulfilled."
>
> ( draft-ietf-sipping-toip-07 is in publication requested state )

<GH> Yes, done.

>
>
>
> With these small changes I think the phonebcp draft will be a good 
> guidance for design of user terminals.
>

Tanks
Gunnar

>
>
> Thanks
>
> Gunnar
>
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked]
> Tel: +46708204288
> www.omnitor.se
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
>   

__________ NOD32 2599 (20071017) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

__________ NOD32 2599 (20071017) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 Nov 2007 18:03:55 -0500

I added the text in 9.2.  For Section 11, I added the text in the area you
suggested, but then I moved most of the entire discussion on Caller Prefs to
-framework.

I took care of the rest as you suggested.  Thanks for your review.

Brian

> Sent: Monday, October 29, 2007 7:17 AM
> To: 'Hannes Tschofenig'
> Cc: 'Ecrit@Ietf. Org'
> Subject: RE: [Ecrit] Modification proposals for media supportin draft-
> ietf-ecrit-phonebcp
> 
> Hi,
> Thanks,
> ++++It may be good to point that out specifically by adding the following
> +++++I suggest to include the reference "[RFC 4504]" again after the words