Subject: Betr.: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00

From: "A vWijk" <[email-masked]>
Date: Mon, 10 May 2004 13:00:04 +0200

Indeed. The transcoding draft can asume that the UAS somehow know that it is a call that needs a relay and that the service needs to be invoked.
The framework draft should address how and when there is a need for a relay invocation. And which type (text, signlanguage etc).

greetz

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands.
Mobile: +31651921948
International text telephone: +31735588408

>>> Paul Kyzivat <[email-masked]> 05-05-04 17:11 >>>

Gonzalo Camarillo wrote:
> Paul,
> 
> We can add discussions on the issues you are mentioning to the framework 
> document. They are interesting issues. I believe they belong to the 
> framework document and not to the document we are WGLCing. This document 
> deals with how to invoke a transcoder; not with the reasons that led you 
> to decide to invoke it or with how to avoid using it.

OK. Based on my "pondering", I did conclude that the UAS can know what 
to offer based on the contact address used. So moving the rest to the 
framework works.

	Paul

> Thanks,
> 
> Gonzalo
> 
> Paul Kyzivat wrote:
> 
>>
>>
>> Dean Willis wrote:
>>
>>>
>>> Paul pondered:
>>
>>
>>
>> `:-)
>>
>>>> I suppose you could view this as a problem for the human operator of 
>>>> the device - to select an appropriate phone feature based on known 
>>>> capabilities of the callee. But that is pretty much a cop out. And 
>>>> it doesn't work when the decision has to be made  by the callee, as 
>>>> when the initial invite has no offer, unless you expect the callee 
>>>> to select different answer modes depending on who is calling.
>>>
>>>
>>>
>>> Would something like a priority-ordered preference/capability set in 
>>> caller-preferences/callee caps be a big aid here?
>>
>>
>>
>> Well, the normal use of callerprefs is to select among alternative 
>> advertised contacts. That doesn't seem to be the case here. Of course 
>> an endpoint *could* choose to alter its behavior based on callerprefs, 
>> but I don't know if we want to suggest that.
>>
>> However I suppose a variant is possible. An endpoint with these 
>> capabilities could register multiple contacts, tagged with 
>> capabilities for voice and text. Depending upon which one was called, 
>> it could do the right thing. And it could prioritize its native 
>> capabilities higher, so that a forking proxy would try that first even 
>> if the caller expresses no preferences.
>>
>> If that were done, when a call arrives at the contact associated with 
>> text, only text would be offered. When a call arrives at the contact 
>> associated with voice then all the games described in this draft would 
>> be carried out.
>>
>> That sounds like an interesting approach.
>>
>>     Paul
> 
> 

_______________________________________________
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

_______________________________________________
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