Subject: Re: [Sipping] Update to caller preferences use cases

From: "A vWijk" <[email-masked]>
Date: Wed, 16 Jul 2003 13:49:12 +0200

Jonathan,

<<> This is indeed one of "the still unclear how we solve it part". And
> perhaps for many people   unclear why this is needed. When I
> started with this hearing impairment work, I found the best
> solution in the caller preferences (that was around august 2000!).
> Where a user could indicate that he or she needs a speech to text
> or speech to sign or english or spanish or Dutch language. That a
> relay service can immediately see what kind of relay service it can
> offer to the user. It is all listed in the preferences.>>

<Lets be careful here, I think you mean its listed in the capabilities, 
not the preferences.>

I mean preferences based on the capabilities. :-)
If a terminal can receive text, great that is a capability. But my preference is that I want only incoming audio to be changed into text. Outggoing audio remains unchanged.
 And we still have no way to indicate that independent of any relay operator.

<What I *think* you mean is that a hearing impaired user would register 
to a relay service. That registration would have callee capabilities 
that indicates that it needs incoming audio translated to text, for 
example.>

The callee is in this case the hearing impaired user who registered him/herself..right?
If so, yes.. this relay operator has then all my preferences listed. That will indeed work. But the problem remains that the hearing impaired user MUST register him/herself with a certain relay operator.
And I am thus looking for a way to have those preferences listed independent of the registrar used. May it be from a local network operator or a relay operator or even from the university.

<I'm really not sure that this is a CAPABILITIES issue. Its a service 
invocation issue. The question is how one asks a service to return an 
IP address and port on which a certain type of media will be received, 
and then forwarded somewhere else in a specified translated format.>

Yes, correct it is a service option and not capability.

<To be honest, this feels much closer to TURN 
(http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt). 
TURN allows a client to ask for a relay service to forward packets to 
it. However, right now, the relay doesnt perform any transformations. 
One can imagine, however, extending TURN to provide transformation 
services as well - converting g711 to g729, or converting from audio 
to streaming text. To do this, the turn allocation request would 
contain a new attribute that specifies the desired transformation. As 
such, its really a service invocation.>

Umm I will check out the TURN method. It sounds good. Perhaps this can bring the solution closer.
I will also think more about this. And try to come with use cases to identify the missing links.

<This may not be the right approach either (need to think about it some 
more), but I think its a lot closer than callee capabilities.>

 << Those
> preferences would be independent to whatever location the user is
> calling or getting called. The latter is especially the problem
> now. If a caller uses a relay to call me (the deaf user), how can
> the relay know that it has to send audio, and to offer a text
> containing the speech of the said audio and to let me reply in
> audio to the caller (voice carry over, I am deaf, but I talk w/o
> any problem). And perhaps in an other case, a different deaf user
> prefers a signlanguage interpreting service for incoming voice and
> outgoing (user signs the answer back and the relay translates it
> into voice).>>

<I think the above proposal would solve that.>

Maybe. I will comment more as soon I have taken a good look at TURN. As I said before. I do not care how it is solved, as long the preferences of the invocation happens at a standardized and reliable way. And that it does not require the hearing impaired user to be registered with a relay opera

_______________________________________________
Sipping mailing list  https://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: Thu, 17 Jul 2003 13:21:36 -0400

At 01:49 PM 7/16/2003 +0200, A vWijk wrote:
>And that it does not require the hearing impaired user to be registered 
>with a relay operator

At the risk of assuming too much, does this mean that the hearing-impaired 
user does not have a "home" relay operator, but will need to be able to 
send an INVITE, much like an "sos" service code (perhaps "tdd" or "relay"), 
along with caller preferences or pre-conditions indicating the need for a 
particular type of relay service (e.g. "voice-to-2973" with 
directionality), and get forwarded to an appropriate server?  Furthermore, 
would that user be able to send a REFER to that server indicating the need 
to INVITE the called party?  This feels like a 2-way conference of sorts, 
with the focus not only mixing media, but also translating media.

Or perhaps there is another way to invoke this ad-hoc.

Mike