Subject: [Sipping] Update to caller preferences use cases

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2003 03:27:18 -0400

Folks,

You may have seen that I posted an update to the caller preferences 
use cases:

http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.txt
http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.html
http://www.ietf.org/internet-drafts/draft-ietf-sipping-callerprefs-usecases-00.txt

This is now a working item of SIPPING.

There are a bunch of changes since the previous version. Firstly, the 
use cases are now aligned with the -09 version of caller preferences. 
As a result of the changes in the caller preferences algorithms, 
several use cases no longer work. I've already documented those in a 
note to sip.

Some other changes:

* added a hearing impaired use case
* added a use case where the registered contact has an embedded 
Reject-Contact
* added a bunch of example registrations from various common devices, 
to show how to use caller prefs
* added a bunch of material up front to motivate caller prefs

And some other open issues:

* one of the use cases (section 3.14) is really better done with a CPL 
script than caller preferences. Should we eliminate this use case? I 
say yes.

* do we advise devices to register what they can't do, along with what 
they can do? THis makes the registrations a lot more bloated, but 
caller preferences tends to work better. I say no.

* do we want to include an example implementation of the matching 
procedure of rfc2533? The benefit is to help calrify the spec a lot. 
The drawback is - what happens if its not consistent with the 
normative algorithm in RFC2533? I say we should include it.

Comments and questions welcome.

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

_______________________________________________
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: "A vWijk" <[email-masked]>
Date: Tue, 15 Jul 2003 19:50:41 +0200

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.
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).

What we need here is a way of registering the different preferences of the services like described above. Make this registration independent of location (thus not bound to a specific relay operator and country). Else we get roaming problems and that not all users have a selected relay operator (most have none, e.g most hearing users).

Ofcourse, it would be easy just to have the deaf user initiate the relay service. But that means that the deaf user has to pay for such service while it could be an phone advertisement or an unimportant call. I as a deaf user expect people who call me, to pay the charges of the relay if they need to get ahold of me.
And if I want to keep my deafness a secret, I am then willing to initiate the relay service anytime, even if it means I pay for an advertisement/marketing call. But most deaf users want every incoming a call a call that he or she understands. Thus as text,via IM or via T.140/RTP or as signlanguage etc. Regardless of the terminal used and the location.

I am open to good suggestions. For hearing people I want to add that this is not only benefitting the hearing/speech impaired. Imagine that you can get a (streaming) text translation in English when a Spanish speaking person calls you (translation can also be offered in voice ofcourse). It is the same principle. And with IP telephony, international calls will increase, since the distinction between local, interlocal and international will disappear.

greetz

Arnoud

<<< [email-masked]  7/15  9:57a >>>
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 18:43:00 -0400

A vWijk wrote:

> 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.

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.

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.

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.

The same thing would apply to MSRP, btw, one could add an attribute to 
a bind operation that asks for desired transformations.

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.

> 
> What we need here is a way of registering the different preferences
> of the services like described above. Make this registration
> independent of location (thus not bound to a specific relay
> operator and country). Else we get roaming problems and that not
> all users have a selected relay operator (most have none, e.g most
> hearing users).

In the above idea, the relay is purely the problem for the user that 
is hearing impaired. If they roam, they would presumably still contact 
their home relay service. If not, there needs to be some kind of 
visited service discovery done. Thats a general problem, not specific 
to transformation services.

> 
> Ofcourse, it would be easy just to have the deaf user initiate the
> relay service. But that means that the deaf user has to pay for
> such service while it could be an phone advertisement or an
> unimportant call. 

Well, thats the nice bit about TURN. It wouldnt work that way. A 
called party thats hearing impaired wouldnt contact the TURN server 
until after it receives the incoming call. This way, if the call is 
from a telemarketer the relay doesnt get contacted. You would just 
reject the call.

I as a deaf user expect people who call me, to
> pay the charges of the relay if they need to get ahold of me.

Well, thats probably not going to work in my proposed approach. I dont 
see how it works that way in any approach, without some serious 
settlement capabilities put into place.

> I am open to good suggestions. For hearing people I want to add
> that this is not only benefitting the hearing/speech impaired.
> Imagine that you can get a (streaming) text translation in English
> when a Spanish speaking person calls you (translation can also be
> offered in voice ofcourse). It is the same principle. And with IP
> telephony, international calls will increase, since the distinction
> between local, interlocal and international will disappear.

I agree to some extent. I think my proposed idea would be reasonable 
for automated translation services, and certainly language translation 
is NOT in that category. Codec translation is though.

-Jonathan R.

---

From: "Guido Gybels" <[email-masked]>
Date: Thu, 17 Jul 2003 18:15:14 +0000 GMT

Mike and others,

You raise a number of interesting issues, and so have other people over the last couple of days.
I'm happy to comment on a case by case basis, but it seems to me that there is a more fundamental issue here: the fact that we are missing a clear set of use cases describing the various scenarios for relay service usage as well as a proper set of requirements in terms of functional behaviour.
Maybe Arnoud and myself, together with those that want to participate should first carry out a proper analysis of this whole problem. We could then prepare a draft that presents the relay cases so that the most appropriate solutions can then be created.
Otherwise, I think that we will keep bouncing the issue around: we will raise a particular case, work out a solution for it, only to see that it doesn't fit very well with other cases. Maybe we first need to establish the bigger picture, try to get the overview first, before we can start detailing?
What do you all think? Based on a conversation I had with Arnoud today I think he would agree with this and I think we are willing to do this analysis and write it down.
Does this sound like a good way forward?

Guido

>>> "[email-masked]" 07/17/03 18:21 >>>

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-impairedu
 ser 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"),a
 long with caller preferences or pre-conditions indicating the need for ap
 articular type of relay service (e.g. "voice-to-2973" with 
directionality), and get forwarded to an appropriate server?  Furthermore,w
 ould that user be able to send a REFER to that server indicating the needt
 o INVITE the called party?  This feels like a 2-way conference of sorts,w
 ith the focus not only mixing media, but also translating media.

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

Mike

---

From: "A vWijk" <[email-masked]>
Date: Mon, 21 Jul 2003 10:50:55 +0200

Mike,
yes the REFER idea is also what I talked about with the other authors of the invocation draft.
In this way, the simple SIP telephone only needs to REFER the call and the much and much more advanced Relay SIP UA /conference bridge can set up the relay service.
A REFER to a URI: [email-masked] would indicate that all voice has to be changed into text.

It is a good thing to see that other people are thinking about this kind of problem.

greetz

Arnoud

<<< Michael Hammer <[email-masked]>  7/17  7:25p >>>
>And that it does not require the hearing impaired user to be registered 

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.

Mike

---

From: "A vWijk" <[email-masked]>
Date: Mon, 21 Jul 2003 10:53:44 +0200

I fully agree here Guido.
So, lets start on this. :-)

greetz

Arnoud

PS A big problem is still how a relay service can know what kind of service you need.
Especially for incoming relay calls. 

<<< [email-masked]  7/17  8:23p >>>
Mike and others,

Guido

Mike