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

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

Jonathan,
In this case you are only looking at the relay invocation at the callee's side.
Thus the deaf user must always register him or herself at a selected relay service.

This solution will surely work, but I am not happy with this registering with the relay itself. It still does not solve incoming relay calls to the exact requirements of the receiving user.

About your other suggestion:
<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.>

If I understand this correctly, you state here that receiving streamed text (RFC 2793) can be a caller preference to ensure when a text call is initiated, that the correct terminal is selected. That is a good idea. It gives the users more flexibility.
And this allows the user who owns 3 phones, 2 cheap wallmart phones without any screen and keyboard and one normal IP telephone with a screen and keyboard to receive text calls on the right phone.

And perhaps also in this way that the user is only logged in a non text terminal, that the relay service or the caller can see that setting up a text call won't work?
And that the relay then kicks in and converts audio to text and vice versa.

I think that this is indeed useful. This will allow a relay service at least know which kind of media can be sent. E.g a terminal has no video ability but it has text. The relay can fallback to text in that case. Even if the caller uses a video connection and communicates via signlanguage.
(or the video caller can also switch to text and skip the relay).

This is useful at this level. So, this can be added as an example. It does not offer flexibility of voice carry over or hearing carry over and such. But for the basics it is useful.

Greetz

Arnoud

<<< Jonathan Rosenberg <[email-masked]>  7/16  8:54a >>>
inline.

Guido Gybels wrote:

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

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.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jul 2003 08:05:47 -0400

I think this scenario may be better solved with preconditions - a new 
kind of precondition for an acceptable mix of media being available. 
This avoids even alerted called parties if a satisfactory arrangement 
can't be made. This doesn't exclude using callerprefs to help, such as 
in picking the order in which to try devices, but does make it secondary.

Today we get away without preconditions on media because generally there 
is only one important medium. Many UAs will fail a call if no media are 
negotiated, effectively implementing a rudimentary form of precondition. 
But that is going to work going forward - there are beginning to be 
interesting call flows that have no media.

So in this case the hearing impared user's UA can first initiate a call 
with precondition for streaming text media. If that succeeds, fine. If 
not, it can try again - setting up a relay and sending a voice invite 
that splices in the relay.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 22 Jul 2003 21:05:37 +0200

> kind of precondition for an acceptable mix of media being available.

YUCK. Preconditions is like a strong drug with a lot of negative 
side-effects.  We should be very careful when prescribing it.  I don't 
think it is warranted here. I think ordinary offer/answer negotiation 
can give us what we need here.

thx,
-r

> Today we get away without preconditions on media because generally 
> there is only one important medium. Many UAs will fail a call if no 
> media are negotiated, effectively implementing a rudimentary form of 
> precondition. But that is going to work going forward - there are 
> beginning to be interesting call flows that have no media.
>
> So in this case the hearing impared user's UA can first initiate a 
> call with precondition for streaming text media. If that succeeds, 
> fine. If not, it can try again - setting up a relay and sending a 
> voice invite that splices in the relay.
>
> 	Paul
>
> A vWijk wrote:
>> Jonathan,
>> This solution will surely work, but I am not happy with this 
>> registering with the relay itself. It still does not solve incoming 
>> relay calls to the exact requirements of the receiving user.
>> <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.
>> If I understand this correctly, you state here that receiving 
>> streamed text (RFC 2793) can be a caller preference to ensure when a 
>> text call is initiated, that the correct terminal is selected. That 
>> is a good idea. It gives the users more flexibility.
>> And this allows the user who owns 3 phones, 2 cheap wallmart phones 
>> without any screen and keyboard and one normal IP telephone with a 
>> screen and keyboard to receive text calls on the right phone.
>> And perhaps also in this way that the user is only logged in a non 
>> text terminal, that the relay service or the caller can see that 
>> setting up a text call won't work?
>> I think that this is indeed useful. This will allow a relay service 
>> at least know which kind of media can be sent. E.g a terminal has no 
>> video ability but it has text. The relay can fallback to text in that 
>> case. Even if the caller uses a video connection and communicates via 
>> signlanguage.
>> This is useful at this level. So, this can be added as an example. It 
>> does not offer flexibility of voice carry over or hearing carry over 
>> and such. But for the basics it is useful.
>> Greetz
>> Arnoud
>>> 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.
>> 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.

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 23 Jul 2003 02:29:20 -0400

--On Tuesday, July 22, 2003 9:05 PM +0200 Rohan Mahy <[email-masked]> 
wrote:

> think it is warranted here. I think ordinary offer/answer negotiation can
> give us what we need here.
>
I think I agree with Rohan here. Preconditions are for "Captian Picard" 
style situations, where you need the endpoints and possibly some elements 
in the path to "make it so" before the call can proceed. In the case of 
media mix, it's either available or it isn't and any tuning of the warp 
engines during call establishment is unlikely to do the trick. Offer-answer 
will fail and you can try again based on what the answer says is do-able.

Dave.

>>> altogether, and find something which is really an example of a caller

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jul 2003 08:58:56 -0400

If you can rely on a UAS refusing a call without alerting when none of 
the offered media match then I agree you can do these cases decently 
without preconditions. I'm not sure that is a reasonable assumption. 
Certainly there are now call flows that start out with a no-media offer, 
so UAS's should accept those. And a UAS that is offered multiple media 
is generally expected to accept the subset it supports. The logical 
conclusion is that a UAS should accept a call even if the supported 
subset of media is null. I think this means the callee is then alerted.

If a caller wants to try an easy case, (e.g. end-end text), and then if 
that fails try a harder approach (e.g. allocate a relay and invite for 
voice thru the relay), then it needs a way to get the first attempt to 
terminate without alerting. I realize preconditions are strong medicine, 
but they are the only obvious way to avoid alerting.

Some more specification around what UASs should do about alerting and 
accepting/rejecting calls in these fringe cases would help in deciding 
if simple techniques can be used reliably.

	Paul

David R. Oran wrote:
> style situations, where you need the endpoints and possibly some 
> elements in the path to "make it so" before the call can proceed. In the 
> case of media mix, it's either available or it isn't and any tuning of 
> the warp engines during call establishment is unlikely to do the trick. 
> Offer-answer will fail and you can try again based on what the answer 
> says is do-able.
> 
> Dave.
> 
>> thx,
>> -r
>>