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

It is not saying that the stream itself is incapable of handling
simultaneous two-way communication.
On the IP side nothing will stop you to type happilly along, since for the
IP side, it is still full two-way communication.
But the user must be aware that the textphone user is likely NOT able to
deal properly with the two-way text. What happens then is that the incoming
and outgoing text will overlap on the textphone.

So, it has nothing to do with negotiation.

But I am open to rewording suggestions that will avoid this confusion. 
Perhaps say: "the media stream is originated from a textphone, which is
likely unable to handle simultaneous two-way communication.

And it is up to the user how to deal with it, but the user knows then..OH!
Yes, I will probably need to do the turn taking approach and end my own
lines with GA or X. (IP to IP ToIP is ALWAYS 2 way communication where both
users type at the same time if they want to).
But if the IP user then sees that the textphone user is happily typing along
when you are typing, you then know..OK no need for turn based typing.
But 95% of textphones will require turn based typing anyway.

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: donderdag 20 juli 2006 11:27
> To: Arnoud van Wijk
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
> 04.txt
> 
> On 20 Jul 2006, at 10:13, Arnoud van Wijk wrote:
> > I do not see any issue here.
> > This has NOTHING to do with negotiation at all. The content label is
> > specific to describe what the content of the media stream is.
> > It can be video for signlanguage, it can be an audio stream for the
> > feedback
> > microphone from users in the conference room (and the other audio
> > stream is
> > then the microphone of the MMUSIC chair and anoyther could be for the
> > presenattor etc etc).
> 
> All of which make sense, but are very different from what is
> expressed by 'txp'.
> 
> > So is txp indicating that the media stream is originated from a
> > textphone
> > that is incapable of handling simultaneous two-way communication".
> 
> The phrase "is incapable of handling simultaneous two-way
> communication" is the problem. The "a=content:" attribute is not
> intended to define the properties of a stream; it's a label to
> indicate the content of the stream. You're imposing a restriction
> with the content attribute that is not specified in the payload
> format, yet the content attribute draft is specifically not intended
> for that purpose.
> 
> The functionality you want is reasonable, but content-attribute is
> not the right mechanism to achieve it. Write up a separate draft,
> defining "a=textphone" with exactly the semantics you want, and well
> defined negotiation semantics.
> 
> Colin

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