Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Cullen Jennings <fluffy@cisco.com> Fri, 25 August 2006 16:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe6Z-0001wg-2u; Fri, 25 Aug 2006 12:00:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe6S-0001q5-16 for mmusic@ietf.org; Fri, 25 Aug 2006 12:00:16 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGe6O-0001Xm-Cm for mmusic@ietf.org; Fri, 25 Aug 2006 12:00:16 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2006 09:00:11 -0700
X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="338175348:sNHT34047148"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PG0BVs009216; Fri, 25 Aug 2006 09:00:11 -0700
Received: from [192.168.1.3] (sjc-vpn2-820.cisco.com [10.21.115.52]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7PG0Aw7023727; Fri, 25 Aug 2006 09:00:10 -0700 (PDT)
In-Reply-To: <000b01c6c822$865330c0$2400a8c0@solstice>
References: <000b01c6c822$865330c0$2400a8c0@solstice>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <35E451BE-CE68-46EF-90B3-098555CF1E8C@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
Date: Fri, 25 Aug 2006 09:00:05 -0700
To: Arnoud van Wijk <arnoud@annies.nl>
X-Mailer: Apple Mail (2.752.2)
DKIM-Signature: a=rsa-sha1; q=dns; l=5566; t=1156521611; x=1157385611; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20<fluffy@cisco.com> |Subject:Re=3A=20[MMUSIC]=20I-D=20ACTION=3Adraft-ietf-mmusic-sdp-media-content-04 .txt; X=v=3Dcisco.com=3B=20h=3DdMxx27VYGa7zN1jS0bfUPYNz7o8=3D; b=IIcUjq0egkEhJmekywyTCQ6hBQGyWzu3ZZlfuY2/lHbqSP6gGnYhrNHb106xwE2SVINWyx+R LEybQtPl93SxOb1O8oUvjNbQBfRDQGD3JsP3XcsWQy7+h+/PqL45r1oM;
Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Cc: 'MMusic' <mmusic@ietf.org>, 'Gunnar Hellström' <gunnar.hellstrom@omnitor.se>, 'Gonzalo Camarillo' <Gonzalo.Camarillo@ericsson.com>, 'Colin Perkins' <csp@csperkins.org>
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

Ok, folks, with my AD hat on here, here is what I would appreciate it  
if you would do:

Remove these two attributes from this draft - either we have come to  
consensus they should not be here or we have at least agreed that we  
don't have consensus on it.

Update the description of what are appropriate future extensions of  
this to include text along the lines of Gonzalo's

  "Content tokens should consist of a meta description of the  
contents of a media stream. That is, whether the stream contains  
slides, or is the main stream, etc. Content tokens should not  
describe things like what to do in order to handle a stream (e.g.,  
use user-level floor control)."

Resubmit this draft soon and I will start IETF LC on it. The WG can  
provide any comments that might typically be WGLC comments in IETF LC.

Go to work on another draft that solves the txp, user-floor problem -  
I will do what I can to help expedite that draft. One thing  that I  
think will help is if the draft is clear about what happens  when a  
device that receives this signally and how that changes the receiving  
devices behavior.

Thanks, Cullen


On Aug 25, 2006, at 1:43 AM, Arnoud van Wijk wrote:

> Very well.
> That is clear then.
> We shall focus on the separate SDP attribute.
>
> Arnoud
>
> Arnoud A. T. van Wijk
> AnnieS New Technology
> www.AnnieS.nl
> Mobile textphone (SIP): arnoud@annies.nl
>
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: vrijdag 25 augustus 2006 10:02
>> To: Arnoud van Wijk
>> Cc: 'Colin Perkins'; 'Gunnar Hellström'; 'Cullen Jennings'; 'MMusic'
>> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
>> 04.txt
>>
>> Hi,
>>
>> my take on this would be to remove the 'user-floor' and the 'txt'  
>> tokens
>> from this draft and add a clearer explanation of what the content  
>> tokens
>> (current and future) should describe.
>>
>> Content tokens should consist of a meta description of the  
>> contents of a
>> media stream. That is, whether the stream contains slides, or is the
>> main stream, etc. Content tokens should not describe things like  
>> what to
>> do in order to handle a stream (e.g., use user-level floor control).
>> That type of stuff would be better described in a separate SDP
>> attribute, as suggested by Colin at some point.
>>
>> That separate SDP attribute would resolve the use cases Arnoud and
>> Gunnar have in mind, which are very interesting as well.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> Arnoud van Wijk wrote:
>>> Hi Colin,
>>> I agree with Gunnar and disagree with you.
>>> The txp content label is no different the the other content  
>>> labels IMHO.
>>> And again, it is NOT about a PSTN textphone, but about turntaking be
>> used in
>>> the call since it media stream contains real-time text to be used in
>> turn
>>> taking method.
>>> It is not about a special phone, or limited device that is elsewise
>> unable
>>> to be connected.
>>> But I am still waiting on Gonzalo's view on this.
>>>
>>> Greetz
>>>
>>> Arnoud
>>>
>>> Arnoud A. T. van Wijk
>>> AnnieS New Technology
>>> www.AnnieS.nl
>>> Mobile textphone (SIP): arnoud@annies.nl
>>>
>>>> -----Original Message-----
>>>> From: Colin Perkins [mailto:csp@csperkins.org]
>>>> Sent: woensdag 23 augustus 2006 10:15
>>>> To: Gunnar Hellström
>>>> Cc: Cullen Jennings; MMusic; Gonzalo. Camarillo@ericsson. com
>>>> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media- 
>>>> content-
>>>> 04.txt
>>>>
>>>> Gunnar,
>>>>
>>>> On 23 Aug 2006, at 08:28, Gunnar Hellström wrote:
>>>>> It is allowed to have more than one content attribute.
>>>> True, but irrelevant.
>>>>
>>>>> There is no difference in characteristics of the txp attribute
>>>>> compared to the other accepted attributes.
>>>>> slides come from a slide showing application that has a specific
>>>>> expected behaviour of showing one slide at a time.
>>>>> Speaker has its source in a camera, a keyboard and a microphone
>>>>> that likely requires some polite method to be allowed to control.
>>>>> All have sources in devices and have a mixed meaning of device
>>>>> indications and preparation for human behaviour when using the
>>>>> contents.
>>>>> There is no reason to separate out txp in this collection of
>>>>> attributes.
>>>> I disagree, for the reasons I have previously explained.
>>>>
>>>>> With the new slimmed description it is of the same size and level
>>>>> as the others.
>>>> The "size and level" of the description was never the problem.
>>>> Instead, there is concern that its semantics don't fit with the
>>>> content label.
>>>>
>>>>> As I remember it, the last call just asked for an improved
>>>>> description, not questioning the idea to include the attribute.
>>>> I am explicitly questioning the inclusion of the txp label in the
>>>> media content draft. I believe it should be removed to a separate
>>>> draft, defining a new SDP attribute. We should also consider if the
>>>> user-floor label should be removed too.
>>>>
>>>> A simple rewording of the description of the txp label, of the type
>>>> you are proposing, without considering the semantics, will not
>>>> resolve this issue.
>>>>
>>>> Colin
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic