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

From: Gunnar Hellström <[email-masked]>
Date: Tue, 22 Aug 2006 21:46:59 +0200

Regarding the discussion about the txp parameter value in draft-ietf-mmusic-sdp-media-content-04, I would like to suggest a new explanation. 

I hope you find this one more in line with the expectations of media contents parameter value descriptions, so that work on this document can progress.

txp: This indicates that the media stream contains a real-time text 
     telephone conversation. Formal turn-taking is likely to occur
     through text or voice indicators embedded in the media content. 
 
     The application may provide an indication of this type of content
     to the user so that the user gets an opportunity to adapt to the
     traditional interaction style of text telephony.

Gunnar
-----------------------------------------------------------------------------
Gunnar Hellström, Omnitor
[email-masked]

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 22 Aug 2006 18:04:33 -0700

The new text did not change my understanding of this attribute. The attribtue definition has tightly coupled the text content with a telephone.
An additional attribute (something like shown below) would make more sense for the text content.

m=text ..
a=content:chat 
a=device:specialphone (or some other name which makes more sense)

> -----Original Message-----
> From: Gunnar Hellström [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 12:47 PM
> To: MMusic; Cullen Jennings
> Cc: Gonzalo. Camarillo@ericsson. com
> Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
> 04.txt
> 
> Regarding the discussion about the txp parameter value in draft-ietf-
> mmusic-sdp-media-content-04, I would like to suggest a new explanation.
> 
> I hope you find this one more in line with the expectations of media
> contents parameter value descriptions, so that work on this document can
> progress.
> 
> 
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 23 Aug 2006 09:28:10 +0200

It is allowed to have more than one content attribute.

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.
With the new slimmed description it is of the same size and level as the
others.

As I remember it, the last call just asked for an improved description, not
questioning the idea to include the attribute.

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]

-----Original Message-----
From: Desineni, Harikishan [mailto:[email-masked]]
Sent: Wednesday, August 23, 2006 3:05 AM
To: Gunnar Hellström; MMusic; Cullen Jennings
Cc: Gonzalo. Camarillo@ericsson. com
Subject: RE: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

The new text did not change my understanding of this attribute. The
attribtue definition has tightly coupled the text content with a telephone.
An additional attribute (something like shown below) would make more sense
for the text content.

m=text ..
a=content:chat

---

From: Colin Perkins <[email-masked]>
Date: Wed, 23 Aug 2006 09:14:41 +0100

Gunnar,

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

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

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Thu, 24 Aug 2006 11:36:26 +0200

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): [email-masked]

> From: Colin Perkins [mailto:[email-masked]]
> 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,
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Aug 2006 11:10:40 +0100

On 24 Aug 2006, at 10:36, Arnoud van Wijk wrote:
> 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.

You are again missing the point: "real-time text to be used in turn  
taking method" says nothing about the contents of the stream, but  
rather describes how the users should interact with each other.  
That's a reasonable thing to describe, but it isn't describing the  
contents, and so shouldn't be in this attribute.

> It is not about a special phone, or limited device that is elsewise  
> unable to be connected.

The submitted versions of the draft, and the draft of V.151 Annex D  
that has been circulated, contradict that. Both use this parameter to  
signal that the peer device has limited user interface capabilities,  
which may change the way in which users interact during the session.

> But I am still waiting on Gonzalo's view on this.

Indeed - I would also like to hear other views.

Colin

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Aug 2006 11:01:39 +0300

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

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 25 Aug 2006 10:43:23 +0200

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

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: vrijdag 25 augustus 2006 10:02
> To: Arnoud van Wijk
> Cc: 'Colin Perkins'; 'Gunnar Hellström'; 'Cullen Jennings'; 'MMusic'
> unable

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Aug 2006 09:00:05 -0700

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

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 25 Aug 2006 23:11:43 +0200

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

Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
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

Thanks, Cullen

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Aug 2006 12:27:51 -0400

Gunnar,

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

	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 28 Aug 2006 20:14:36 +0200

Paul,
I changed the Subject line since we need to find another home for the
turn-taking indication than the media-content attributes.

What I would like to find or define is a parameter on the session level that
is just an indication about the type of limitations in communication that
may occur on the user interface side of a SIP device.

It should not influence control of media between SIP devices, but rather be
used to adapt the user interface of the terminal receiving this indication
to the communication habits.

For voice, it is not really half duplex like Push To Talk, because during
periods of voice it is possible to talk in both directions, it is only usage
patterns that usually limit voice usage to one direction.

During text transmission. Text may be handled in a half-duplex fashion, like
"push to text". But there are situations where more or less full duplex is
possible.

Would you recommend to signal this kind of media restrictions in the user
interface during a session by using the duplex="half" indication in the
contact field?
Note that the restrictions shall not apply to the media transport in the SIP
call.

Gunnar

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, August 28, 2006 6:28 PM
To: Gunnar Hellström
Cc: Cullen Jennings; Arnoud van Wijk; 'Colin Perkins'; 'MMusic';
'Gonzalo Camarillo'

Gunnar,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Aug 2006 15:21:36 -0400

Gunnar,

I'm not an expert in either the PTT stuff or your text mode stuff, so I 
might not have a lot to offer here.

Once upon a time, years ago now, there was some discussion of using half 
duplex in presence to denote PTT. But the PTT people never bought it.

As best I understand the PTT stuff in IMS (POC), it is handled via a 
special set of floor control conventions conveyed in RTP. (Someone will 
correct me if I am wrong.) Meanwhile, the media stream itself has no 
indication in SDP that it is half duplex.

So I wonder if this is so different from your usage. I think what might 
be appropriate is some way of conveying what floor control convention is 
to be followed for this stream. There could be one value that denotes 
the convention you want to use for text, and another that denotes the 
convention used for POC. (Different kinds of PTT may use different ones.)

AFAIK there is currently no attribute that does this. So maybe something 
like:

    a=floor-control-type: token

	Paul