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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 05 May 2004 13:50:31 +0300

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.

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

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
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, 05 May 2004 11:11:18 -0400

> 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

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