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

From: "Mark Watson" <[email-masked]>
Date: Wed, 8 Aug 2001 14:50:16 +0100

All,

I think there's a general problem, in that many types of media can in
principle be translated (with varying degrees of ease) in to many other
types of media.

What would be useful is a generic way for the parties to a session to
specify their preferred media combinations and for the appropriate
translators to be automatically brought into the session - such a mechanism
can be defined indepent of the media types involved and the translators
available. (Perhaps this is what your draft does, Eric - I'll look out for
it)

I'd like to think there was a way of doing this which also optimised the use
of resources - so if Party A wants to receive only Media Type 1 (Media1),
and Party B wants to send Media Type 2 (Media2) and an Media2->Media1
translator is available, then there should be no need to send Media2 to A
(indeed, the reason A likes Media1 might be because it is lower bandwidth
than Media2). Media2 should only be sent to the translator. Equally, though,
the case where A wants *both* MT1 and MT2 should be supported.

Regards,

Mark Watson

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: 07 August 2001 18:02
> To: sipping
> Cc: Jeff Van Dyke; Andy Spitzer
> Subject: RE: [Sipping] SIP Support for Hearing and Speech 
> Impaired Users
> 
> 
> 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,
> 
> 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
> 
> 
> At 04:08 PM 8/6/2001 -0400, Eric Burger wrote:
> >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.tx
> t
> > >
> > > 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
> 
> 
> _______________________________________________
> 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: "Eric Burger" <[email-masked]>
Date: Wed, 8 Aug 2001 10:30:06 -0400

We have two approaches.  The first approach would be more like your "it
happens by magic in the network" approach.  In this scenario, a proxy
detects the mismatch in SDP and requests the transcoding service in the
manner of a 2-party conference bridge.  The second approach is where the
terminating UA requests the transcoding service and returns the transcoding
service's SDP to the calling UA.

Service providers are more likely to use the first approach for peering or
as a value-add service.  Phone manufacturers or ingress proxies are more
likely to use the second approach.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 9:50 AM
To: 'eburger'; sipping
Cc: Jeff Van Dyke; Andy Spitzer
Subject: RE: [Sipping] SIP Support for Hearing and Speech Impaired Users

All,

---

From: Michael Hammer <[email-masked]>
Date: Wed, 08 Aug 2001 11:38:51 -0400

Eric,

As much as I would like to believe in magic, resources are provided in the 
network for the benefit of either the calling or called party.  In this 
case, it is the called party that benefits.  Both your and Mark's 
approaches (with which I agree) lay the responsibility on the called party 
or its supporting proxy to recognize the mismatch in desired media and to 
invoke the translator as needed.  In the first case, I would assume the 
magic is based on some type of registration information (profile?) 
associated with the called party, in the second case the called party 
explicitly asks for the service.

Mike

---

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

Hello,

Letting proxies detect the missmatch of codecs and invoke transcoding
services is an old idea. This is actually what an MSC does in a GSM
call. And that's why the call between two GSM phones has two transcoding
points, when it should be transcoder-free. That's also why
transcoder-free operations had to be defined, adding complexity to GSM.

Let's keep things simple. Let's the end systems invoke transcoding
services if they want to. They can use 3pcc for instace: here you have
an example of such an invokation.
http://www.hut.fi/~gonzalo/papers/draft-camarillo-3pcc-qos-00.txt

In the scenarios where we do not really need to break the end to end
negotiation of media parameters, let's keep it e2e.

Regards,

Gonzalo

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 8 Aug 2001 19:22:07 -0400

A proxy in the middle makes sense if you're peering two 100% codec A and
100% codec B networks.  However, for everything else, letting the end system
invoke transcoding makes sense.  That's why we defined both.

By INVITE-ing a transcoding resource into the call, we can setup the call in
10 messages, as opposed to 28 as described in
draft-camarillo-3pcc-qos-00.txt.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 6:27 PM
To: Michael Hammer
Cc: [email-masked]; sipping; Jeff Van Dyke; Andy Spitzer
Subject: Re: [Sipping] SIP Support for Hearing and Speech Impaired Users

Hello,

Regards,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Aug 2001 13:17:09 +0300

Hello,

Well, an MSC uses less messages, and they are much smaller than SIP
messages. We might have to trash SIP and come back to the MSC
architecture :o)

A network with 100% codec A and a network with 100% codec B... where do
you see the problem? I can invoke using 3pcc a 3rd-party-developed
transcoder which is in a 3rd network.

The problem with your approach is that "the network" makes unnecessary
assumptions about what the terminals want. Of course that in a GSM to
GSM call the MSC does not want to introduce unncessary transcoding
points. However, since the MSC is not one of the terminals, it thinks
that the terminals need a transcoder... and that's the problem.

The terminals can perform an end-to-end negotiation of media parameters.
Then, they are the ones know best if a transcoder is needed.

I like to see and end to end architecture as long as it is possible.
Some scenarios need support from the network, no doubt about it, but
some of them do not. And this one would not need it.

However, you are right. All the mechanisms are out there. SIP can be
used in both, the end to end architecture where end systems are in
control and in a more PSTN-oriented architecture, where the network
(proxies) have more responsability.

I just happen to like better the e2e approach.

Regards,

Gonzalo

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 9 Aug 2001 11:19:20 -0400

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Gonzalo Camarillo
> Letting proxies detect the missmatch of codecs and invoke 
> transcoding services is an old idea. This is actually what an 
> MSC does in a GSM call. And that's why the call between two 
> GSM phones has two transcoding points, when it should be 
> transcoder-free. That's also why transcoder-free operations 
> had to be defined, adding complexity to GSM.
> 
> Let's keep things simple. Let's the end systems invoke 
> transcoding services if they want to. They can use 3pcc for 
> instace: here you have an example of such an invokation. 
> In the scenarios where we do not really need to break the end 
> to end negotiation of media parameters, let's keep it e2e.
>

YES YES YES YES YES YES YES

> Regards,
> 
> Gonzalo
> 
> 
> Michael Hammer wrote:
> > 
> > Eric,
> > 
> > As much as I would like to believe in magic, resources are 
> provided in 
> > the network for the benefit of either the calling or called 
> party.  In 
> > this case, it is the called party that benefits.  Both your 
> and Mark's 
> > approaches (with which I agree) lay the responsibility on 
> the called 
> > party or its supporting proxy to recognize the mismatch in desired 
> > media and to invoke the translator as needed.  In the first case, I 
> > would assume the magic is based on some type of registration 
> > information (profile?) associated with the called party, in 
> the second 
> > case the called party explicitly asks for the service.
> > 
> > Mike
> > 
> > >We have two approaches.  The first approach would be more 
> like your 
> > >"it happens by magic in the network" approach.  In this 
> scenario, a 
> > >proxy detects the mismatch in SDP and requests the transcoding 
> > >service in the manner of a 2-party conference bridge.  The second 
> > >approach is where the terminating UA requests the 
> transcoding service 
> > >and returns the transcoding service's SDP to the calling UA.
> > >
> > >Service providers are more likely to use the first approach for 
> > >peering or as a value-add service.  Phone manufacturers or ingress 
> > >proxies are more likely to use the second approach.
> > >
> > >principle be translated (with varying degrees of ease) in to many 
> > >other types of media. What would be useful is a generic 
> way for the 
> > >parties to a session to specify their preferred media combinations 
> > >and for the appropriate translators to be automatically 
> brought into 
> > >the session - such a mechanism can be defined indepent of 
> the media 
> > >types involved and the translators available. (Perhaps 
> this is what 
> > >your draft does, Eric - I'll look out for
> > >it)
> > >I'd like to think there was a way of doing this which also 
> optimised 
> > >the use of resources - so if Party A wants to receive only 
> Media Type 
> > >1 (Media1), and Party B wants to send Media Type 2 (Media2) and an 
> > >Media2->Media1 translator is available, then there should 
> be no need 
> > >to send Media2 to A (indeed, the reason A likes Media1 might be 
> > >because it is lower bandwidth than Media2). Media2 should only be 
> > >sent to the translator. Equally, though, the case where A wants 
> > >*both* MT1 and MT2 should be supported. Regards, Mark Watson
> > >
> > >
> > >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
> > 
> > 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
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>