SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03

[Gunnar Hellstrom <[e-mail]>]

This is a new effort to describe the "txp" attribute for the
sdp-media-content draft.
My understanding is that the described use of the txp attribute is totally
in alignment with the aims of sdp-media-content. It does not influence
negotiation, it is just used for indication to the receiving user and
possibly direction of the media stream.

Current text:
txp: This indicates that the media stream is originated from a
      textphone, and it requires special behavior from the receiving
      application.  A typical use case for this is a connection where
      one endpoint is an analog textphone of a kind that cannot handle
      two-way simultaneous text communication, and the other one is a
      native IP based real time text capable terminal.  The human users
      normally need to apply formal turn-taking habits, and need to
      figure out to what extent it is possible to interrupt the other
      party if the need arises.

New proposal:
txp: This indicates that the media stream is originated from a
      textphone with restricted presentation capabilities.

      A typical use case for this is a connection between a
	gateway and an IP terminal capable of handling real-time text.
	The gateway gives the "txp" indication when its connection with
	textphone only can transmit the text medium one way at a time.

	In the audio media it indicates that a textphone is connected and
	may take turns on using real-time text alternating with audio on
	the connection because of the limitation in textphone presentation
	capabilities. Variations of the presentation limitations exist. Not
	all of them are detectable. Therefore the IP session should be set
	up for full duplex simultaneous operation, but an indication
	provided in the user interface making the IP terminal user aware of
	the situation. A possible such indication can be to direct the
	real-time text conversation to one common window for both text
	communication directions instead of the traditional split in one
	window per call participant.

	The indication is also supposed to make the user aware of that
	traditional turntaking habits from PSTN text telephony may need
	to be applied. For audio users the indication should mean be
	careful and not try to use voice and text simultaneously but
	leave time for mode switching in the limited textphone end.

	More about requirements on communication with textphones through
	gateways can be read in RFC 2804, section 11.2.4 [xx], in
	ITU-T H.248.2 [xy], and in ETSI EG 202 320 [xz]. These
	references also give more background to the variations in
	presentation capabilities of various textphones.


Gunnar


----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[e-mail]
Mob: [phone]
Phone: [phone]
www.omnitor.se


-----Ursprungligt meddelande-----
Fran: Gunnar Hellstrom [mailto:[e-mail]]
Skickat: den 5 juli 2006 22:41
Till: Colin Perkins
Kopia: 'Cullen Jennings'; 'Gonzalo Camarillo'; MMusic
Amne: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03




Colin, Cullen and all,
We have had a brief discussion about the "txp" attribute for the
media-content parameter.
I want to bring this discussion to the list.

We have been asked to provide a more clear definition of what content:"txp"
means.
During these efforts, Colin and Cullen have started to question if it was
right to include the "txp" attribute in this draft. They see some difference
in type of the "txp" attribute from the other attributes in the draft.

I have not seen that difference.
By the end of section 5, there is a statement "All of these values can be
used with any media type."
We have specified "txp" so far mainly to be used together with the text
medium specification.
But we can define it to have meaning also for audio. It would then mean that
audio contents is intermittently used and takes turns with text contents.
The party signaling this attribute is likely a PSTN gateway. Between the
gateway and the endpoint receiving the indication there is no strict
restriction on the media. It is rather how their contents is used that is
specified.

Many of the other attributes are also easiest foreseable for one specific
medium.

sl for sign lanuage is easiest foreseeable added to the video medium.
slides is easiest to foresee for the image medium.
speaker is said to be video related.

Thus there is no strict rule that an attribute must be valid for many media.

You say that the "txp" attribute influences media negotiation when the draft
says that media-content attributes should not. I cannot see that it
influences media negotiation more than any other media-content attribute.
The "sl" ( Sign language ) attribute may lead to some terminals avoiding to
connect this medium because the user is not interested, while others can be
interested to define their terminals to always negotiate the "sl" video and
put it in a good viewing position.

Same with "alt". On a small terminal you may preset the terminal to not show
the stream with the "alt" media-content attribute.


Conclusion, "txp" is an attribute of similar type as most other
media-content attributes and suits well in the media-contents specification.
It just needs a further elaborated description in the draft. I will have a
try shortly to create that.

Gunnar




----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[e-mail]
Mob: [phone]
Phone: [phone]
www.omnitor.se


-----Ursprungligt meddelande-----
Fran: Colin Perkins [mailto:[e-mail]]
Skickat: den 5 juli 2006 20:16
Till: Gunnar Hellstrom
Kopia: Arnoud van Wijk; 'Cullen Jennings'; 'Gonzalo Camarillo'; 'Jani
Hautakorpi ((JO/LMF))'
Amne: Re: SV: SV: SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03


On 5 Jul 2006, at 19:10, Gunnar Hellstrom wrote:
> Is it OK for you if we copy this thread to the list and continue
> there?

If you wish.

> Firstly, I saw a need to declare real-time text capability already
> on the
> session level. Therefore I suggested use of the Contact:;text
> and there we can also use Contact;:duplex="half"  as a general
> indicator.
>
> There were cases when text medium is not declared from the
> beginning, but
> the capability must be declared. So, for that situation I saw no
> way to use
> the media-content parameter.
>
> I think I am satisfied with these.
>
> But the media-content="txp" parameter was already on its way to be
> created,
> so I recommended use of it too.
>
> It is very similar in meaning with "user-floor" as we have
> discussed. A
> typical media-content attribute as I see it. A quite soft indicator
> that
> mainly users may need to consider. Similar to the other attribute
> values.
> What is the problem?

The "txp" media-content label is media format specific, defines some
attributes of the device, and your proposal for its use impacts the
media negotiation. The other content label attributes are both media
format and device independent, and are ignored during media negotiation.

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