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

[Paul Kyzivat <[e-mail]>]

Gunnar,

What you are now describing is beginning to sound like the PTT (Push To 
Talk) half duplex audio.

	Paul

Gunnar Hellström wrote:
> Cullen,
> Thanks for giving the media-content the required decision to move on.
> 
> This gives us a reason to review the requirements behind the proposed "txp"
> parameter for text turntaking.
> It can in fact be a combined audio/text turn-taking procedure. Real-time
> text and voice takes turns during a call in many cases on the PSTN side. And
> then, during text periods, turn-taking is often used for text in the two
> directions.
> 
> That leads me to think that we should look at session level attributes.
> Such as
> Contact: duplex="half" or a suitable more precise indication in SIP.
> 
> It should be remembered that the media flow itself should be left to be full
> duplex on the IP side.
> 
> More on this soon under another subject line.
> 
> Gunnar
> 
> ----------------------------------------------------------------------------
> -
> Gunnar Hellström, Omnitor
> [e-mail]
> Mob: [phone]
> Phone: [phone]
> www.omnitor.se
> 
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Friday, August 25, 2006 6:00 PM
> To: Arnoud van Wijk
> Cc: 'MMusic'; 'Gunnar Hellström' ; 'Gonzalo Camarillo'; 'Colin Perkins'
> Subject: Re: [MMUSIC] I-D
> ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
> 
> 
> 
> 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): [e-mail]
>>
>>> -----Original Message-----
>>> From: Gonzalo Camarillo [mailto:[e-mail]]
>>> 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): [e-mail]
>>>>
>>>>> -----Original Message-----
>>>>> From: Colin Perkins [mailto:[e-mail]]
>>>>> 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
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>>
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic