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

From: Guido Gybels <[email-masked]>
Date: Mon, 14 Jul 2003 19:40:20 +0100

Jonathan:

<<* added a hearing impaired use case>>

First of all, I think it is extremely useful to have some 
use cases for deaf and hard of hearing people in the 
draft. Some comments/questions:

1) If I understand the case correctly, the relay service 
needs to issue a registration on behalf of the user, 
indicating that this registration accepts audio. One of 
the problems with that scenario is that this seems to 
suggest that the user must register through the relay in 
order to be able to receive incoming calls. I'm not so 
sure how practical that is, especially with regard to 
roaming users (how would they discover the relay in the 
network?). Some thoughts on this would be welcome.

2) The current version is slightly vague with regard to 
the type of text coming out of the relay. Using 
traditional messaging (IM) is not really an option for 
relay calls. I'd like to see a more explicit example of 
using RFC2793 character-by-character text coming from the 
relay, as that is likely to be what will be used in a real-
world scenario. We have experimented at Typetalk with 
using IM for the interaction with the relay, but that has 
proven to be quite useless, as the conversation breaks 
down and the long pauzes and silences that result out of 
the message based interaction (as opposed to a continuous 
stream of text going back and forward) become extremely 
akward for both parties. Can I therefore suggest that this 
use case specifically mentions RTP T.140 text streams, 
rather just messaging. In fact, the deaf or hard of 
hearing user could register for both T.140 and IM, so that 
he/she can accept both those. If the hearing user want to 
set up an IM session, that will just succeed. If the call 
is rerouted through the relay, than it will connect a 
T.140 stream.

3) The current scenario is based on an incoming audio 
conversation, which certainly is a valid case. However, 
there is also the opposite possibility of making an 
outgoing call using T.140 but with a voice destination. In 
that case, again, the call needs to be routed through the 
relay. However, it seems unlikely that every hearing user 
will be registered with a relay service, so there is no 
registration for those hearing users, as hearing people 
cannot necessarily know in advance that they will be 
called by a deaf or hard of hearing person. So, can caller 
preferences deal with such a scenario? If yes, I would be 
grateful for a use case demonstrating this, otherwise we 
need suggestions on how to deal with such situations.

As ever,

Guido

Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 18:31:00 -0400

inline.

> network?). Some thoughts on this would be welcome.

I thought about this use case some more, and I actually concluded that 
this service is really not a CALLER PREFERENCE service. Its not about 
the caller preference at all. Its about a routing application on the 
callee side which sends incoming audio calls to a relay, and incoming 
messaging calls to a user. Something like that is best implemented 
through servlets on the callee side, or something. Its not a caller 
preference at all. So, I would like to remove this case altogether, 
and find something which is really an example of a caller preference.

> world scenario.

Yeah, the example didnt say - I had meant something like RFC2793.

> need suggestions on how to deal with such situations.

I dont see how. Clearly all called parties can't register against your 
relay.

I have a much simpler use case for hearing impaired services. I'm not 
sure its practical or useful, though, so please comment on that. 
Consider a caller that is hearing impaired. Before making a call, they 
contact a relay service. This relay service will receive audio and 
transform it to streaming text. Of course the caller can also receive 
streaming text directly from the called party. So, in their invite, 
they have an m-line for audio, and an m-line for streaming text. They 
add a caller preference to have their call routed to a device that 
supports streaming text. In this way, if a called party happens to be 
able to do both audio on one device, or streaming text on another, the 
call is routed to the device that can do streaming text.

It feels farfetched to me, so please comment.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com