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

["Arnoud van Wijk" <[e-mail]>]

So Colin...
The issue is not txp or use-floor.
It is more or less WHAT is exactly the goal and use of the content label.

This label is to add information to the media stream what the content is.
So, when you receive 2 video streams using the same codecs, how do you know
one is signlanguage and one is the normal video telephone call? That is one
thing the content label solves.
But that does require user interaction or client interaction to ensure the
signlanguage stream is positioned correctly on the screen.

If you then look at the txp content label. The media stream gets labelled
that it is from a PSTN textphone.
PSTN textphone is a different content then subtitles or plain vanilla ToIP.

The user or the user client will be used in a different way based on the
content label. That is up to the user and the services he or she uses.

I totally fail to see your point that txp is different then sl or left
microphone or mainslides.

We both have a different view on what is content label and what is ok to use
it.
I appreciate the fact that you want to solve this and publish a draft on
that. I will surely study that when I see it floating on the MMUSIC mailing
list.

But maybe we should also focus on WHAT is the correct use of the content
label. Decide on that before saying txp is not allowed.

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: dinsdag 25 juli 2006 0:15
> To: Gunnar Hellstrom
> Cc: [e-mail]
> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
> 04.txt
> 
> Gunnar,
> 
> On 24 Jul 2006, at 22:42, Gunnar Hellstrom wrote:
> > The device in the far end, on the other end of the PSTN line on the
> > other
> > side of a gateway MAY have presentation limitations.
> >
> > But it MAY also have no limitations.
> >
> > The important thing is that it operates in an environment where
> > there is a habit to do formal turntaking by text tokens in the text
> > stream. Our user will have a better chance to use the media
> > properly when knowing that that is the environment it comes from.
> >
> > The IP terminal does not need to adapt more than to give this
> > indication in some way to the user.
> 
> You have said that before, and I have previously explained that it is
> a form of device capability negotiation, and therefore outside the
> scope of a content label.
> 
> > Similarly to the other content indicators.
> > The user-floor is a total analogy. The user needs an indication
> > about how to behave when using the medium. It is because of a lack
> > in the far end
> > terminal or in the conference system. The terminal does not adapt
> > more than give an indication. Similar as for "txp".
> 
> That is a problem with user-floor.
> 
> > For the "sl" indicator, for sign language, it is important to
> > present it big enough and with proper quality to be perceived. That
> > might influence
> > terminal, but I suggest we do not use this indication for that
> > purpose, but rather just for planning the layout on the display and
> > possibly to remind the user to prepare for a return channel in sign
> > language.
> >
> > You say: "There is a significant difference: the txp parameter
> > requires the user to change their behaviour due to device
> > capabilities. None of
> > the others do." It is a combination of conversational behaviour
> > culture and far far end device limitations on some of the terminals.
> > All parameters have something specific. Why would this be forbidden?
> 
> Because the other parameters, with the possible exception of user-
> floor, do not require changes in user behaviour.
> 
> > The sl requires video capabilities in the far end terminal.
> > The user-floor indicates a lack of conferencing tools.
> > The slides indicate a capability to send pictures.
> >
> > New extensions may add yet other parameters that indicate specific
> > characteristics of the terminals transmitting them combined with an
> > indication of the resulting medium.
> 
> No, they may not. This is your fundamental misunderstanding: they
> label the content of the stream, not the characteristics of the
> terminal. There is an important difference, which you do not seem to
> understand.
> 
> > How about to add a new value "subtitles" to be used as an
> > indication for the receiving application to plan the layout to
> > present it as text placed under the main video window.
> 
> Sure, that makes sense, since it labels the content of the stream,
> and does not describe the capabilities of the device.
> 
> > You say "For the record, I disagree that the changes suggested are
> > sufficient, for the reasons I have explained."
> >
> > I understand this as  "OK, let it be accepted but remember I was
> > not totally happy with it".
> 
> No, it means that the changes you have proposed ignore my concerns,
> and hence I object to the publication of the draft as it stands.
> 
> 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