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

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Aug 2006 10:54:27 +0100

Guido,

On 31 Jul 2006, at 14:56, Guido Gybels wrote:
> Re txp/user-floor:
>
> <<The 'content' attribute is needed, so that the
>   receiving application can treat each media stream appropriately  
> based
>   on its content.>>
>
> It looks like this has been a difficult debate. At the risk of  
> creating further discussion, I would like to propose a slightly  
> different way of looking at this whole issue, in order to try and  
> break the deadlock:
>
> The bottom line of the "content" attribute seems to be that it is  
> in fact a piece of metadata telling us WHAT the content in that  
> stream represents (a semantic notion, rather than the more familiar  
> technical encoding we would expect in this type of protocol). So,  
> it can tell us that a stream is in fact a set of slides, that  
> another stream represents a video conversation through a sign  
> language interpreter or that yet another voice stream is part of a  
> conference call.

I would agree with this.

> I would like to offer the suggestion that as such, it is perfectly  
> in scope and reasonable to have the content attribute indicate that  
> a particular text stream represents a TTY (or textphone as we call  
> them in the UK) conversation.
>
> That is after all what I perceive the content attribute to do: tell  
> us WHAT this is.

This is where I disagree. The content is a conversation; the fact  
that one of the participants is using a text phone is an orthogonal  
issue. Depending on how I use the text phone, the content can change,  
but the fact that it's a text phone can't.

> I appreciate that content is not meant to deal with user behaviour,  
> but that part of the debate, I think, is a red herring. It has  
> detracted from the real question: is signalling the fact that a  
> certain stream is a TTY conversation notionally similar to  
> signalling that it is a slideshow or anything else for that matter.  
> I would offer the opinion that it is.
>
> The content attribute tells you what it is. Full stop. You can then  
> use that knowledge to define how to render that content, for example.

We have many different attributes and ways of defining "what it is",  
depending on which aspect of "what" is being coded. The "a=content:"  
attribute is supposed to give metadata about the contents of the  
media, not about the capabilities of the device generating that media.

> And it is quite relevant to have some attribute that tells you  
> something is a TTY conversation so that you can render that  
> differently (for example, I would have my client render TTY  
> conversations in a single window, similar to what you get on a TTY,  
> whereas non-TTY interactive text would be displayed in a dual  
> window or two column layout, one for each direction).

I agree that having an attribute to signal text phone calls would be  
useful. The disagreement is about which attribute should be used. I  
believe the property that the call is coming from a text phone is an  
indication of device features, not the content of the media, and  
should be signalling in an attribute relating to device properties.

For example, we could define an "a=device:" attribute, that gives  
some indication of the capabilities of the device used. That would  
allow sessions like:

	v=0
	o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
	s=SDP Seminar
	i=A Seminar on the session description protocol
	u=http://www.example.com/seminars/sdp.pdf
	e=[email-masked] (Jane Doe)
	c=IN IP4 224.2.17.12/127
	t=2873397496 2873404696
	m=text 50000 RTP/AVP 100
	a=rtpmap:100 t140/1000
	a=device:txp
	a=content:speaker
	m=video 50002 RTP/AVP 101
	a=rtpmap:101 h261/90000
	a=content:slides

where the role of "speaker" is signalled separately from the  
capabilities of the device used to connect to the session.

Colin

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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 7 Aug 2006 22:35:36 +0100

Colin,
You still think that "txp" specifies a device type.
We have no direct contact with this device, it is far away on the other end
of a PSTN line.

It is the media contents we want to give a hint on to both the application
and the user.

The content "txp" is a conversation of the type where you are expected to
participate excersizing formal turntaking.

I find that to be within what would be suitable for the description of the
media-content attribute.

Do you now?

Gunnar
----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Sunday, August 06, 2006 10:54 AM
To: Guido Gybels
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Guido,

I would agree with this.

	v=0

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Aug 2006 10:17:46 +0100

Gunnar,

> You still think that "txp" specifies a device type.

No, I do not.

> We have no direct contact with this device, it is far away on the  

Yes, I understand that. You have explained this several times now.

> participate excersizing formal turntaking.

There are two things going on here:

1) labelling that it is a conversation, which is an appropriate use  
for content label

2) labelling that, due to limitations of the UI on the PSTN device,  
you must use formal turn taking techniques during that conversation,  
which is not an appropriate use for content label

These are two different, and separable, things: the first is metadata  
about the contents of the stream, the second is metadata about device  
capabilities which impact user behaviour. Since they're different  
things, they should be signalled in different SDP attributes.

> I find that to be within what would be suitable for the description  

As I have repeatedly explained, no I do not think it is suitable.

Colin