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

From: "Chris Boulton" <[email-masked]>
Date: Wed, 5 May 2004 08:32:14 +0100

Yes from me for supporting ;-)

>-----Original Message-----
>From: Dean Willis [mailto:[email-masked]]
>Sent: 30 April 2004 10:45
>To: Paul Kyzivat
>Cc: Gonzalo Camarillo; [email-masked]; Rohan Mahy; Allison Mankin
>Subject: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00
>
>Paul Kyzivat wrote:
>
>Gonzalo quoted:
>>> " It is recommended that an offerer does not invoke transcoding
>>>    services before making sure that the answerer does not support
the
>>>    capabilities needed for the session. Making wrong assumptions
about
>>>    the answerer's capabilities can lead to situations where two
>>>    transcoders are introduced (one by the offerer and one by the
>>>    answerer) in a session that would not need any transcoding
services
>>>    at all."
>...
>
>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?
>
>--
>Dean
>
>_______________________________________________
>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

This message has been scanned for viruses by MailControl - www.mailcontrol.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