Subject: RE: [Sipping] SIP Support for Hearing and Speech Impaired Users

From: "Eric Burger" <[email-masked]>
Date: Mon, 6 Aug 2001 16:08:19 -0400

This is really a simple transcoding bridge.

Let's look at an asymmetric wireless transcoder.  B can send GSM and receive
G.711.  A can send and receive G.711.  The transcoder will pass through B's
ear path and transcode the mouth path between GSM and G.711.  How does it
know to do this?  By the m= lines in A's and B's SDP.

Substitute TTS for GSM, and you have the scenario described below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Gonzalo Camarillo
Sent: Monday, July 30, 2001 5:15 PM
To: Arnoud van Wijk (ELN)
Cc: [email-masked]'; Jonathan Rosemberg; Henning Schulzrinne; Cathy
Gearhart (EUS); Henry Sinnreich
Subject: Re: [Sipping] SIP Support for Hearing and Speech Impaired Users

Hello,

Here you have some feedback on draft-vanwijk-sipping-deaf-req-00.txt:

This draft contains some call flows that show how different services
required by hearing impaired people can be implemented. The call flow of
section 6.2 shows how to implement a one-way speech to text translation
service.

In this example the voice from the caller (A) has to be sent to the
human relay (speech to text translation S2T). The S2T will send text
over RTP to the callee (B). B, however, sends audio directly to A (B can
speak perfectly).

Besides the text over RTP session between S2T and B, this example
assumes one single audio session. A sends audio to S2T and B sends audio
to A over the same RTP session.

This would not work, because S2T does not have any address to send RTCP
reports. Besides, the RTCP reports sent from B to A would indicate that
there were no packets received, since A is sending RTP packets to S2T
instead.

This example should contain two audio sessions: one sendonly from A to
S2T and another reconly (from A's point of view) from B to A.

The same bug can be found in other sections of the draft. Section 6.3
also assumes that the SDP in the INVITE from B to the relay only
contains an m line (video stream) while it should contain the video line
and the audio line (for RTCP).

The same thing with section 6.5.

Once we agree that both lines are needed, let's see how we are going to
provide the relay with these two m lines:

Let's assume that we are a speech to text relay. We need to receive two
m lines: 1) an outgoing text over RTP m line
2) an incoming voice over RTP line

I made some time ago a proposal for this. It consisted of using the same
format as in a conference bridge. That is, several users INVITE the
conference bridge. This mixes all the incoming audio and sends it out.

Applying the same principle, I INVITE the S2T with an SDP containing one
RTP text line, and then I send another INVITE with the audio line. Both
INVITEs belong to the same conference (they are typically related using
the request-URI). Therefore, the S2T acts effectively as a conference
bridge between both streams.

Jonathan made another proposal. He suggested that everything could be
done in a single INVITE. The relay would know that it had to translate
the media received over one media line to the other one. While this
approach is less general (it just works for translators/transcoders), it
saves messages.

I guess you will choose the second approach, right? (any of them is OK
with me)

Best regards,

Gonzalo

"Arnoud van Wijk (ELN)" wrote:
>
> I submitted the following draft:
> SIP Support for Hearing and Speech Impaired Users
>
> SIP is attracting more and more attention as a valuable tool to enable and
support voice and multimedia communications over the Internet. However, some
users of SIP-based services will be unable or severely restricted to use
plain voice communication. In particular, people who are hearing impaired
often cannot send and/or receive voice. Its goal is to lay a foundation for
design and implementation of SIP based services for Hearing and Speech
Impaired users. These services are generally enabled by baseline SIP, or
through the use of the caller preferences specification. No additional
extensions are proposed here in order to support universal access.
> It can be found at:
http://search.ietf.org/internet-drafts/draft-vanwijk-sipping-deaf-req-00.txt
>
> Let me know what ye all think of it! And ofcourse everybody is welcome to
bring additional requirements and possibilities.
>
> Greetz
>
> Arnoud van Wijk
> _______________________________________________________________
> ERICSSON EUROLABS NETHERLANDS BV
> Arnoud van Wijk
> Innovation Unit
> Research & Development (ELN/V)
> Fax: +31-161 247569
> _______________________________________________________________
>
> _______________________________________________
> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

--
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027
USA                              [email-masked]

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Michael Hammer <[email-masked]>
Date: Tue, 07 Aug 2001 10:21:38 -0400

All,

What has me concerned is how this scales to other services like three-way 
calling or conference calling.  This could get complex for all just because 
one party has a particular need.  The same problems could result if you 
extend this to automated language interpreters.

What do you think about the approach that the recipient is responsible for 
translations into the preferred receivable form, e.g. text, French, etc. ?

The idea would be that the call flows would be identical from the distant 
party's perspective (no impact on them), but the recipient needing special 
treatment would "conference in" a non-mixing translator that puts the 
received stream in the preferred form.  Received stream from distant party 
is relayed to translator, who returns stream in new format.  This can be 
done unbeknownst to other parties.  Supported user can mute the native 
speech and only read the text (or listen to French version). [Note:  If 
more than two languages used, send-side translation may be another type of 
translation service.]

This also has the benefit that the original speech can be put on 
speakerphone when both hearing and non-hearing parties are in the same room.

Mike

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 7 Aug 2001 13:02:25 -0400

We have a draft on transcoding that describes how the endpoint can request
transcoding services on its own behalf.  It will be out after the draft
moratorium...

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 10:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] SIP Support for Hearing and Speech Impaired Users

All,

Mike

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 7 Aug 2001 16:22:32 -0700

Next week at the SIPit event, we will start testing interoperability
between SIP T.38 fax relay implementations.  As of today, 2 companies
have confirmed their participation.

If you have an implementation and are interested in joining the
whistling team, send your contact information or just stop by at the
sip-it event.

Jean-Francois.

> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 7:49 AM
> To: [email-masked]'; [email-masked]'
> Subject: RE: [Sipping] T38 and SIP
>
>
> Patrick,
>
> As per a previous ping on the ietf list, a total of 4
> companies had privately indicated their intention to either
> implement or already test SIP T.38fax (via a couple of test
> cases at the next sip-it events).  Most are sip-pstn gateway vendors.
>
> The intent is to start some testing at the next event in
> August (confirmed by at least 2 companies).  The I-D of
> reference is
> http://search.ietf.org/internet-drafts/draft-mule-sip-t38callf
> lows-01.txt ;  preference is for the fax flow to replace the
> audio (see sections 4.2 and 5.2).
>
> Jean-Francois.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Aug 2001 01:10:35 +0300

Hello,

> This is really a simple transcoding bridge.

Yes, it is. Nobody said it was not.

> Substitute TTS for GSM, and you have the scenario described below.

I do not understand what is your point. FID actually gives you a way to
signal this scenario.

What I was saying is that in the draft we are referring to, the call
flows are wrong. A single media stream is set up while the correct way
to do it is to set up two media streams (basically for RCTP).

Regards,

Gonzalo